kubeadm v1.15 中的自动化高可用性：包含但可替换

在发布时，Lucas Käldström 以 SIG 集群生命周期联合主席和 kubeadm 子项目所有者的身份撰写；Fabrizio Pandini 以 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 分钟屏幕录像在此

简而言之

1. 设置负载均衡器。您需要一个外部负载均衡器；然而，提供此功能超出了 kubeadm 的范围。

   • 社区将为此任务提供一组参考实现
   • HAproxy、Envoy 或云提供商的类似负载均衡器效果良好

2. 在第一个控制平面节点上运行 kubeadm init，并进行少量修改

   • 创建 kubeadm 配置文件
   • 在配置文件中，将 controlPlaneEndpoint 字段设置为您的负载均衡器可访问的位置。
   • 运行 init，使用 --upload-certs 标志，如下所示：sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

3. 当您想扩展控制平面节点集时，随时运行 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 控制平面。这是一个显式的选择加入功能，您也可以以您喜欢的方式手动分发证书。\

• 动态增长的 etcd 集群。当您不提供外部 etcd 集群时，kubeadm 会自动添加新的 etcd 成员，作为静态 Pod 运行。所有 etcd 成员都加入到随着您的高可用性控制平面一起增长的“堆叠式”etcd 集群中。\

• 并发加入。与已经为工作节点实现的操作类似，您可以随时、以任何顺序甚至并行地加入控制平面节点。\

• 可升级。kubeadm 升级工作流已得到改进，以便正确处理 HA 场景，并且在像往常一样使用 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 migrate 命令执行自动模式迁移。

在今年内，我们期待将模式升级到正式可用版本 v1。如果您对这项工作感兴趣，也可以加入 WG 组件标准。

下一步是什么？

2019 年计划

我们正专注于将配置文件格式升级到 GA（kubeadm.k8s.io/v1），将这种超简单的 HA 流程升级到稳定版，并提供更好的工具来自动轮换运行集群所需的证书。

除了我们章程中的这三个关键里程碑之外，我们还希望改进以下领域

• 支持将 Windows 节点加入到 kubeadm 集群（带有端到端测试）
• 改进上游 CI 信号，主要针对 HA 和升级
• 整合 Kubernetes 工件的构建和安装方式
• 利用 Kustomize 实现高级、分层和声明式的配置

我们不保证这些交付成果会在今年发布，因为这是一项社区工作。如果您希望看到这些事情发生，请加入我们的 SIG 并开始贡献！尤其是 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 等频道
• 参加我们每周二太平洋时间上午 9 点举行的公开 SIG 集群生命周期 Zoom 会议
  • 查看会议记录以加入
• 参加我们每周三太平洋时间上午 9 点举行的公开 kubeadm 办公时间 Zoom 会议
  • 查看会议记录以加入
• 观看来自 KubeCon 巴塞罗那的SIG 集群生命周期介绍或 kubeadm 深入探讨 会议

感谢

如果没有为 SIG 集群生命周期和 kubeadm 做出贡献的伟大人士的帮助，这个版本是不可能实现的。我们要感谢所有 kubeadm 的贡献者和公司，使他们的开发人员能够从事 Kubernetes 的工作！

特别感谢使这一切成为可能的 kubeadm 子项目负责人

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

• ←上一页
下一页→