摘要：Kubespray 和 Kurator 就是这类开源工具的典型代表。本文将对这两款工具进行比较。
本文分享自华为云社区《Kubernetes 集群管理：Kurator or Kubespray-华为云云原生团队》，作者： 云容器大未来 。
随着云计算技术的飞速发展，Kubernetes 已经成为了容器编排领域的事实标准。用户可以通过 Kubernetes 自动化地部署、扩展以及管理容器化的应用程序。然而，在不同云环境下创建高可靠的 Kubernetes 集群可能是一个复杂和漫长的过程。面对这种情况，许多用户开始寻找能够自动化部署和管理 Kubernetes 集群的工具，而 Kubespray 和 Kurator 就是这类开源工具的典型代表。本文将对这两款工具进行比较。
Kubespray 是一个开源项目，旨在帮助用户在多云环境中部署和管理Kubernetes集群。为了实现这个目标，Kubespray 使用了 Ansible 这个强大的工具。Ansible 是一个深受信赖的开源自动化运维工具，主要用于自动化应用部署、配置管理和任务执行。基于此，Kubespray 能够在各种云平台，如 AWS、GCE、Azure、OpenStack 等以及裸机等硬件上进行部署。此外，Kubespray 还具有以下优点：
● 支持高可用集群
● 网络插件等属性可组合
● 支持多种流行 Linux 发行版
● 持续集成测试
使用 Kubespray，用户可以选择执行一个 Ansible 脚本，然后 Ansible 会使用 SSH 协议与各个目标主机进行通信，并基于该脚本实现集群部署、清理、升级等任务。
Kurator是由华为云云原生团队研发的业界领先的分布式云原生开源套件。其设计理念和实践经验源自华为云在分布式云原生领域多年的优秀实践。Kurator虽然基于Kubespray对本地数据中心集群的生命周期进行管理，但与Kubespray的主要区别在于，Kurator采用了更易于理解和配置的云原生声明式方法来管理集群，可谓站在了巨人的肩膀上。具体来说，Kurator设计了声明式的API用以表达Kubernetes集群的期望状态（比如集群的版本，集群的节点规模，网络配置等），并通过 Cluster Operator 对集群生命周期进行管理。这种方法极大地简化了用户的操作：用户只需将期望状态声明到 API 对象中，无论是创建集群还是进行其他操作，剩下的所有工作都可以由 Kurator 的Cluster Operator自动完成。此外，在分布式云场景下，由于资源和环境的差异和复杂性，这种声明式的方法具有更高的自动化程度和更好的扩展能力，使得管理和操作变得更为简便和高效。
下面的示例将展示如何使用 Kurator 部署一个本地数据中心的 Kubernetes 集群。
1.在已经安装了 Kubernetes 集群的机器上安装 Kurator 的Cluster Operator
2.创建包含 SSH key 的 secret（一种Kubernetes中用来保存敏感数据的对象）
3.声明包含了机器信息以及集群信息的 CRD（Custom Resource Definition，自定义资源定义，用于扩展Kubernetes API）
4.将这些 CRD 应用到集群中，Cluster Operator 就会开始自动执行目标集群的安装
下面的代码示例展示了如何定义'CustomMachine'和'CustomCluster'。
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1 kind: CustomMachine metadata: name: cc-custommachine namespace: default spec: master: - hostName: master1 # 将publicIP 的参数修改为真实master节点的公有IP publicIP: 200.x.x.1 # 将privateIP 的参数修改为真实master节点的私有IP privateIP: 192.x.x.1 sshKey: apiVersion: v1 kind: Secret name: cluster-secret node: - hostName: node1 # 将publicIP 的参数修改为真实node节点的公有IP publicIP: 200.x.x.2 # 将privateIP 的参数修改为真实的node节点的私有IP privateIP: 192.x.x.2 sshKey: apiVersion: v1 kind: Secret name: cluster-secret ... apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1 kind: CustomCluster metadata: name: cc-customcluster namespace: default spec: cni: # 可将cni的类型设置为 calico、flannal、cilium等 type: cilium controlPlaneConfig: # 高可用选项中将该地址设置为虚拟IP的地址 address: 192.x.x.0 # 可选项，用以设置负载均衡的域名 loadBalancerDomainName: my-apiserver-lb.kurator.com # 可选项，用于添加到API服务器签名证书，以保证其能被正确的验证 certSANs: [200.x.x.1,200.x.x.2] machineRef: apiVersion: cluster.kurator.dev/v1alpha1 kind: CustomMachine name: cc-custommachine namespace: default ...
在Kubernetes环境下，一旦上述的自定义资源（CR）被创建或更新后，相关事件会被发送到 API server。Cluster Operator 会监听这些与CR相关的事件，并根据定义的期望状态（由spec的字段定义）创建相应的manager worker来实现状态的调整，即从当前状态调整至期望状态。
这些manager worker是由Cluster Operator创建和管理的一种特殊的 Pod。这些 Pod能够执行相应的Ansible集群管理命令来实现状态调整。根据当前状态和期望状态的区别，Cluster Operator 会创建不同的worker来实现不同的调整。Cluster Operator 也会监听这些worker的完成情况，以确认任务的完成和状态的更新。
除了集群的创建和删除，集群节点扩缩容和升级等也是相同的流程。例如，进行升级时，只需要在 KubeadmControlPlane中修改version字段即可。同样地，进行扩缩容时，只需增删 CustomMachine中的节点信息字段。
整个过程如下图所示：
Kurator和Kubespray都可以在多种云环境中部署生产可用的Kubernetes集群。Kubespray具有前面介绍的诸多优点，包括提供了高可用选项。Kurator继承了Kubespray的能力与优点，同样支持高可用。然而，这两者在技术实现、用户体验和项目愿景与社区等方面存在显著的差异。
在Kubespray中，集群的配置主要通过清单文件和变量文件进行。清单文件定义了Ansible需要管理的主机，而变量文件则用于实现对Kubernetes集群的定制。在集群管理方面，Kubespray依赖于执行一系列的Ansible-playbook命令。每一种对集群的操作都有一个相应的Ansible脚本，这些脚本覆盖了集群部署、扩缩容、升级、清理等集群生命周期的管理。执行这些脚本需要使用Ansible-playbook命令，并在命令中包含使用的脚本、权限访问以及其他的参数信息。
相较之下，Kurator的实现方式有所不同。在Kurator中，所有的配置信息都被统一放在了API对象上。这意味着用户无需从Ansible的角度去管理这些配置，而是通过声明API对象的状态来配置。例如，当用户声明了期望的API对象的状态后，Cluster Operator就会自动触发并执行相应的操作。用户无需知晓底层使用的具体Ansible脚本，使得操作更为简洁和直观。
总的来说，虽然Kubespray提供了更灵活的定制化能力，但Kurator通过集中式的API对象管理和自动化操作，提供了更为简单、直观的集群配置和管理方式，在云原生环境下具有更好的扩展性。
正如上面提到的，在Kubespray中，用户需要配置清单文件和变量文件，然后根据自己的需求调整并执行对应的Ansible命令。
而 Kurator采用的是声明式配置来管理本地 Kubernetes 集群，这一方式与 Kubernetes 的核心设计理念高度一致。因此，对于 Kubernetes 用户来说，Kurator 更容易理解，并且学习成本更低。与仅需描述期望状态的Kurator相比，Kubespray 使用的是 Ansible 命令，这对于没有 Ansible 经验的用户来说可能会有一定的学习挑战。
此外，使用 API 对象的方式，Kurator 能够保存集群信息以及管理操作记录，方便用户查看和跟踪。由于保存了当前集群的信息，Kurator 还能在执行操作之前，对比操作参数进行预检查。例如，当用户想要升级集群的 Kubernetes 版本时，Kurator 可以在操作开始之前判断当前升级跨度是否合适。
借助 Operator 模式，Kurator 能够自动化地创建和管理集群。如果集群操作出现失败，用户可以删除出错的 worker，Kurator 会立即自动创建一个新的、功能相同的集群管理 worker，确保操作的幂等性，即重复操作不会改变系统状态。
这种高度自动化的方式有助于减少人工干预的时间和成本，从而降低人为错误的发生率并提高整体效率。
在社区愿景方面，Kubespray 的定位是在各种云环境中部署生产可用的 Kubernetes 集群，并没有将其关注点放在分布式云环境的集群管理上。而 Kurator 的定位是成为一键式分布式云原生套件。除了支持在多种云环境中部署集群，Kurator 更深远的目标是帮助用户一站式构建专属的分布式云原生基础设施，以支持企业业务在不同的云环境和边缘环境之间进行分布式升级。因此，Kurator 的最新版本引入了 "舰队" 的概念，以提供一致地管理分布在任何云环境上的集群的能力。
另外，在社区发展的阶段上，两者也有明显的不同。Kubespray 目前非常活跃且成熟，拥有大量的贡献者和用户。相较而言，Kurator 尚处于初期阶段，但潜力无限，充满创新可能。Kurator 社区汇聚了资深的开源项目贡献者，并且高度重视与尊重每位参与者的讨论和贡献。对于 Kubernetes 的新手，Kurator 可以帮助轻松创建集群并一键集成常用开源工具，便于用户更好地体验云原生技术。而对于追求突破和创新的开发者来说，Kurator 也为他们提供了充足的施展空间。
以下的对比表格总结了 Kubespray 和 Kurator 在多个方面的区别：
从上面的对比来看，Kubespray 和 Kurator 都有各自的优势和特点。Kubespray 是一个成熟的项目，有着活跃的社区和高度的集群定制能力。然而，Kurator 提供了更简化和用户友好的配置管理，使得用户能够更容易地上手和使用。虽然 Kurator 的社区在规模上目前不如于 Kubespray，但是它充满了创新和发展潜力。因此，无论你是一个 Kubernetes 的新手，还是一个寻求创新和发展潜力的开发者，Kurator 都能满足你的需求。
在未来的发展规划中,Kurator 将进一步加强其对 Kubernetes 集群生命周期的管理,并强化集群管理的能力,提供跨云、跨区域、跨集群统一、一致的策略管理以确保安全和合规性。Kurator还将加强跨云、跨区域、跨集群的流量管理。Kurator 还计划在分布式应用的编排方面进行创新,比如提供基于 Volcano 的统一调度策略,以满足不同业务场景的需求。为了提升安全性,Kurator 还将为 Kubernetes 提供运行时的安全扫描。此外,还将针对多集群应用提供统一的监控工具。所有这些努力都旨在构建一个更为强大、可靠和用户友好的分布式云原生套件。
如果您对Kurator有更多兴趣或想法，欢迎加入Kurator社区，参与社区讨论和开发。
GitHub地址：https://github.com/kurator-dev/kurator
Slack地址：https://join.slack.com/t/kurator-hq/shared_invite/zt-1sowqzfnl-Vu1AhxgAjSr1XnaFoogq0A