开源项目 WKSctl：使用 GitOps 管理 Kubernetes 集群

WKSctl是一个开源项目，用于通过 SSH 安装、引导和管理 Kubernetes 集群，包括其插件。WKSctl 是 Cluster API (CAPI) 按照GitOps方式所提供的一个项目。Kubernetes 集群是由 YAML 文件配置的，WKSctl 在 Git 的每次推送后都会应用更新，从而允许用户按需拥有可复制的集群。

CAPI 是一个 Kubernetes 项目，能够让用户以声明的方式创建、配置和管理集群，就像使用 Deployment 或 Service 等其他 Kubernetes 资源那样。目前，AWS或VMware vSphere等基础设施供应商提供了其他的 CAPI 实现。WKSctl 有一个有趣的特点，它只需一个 SSH 端点列表以及引导 Kubernetes 的目标虚拟机的关联凭据即可。

最近，InfoQ 采访了 Weaveworks 的Alexis Richardon（CEO）、Mark Ramm（产品总监）、Cornelia Davis（CTO）和Mark Emeis（工程师经理）以了解更多关于 WKSctl 的信息。

InfoQ：什么是 WKSctl？您为什么要构建另外一个 Kubernetes 工具？

Alexis Richardson：目前，有像kops或Kubeadm这样自行安装（roll your own，简称 RYO）的安装程序，也有像rancher、kind或minikube这样打包好的安装程序。WKSctl 让我们拥有 RYO 的强大功能，同时兼有打包好的安装程序的功能，适用于开发者、数据中心和云端。

WKSctl 是 CAPI 的一个开源实现，而不是 Kubernetes 的一个发行版。它是一个 GitOps 安装程序和控制器，适用于上游 Kubernetes 集群。WKSctl订阅一个存储库（使用Flux），其包含 Kubernetes 和其他我们希望安装的部件。然后，WKSctl 构建并引导该集群。我们要做就是给 WKSctl 提供一个 SSH 端点列表，剩下的事就由 WKSctl 完成。一旦该集群启动并运行，如果我们在 Git 中更改了该集群的配置，那么 WKSctl 会把这些更改应用到该集群上。

它的总体的好处是可以灵活地使用 Kubernetes 的多个不同的发行版本。我们可以有可复制的集群，想复制多少次就可以复制多少次。集群自身是牛而不是宠物。我们认为，理想情况下，集群应该是百分之百可丢弃的，当集群处于不正确的状态时，我们应该得到通知。

InfoQ：WKSctl 的典型使用场景是什么？

Richardson：WKSctl 的目的不是进行机器配置。因此，WKSctl 的理想用户是使用 Terraform、vSphere、Salt、Ansible 或 Chef 来自己配置机器的人。因此，用户可以使用 WKSctl 在这些机器上安装和引导 Kubernetes。但是，如果我们不想配置机器，那么，也可以用 Firekube，它比 WKSctl 更进一步。Firekube 使用一个 vanilla Kubernetes，并用 WKSctl 把它安装在Ignite（Firecracker虚拟机）集群上。

另一个使用场景是多云或混合云，这方面有更先进的模式，我们称之为“master-of-masters，简称MoM”模式。在这个模式中，我们将拥有一个 MoM 集群，它会在每个目标环境中供应 Kubernetes 主管理集群，后续我们就可以供应任意数量的 Kubernetes 集群了。

图源：GitOps和集群API：Master-of-Masters

InfoQ：WKSctl 是如何运行的？它是 CLI 还是一个 Kubernetes 控制器，还是两者兼有？

Mark Emeis：两者兼有。WKSctl 用 CLI 引导 Kubernetes 集群中的第一个节点，然后安装 WKSctl 控制器以管理其他 master 和 worker 节点的安装。WKSctl CLI 基于 Git 存储库创建一个集群，安装 Flux 以订阅该 Git 存储库，这就是我们所谓的“Git 到 Kubernetes 的调解循环”。最终，WKSctl 安装一个自定义资源控制器，以便根据从 Git 收到的配置来应用集群级的更改。

Cornelia Davis：有两个调解循环。Flux 是一个调解器，监控 Git 存储对集群配置的所有更改。本质上，它的工作是把这些来自 Git 的东西提交给 etcd。第二个调解器是 WKSctl 控制器，它就像 Kubernetes 中的 replication 控制器那样监控 etcd。

InfoQ：如何给 Kubernetes 集群打补丁和升级？是否有停机时间？

Mark Ramm：WKSctl 对 CAPI manifest 的更改做出反应。当运维人员改变 Kubernetes 的版本时，控制器更新 master 节点，然后是 worker 节点。当集群被有效更新时，需要构建应用程序以重新处理调度。对于应用来说，遵循 12 因素应用程序模式是个良好的开端。

InfoQ：我们能否自定义集群架构以解耦组件，比如有专门用于 etcd 的虚拟机而 API 组件位于另外的服务器中？

Ramm：默认情况下，WKSctl 启动时，会有 worker 节点和 3 个 master 节点。我们希望保持简单。如果要做更复杂的事情，我们会推荐使用我们的商业产品WKP。总体上，我们看到 WKSctl 发生的情况是，用户在按需创建开发和测试集群，这些集群是短暂的（规模不大）。很多集群来来去去，而不是只有一个大集群。 我们发现，一般情况下，出于权限和安全的原因，企业用户倾向于使用更多的集群而不是一个大型集群。另外，当我们水平扩展集群时，系统的扩展很容易，这跟创建大型集群刚好相反。

InfoQ：在社区中，WKSctl 的采用情况怎样？

Ramm：德国电信是刚开始使用 WKSctl 的客户。最近，他们分享了一个小视频，演示了 WKSctl 在他们的环境中的工作情况。

原文链接：

WKSctl: a Tool for Kubernetes Cluster Management Using GitOps