kubeadm v1.15提供的自动高可用性

作者：

• Lucas Kaldstrom， @luxas， 集群生命周期SIG联合主席以及kubeadm子项目拥有者，Weaveworks
• Fabrizio Pandini， @fabriziopandini， kubeadm子项目拥有者，独立

kubeadm是一个工具，使Kubernetes管理员能够快速、轻松地引导最小可行的集群，这些集群完全符合经过认证的Kubernetes指南。自2016年以来，它一直处于集群生命周期SIG的积极开发中，并在2018年底从beta版升级到通用版（GA）。

在这个重要的里程碑之后，kubeadm团队现在将重点放在核心特性集的稳定性上，并致力于成熟现有特性。

在本文中，我们将介绍kubeadm v1.15版本的改进。

kubeadm的范围

kubeadm专注于执行必要的操作，以用户友好的方式启动和运行一个最小可行的、安全的集群。kubeadm的范围仅限于本地机器的文件系统和Kubernetes API，它的目的是为高级工具提供一个可组合的构建块。

kubeadm接口的核心非常简单：运行kubeadm init创建新的控制平面节点，运行kubeadm join将工作节点连接到控制平面。还包括用于管理已经引导的集群的常用实用程序，如控制平面升级、令牌和证书更新。

为了保持kubeadm的精益、专注和供应商/基础设施无关，以下任务超出了范围：

• 基础设施生成
• 第三方网络
• 非关键附加组件，例如监视、日志记录和可视化
• 特定的云提供商集成

这些任务由其他集群生命周期SIG项目处理，例如用于基础设施生成和管理的集群API。

相反，kubeadm只覆盖每个Kubernetes集群中的共通点：控制平面。

kubeadm v1.15中有什么新内容？

高可用性升级到Beta

我们很高兴地宣布，对高可用性集群的自动化支持在kubeadm v1.15升级到Beta。让我们向所有在此工作中提供帮助的贡献者和早期采用者大声欢呼，以获得迄今为止收到的良好反馈！

但是kubeadm中的自动化高可用性是如何工作的呢？

好消息是，你也可以使用熟悉的kubeadm init或kubeadm join工作流来创建高可用性集群，惟一的区别是，在添加更多控制平面节点时，必须将--control-plane标志传递给kubeadm join。

这个功能的3分钟屏幕截图如下：

https://asciinema.org/a/252343

简而言之：

• 设置一个负载平衡器。你需要一个外部负载平衡器；但是，提供这一点超出了kubeadm的范围。
  • 不过，社区将为此任务提供一组参考实现
  • 可以使用HAproxy、Envoy或来自云提供商的类似的负载平衡器
• 在第一个控制平面节点上运行kubeadm init，需要少量修改：
  • 创建一个kubeadm配置文件
  • 在配置文件中，将controlPlaneEndpoint字段设置为可以到达负载平衡器的位置。
  • 运行init，使用--upload-certs标志，如下所示：sudo kubeadm init --config=kubeadm-config.yaml --upload-certs
• 当你想要展开控制平面节点集时，随时运行kubeadm join -control-plane
  • 控制平面和普通节点可以在任何时间以任何顺序连接
  • 运行的命令将由上面的kubeadm init给出，形式如下：

kubeadm join [LB endpoint] \
   --token ... \                                                                                          
   --discovery-token-ca-cert-hash sha256:... \                                                            
   --control-plane --certificate-key ...  

对于那些对细节感兴趣的人来说，有许多事情使这个功能成为可能。最值得注意的是：

• 自动化证书转移。kubeadm实现了一个自动证书复制特性，以自动化所有证书颁发机构/密钥的分发，这些证书/密钥必须在所有控制平面节点之间共享，以便使你的集群能够工作。这个特性可以通过传递--upload-certs到kubeadm init来激活；有关详细信息，请参见配置和部署HA控制平面。这是一个显式的选择加入特性，你还可以以你喜欢的方式手动分发证书。 https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
• 动态增长etcd集群。当不提供外部etcd集群时，kubeadm会自动添加一个新的etcd成员，作为一个静态pod运行。所有etcd成员都加入到一个“堆叠”etcd集群中，该集群与你的高可用性控制平面一起增长
• 并发连接。与已经实现的工作节点类似，你可以在任何时候、以任何顺序、甚至是并行的方式连接控制平面节点。
• 可升级。为了正确处理HA场景，对kubeadm升级工作流进行了改进，在像往常一样使用kubeadm upgrade apply启动升级之后，用户现在可以在剩余的控制平面节点和工作节点上使用kubeadm upgrade node来完成升级过程

最后，值得注意的是，已经创建了一个全新的测试套件，专门用于确保kubeadm中的高可用性将随着时间保持稳定。

证书管理

在kubeadm v1.15中，证书管理变得更加简单和健壮。

如果你定期执行Kubernetes版本升级，kubeadm现在将在kubeadm upgrade时自动旋转你的所有证书，从而使你的集群保持最新和合理的安全性。

如果你希望手动更新证书，则可以通过将--certificate-renewal=false传递给kubeadm upgrade命令来退出自动证书更新。然后，你可以使用kubeadm alpha certs renew命令执行手动证书续订。

但还有更多。

引入了一个新的命令kubeadm alpha certs check-expiration，允许用户检查证书过期。输出类似如下：

CERTIFICATE                EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
admin.conf                 May 15, 2020 13:03 UTC   364d            false
apiserver                  May 15, 2020 13:00 UTC   364d            false
apiserver-etcd-client      May 15, 2020 13:00 UTC   364d            false
apiserver-kubelet-client   May 15, 2020 13:00 UTC   364d            false
controller-manager.conf    May 15, 2020 13:03 UTC   364d            false
etcd-healthcheck-client    May 15, 2020 13:00 UTC   364d            false
etcd-peer                  May 15, 2020 13:00 UTC   364d            false
etcd-server                May 15, 2020 13:00 UTC   364d            false
front-proxy-client         May 15, 2020 13:00 UTC   364d            false
scheduler.conf             May 15, 2020 13:03 UTC   364d            false

在下一个版本中，你还应该期望kubeadm中围绕证书管理进行更多的工作，引入ECDSA密钥，并改进对CA密钥旋转的支持。此外，在kubeadm alpha下执行的命令预计将很快移动到顶层。

改进的配置文件格式

你可以争辩说，几乎没有两个Kubernetes集群配置相同，因此需要根据环境定制集群的设置方式。配置组件的一种方法是通过标记。然而，这有一些可伸缩性限制：

• 难以维护。当一个组件的标志集增长超过30个以上的标志时，配置它就变得非常困难。
• 复杂的升级。当标记被删除、弃用或更改时，你需要与参数同时升级二进制文件。
• 键值限制。有许多类型的配置无法用—key=value语法表示。
• 命令式的。与声明式指定的Kubernetes API对象本身相反，标志参数在设计上是命令式的。

这是Kubernetes组件的一个关键问题，因为一些组件有150多个标记。使用kubeadm，我们开创了ComponentConfig的工作，并为用户提供了一组小标志，但最重要的是，为高级用例提供了声明性和版本化的配置文件。我们称之为ComponentConfig。它具有以下特点：

• 可升级：你可以升级二进制文件，但仍然使用现有的旧模式。自动迁移。
• 可编程。用JSON/YAML表示的配置允许一致的、可编程的操作
• 可表现的。可以使用和应用高级配置模式。
• 声明性的。OpenAPI信息可以很容易地暴露/用于生成文档

在kubeadm v1.15中，我们改进了结构，并发布了新的v1beta2格式。需要注意的是，v1.13中发布的现有v1beta1格式仍然适用于多个版本。这意味着你可以将kubeadm升级到v1.15，并且仍然使用现有的v1beta1配置文件。当你准备好利用v1beta2中所做的改进时，可以使用kubeadm config migration命令执行自动模式迁移。

在这一年的课程中，我们期待着把模式升级到通用可用性v1（GA v1）。如果你对这项工作感兴趣，你也可以加入Component Standard工作组。

https://github.com/kubernetes/community/tree/master/wg-component-standard

接下来是什么？

2019年计划

我们正致力于将配置文件格式升格为GA（kubeadm.k8s.io/v1），将这种超级简单的高可用性流升格为稳定，并提供更好的工具来实现自动运行集群所需的证书的旋转。

除了在章程的三个关键里程碑外，我们还想改进下列领域：

• 支持将Windows节点连接到kubeadm集群（提供端到端测试）
• 改善上游CI信号，主要用于HA和升级
• 整合Kubernetes工件的构建和安装方式
• 利用Kustomize支持高级、分层和声明性配置

尽管如此，我们不保证这些交付物将在今年交付，因为这是一个社区的努力。如果你想看到这些事情发生，请加入我们的团体并且开始贡献！ComponentConfig问题尤其需要更多的关注。

kubeadm现在有了一个标志！

在这个周期里，Dan Kohn提供了CNCF的帮助，创建kubeadm标识。Alex Contini 创造了19个（！）不同的标志选项，供社区投票。民意调查持续了大约一周，我们得到了386个答案。获胜的选项获得了17.4%的选票。换句话说，现在我们有了一个官方标志！

贡献

如果这一切听起来令人兴奋，加入我们吧！

集群生命周期SIG有许多不同的子项目，kubeadm就是其中之一。在下面的图片中，你可以看到图中有很多部分，我们还有很多事情要做。

如果你想开始贡献，这里有一些方便的链接：

• 你可以在YouTube上观看集群生命周期SIG新贡献者怎样开始参与。
• 在我们的存储库中寻找“good first issue”、“help wanted”和“sig/cluster-lifecycle”标记的问题（例如kubernetes/kubeadm）
• 在Slack中加入#sig-cluster-lifecycle、#kubeadm、#cluster-api、#minikube、#kind等
• 加入我们的公共，双周的集群生命周期SIG Zoom会议，星期二上午9点（太平洋时区）
  • 查看会议记录以加入
  • https://docs.google.com/document/d/1Gmc7LyCIL_148a9Tft7pdhdee0NBHdOfHS1SAF0duI4/edit
• 加入我们的公众，每周在Zoom会议的kubeadm办公时间，星期三上午9点（太平洋时区）
  • 查看会议记录以加入
  • https://docs.google.com/document/d/130_kiXjG7graFNSnIAgtMS1G8zPDwpkshgfRYS0nggo/edit
• 查看来自KubeCon Barcelona的集群生命周期SIG的简介或kubeadm深入了解

谢谢

如果没有为集群生命周期SIG和kubeadm做出贡献的优秀人员的帮助，这个版本是不可能发布的。我们要感谢所有kubeadm的贡献者和让他们的开发者能够投入使用Kubernetes的公司！

我们特别要感谢kubeadm子项目的所有人，正是他们使这一切成为可能：

• Tim St. Clair， @timothysc，集群生命周期SIG联席主席，VMware
• Lucas Kaldstrom， @luxas， 集群生命周期SIG联合主席，Weaveworks
• Fabrizio Pandini @fabriziopandini，独立
• Lubomir I. Ivanov， @neolit123， VMware
• Rostislav M. Georgiev， @rosti， VMware