本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
kubeadm v1.8 发布：为 Kubernetes 集群引入轻松升级
编者按：这篇博文是关于Kubernetes 1.8新功能的系列深度文章之一。
自2016年9月首次发布以来，集群生命周期特别兴趣小组（SIG）已将kubeadm确立为最简单的Kubernetes引导方法。现在，我们与Kubernetes v1.8.0的发布同步发布kubeadm v1.8.0。在这篇博文中，我将向您介绍自上次更新以来我们对kubeadm所做的更改、kubeadm的范围以及您如何为这项工作做出贡献。
安全第一：kubeadm v1.6 & v1.7
此前，我们讨论了kubeadm v1.6的计划更新。v1.6的首要重点是安全性。我们开始强制执行角色基于访问控制（RBAC），因为它已升级到beta版本，为集群中的不同系统组件提供了唯一的身份和锁定的权限，禁用了不安全的localhost:8080 API服务器端口，开始授权所有对kubelets的API调用，并改进了v1.5中使用的令牌发现方法。令牌发现（又称引导令牌）在v1.8中升级到beta版本。
在功能数量上，kubeadm v1.7.0与v1.6.0和v1.8.0相比是一个小得多的版本。主要新增功能是强制执行节点授权器，这显著减少了Kubernetes集群的攻击面，以及从v1.6集群进行的初步、有限的升级支持。
v1.8中更简单的升级、可扩展性和稳定性
从Kubernetes v1.7.0到我们的稳定期（代码冻结）之间，我们有八周的时间来实施新功能并稳定即将发布的v1.8.0版本。我们为kubeadm v1.8.0设定的目标是使其更具可扩展性。我们希望在此周期中添加许多新功能和改进，我们也成功了。升级以及更好的自省能力。kubeadm v1.8.0中最重要的更新（也是我最喜欢的新功能）是控制平面的一键式升级。虽然v1.7.0具有升级集群的能力，但用户体验远非最佳，而且过程存在风险。
现在，您可以通过输入以下命令轻松检查您的系统是否可以处理升级
$ kubeadm upgrade plan
这为您提供了可以升级到的版本以及集群健康状况的信息。
您可以通过指定--dry-run标志来检查升级将对您的系统产生的影响。在以前的kubeadm版本中，升级基本上是盲目的，您只能对升级将如何影响您的集群做出假设。有了新的dry run功能，不再有神秘感。在应用升级之前，您可以准确地看到应用升级会做什么。
检查升级将如何影响您的集群后，您可以通过键入以下命令应用升级
$ kubeadm upgrade apply v1.8.0
这是一种比以前版本更干净、更安全的升级方式。与任何类型的升级或降级一样，最好先使用您首选的解决方案备份您的集群。
自托管
在这种情况下，自托管指的是设置控制平面的一种特定方式。自托管概念最初由CoreOS在其bootkube项目中开发。长期目标是将此功能（目前处于alpha阶段）转移到通用的kubeadm工具箱。自托管意味着控制平面组件、API服务器、控制器管理器和调度器本身就是它们所运行集群中的工作负载。这意味着控制平面组件可以使用Kubernetes原语进行管理，这具有许多优势。例如，如果领导者选举的组件（如调度器和控制器管理器）在DaemonSet中运行，则当实现HA时，它们将自动在所有主节点上运行。Kubernetes中的滚动升级可用于控制平面组件的升级，几乎不需要为此编写额外的代码；这是Kubernetes的内置原语之一！
自托管在v1.9.0之前不会是默认设置，但用户可以在实验集群中轻松测试此功能。如果您测试此功能，我们很乐意收到您的反馈！
您可以通过启用其功能门来测试自托管
$ kubeadm init --feature-gates=SelfHosting=true
可扩展性
我们添加了一些新的可扩展性功能。您可以将一些任务（例如生成证书或向kubeadm写入控制平面参数）委托给kubeadm，但仍然自行驱动控制平面引导过程。基本上，您可以让kubeadm完成部分工作，并在需要自定义的地方自行填写。以前，您只能使用`kubeadm init`执行“完整的交易”。`kubeadm alpha phase`命令的加入支持了我们使kubeadm更模块化的目标，让您可以调用引导过程中的原子子步骤。
在v1.8.0中，`kubeadm alpha phase`只是一个alpha预览。我们希望在v1.9.0中将其升级为beta版`kubeadm phase`命令。我们迫不及待地期待社区对如何更好地改进此功能的反馈！
改进
除了新的 kubeadm 功能之外，我们还改进了现有功能。使 `kubeadm join` 如此简洁的引导令牌功能已从 alpha 升级到 beta，并获得了更多安全功能。
如果您在 v1.6 或 v1.7 中对系统进行了自定义，那么在升级集群时，您必须记住这些自定义。现在不再需要了：从 v1.8.0 开始，kubeadm 会将您的配置上传到集群中的 ConfigMap，并在升级时读取该配置，以实现无缝的用户体验。
第一个证书轮换功能已在 v1.8 中升级到 beta 版，这令人欣喜。感谢 Auth Special Interest Group，Kubernetes 节点组件 kubelet 现在可以自动轮换其客户端证书。我们预计此领域将持续改进，并将继续参与这项跨 SIG 工作，以轻松轮换任何集群中的所有证书。
最后但同样重要的是，kubeadm 现在更具弹性。`kubeadm init` 将更早地检测到更多故障环境，并超时而不是永远等待预期的条件。
kubeadm 的范围
由于 Kubernetes 有如此多的不同端到端安装程序，生态系统中存在一些碎片化。随着每个新 Kubernetes 版本的发布，这些安装程序自然会变得更加分歧。如果用户依赖于未以任何方式标准化的特定于安装程序的变体和挂钩，这可能会在以后造成问题。我们从一开始的目标就是使 kubeadm 成为部署 Kubernetes 集群的构建块，并提供 `kubeadm init` 和 `kubeadm join` 作为新 Kubernetes 用户的最佳实践“快速路径”。理想情况下，使用 kubeadm 作为所有部署的基础将更容易创建符合标准的集群。
kubeadm执行将最小可用集群启动并运行所需的动作。它只关心引导，而不是机器的配置，这是设计使然。同样，默认安装各种可有可无的插件，如Kubernetes Dashboard、一些监控解决方案、云提供商特定的插件等，都不在范围之内。相反，我们期望在kubeadm之上构建更高级、更定制的工具，以安装终端用户所需的软件。
v1.9.0 及以后
kubeadm 的未来将如何发展？
计划中的功能
我们计划在 v1.9.0 中将高可用性（复制的 etcd 和多个冗余的 API 服务器以及其他控制平面组件）作为 alpha 功能。这是我们用户群的常规请求。
此外，我们希望使自托管成为部署控制平面的默认方式：如果我们可以依靠 Kubernetes 自己的工具来管理集群组件，Kubernetes 将变得更容易管理。
促进 kubeadm 的采用和参与
kubeadm 采用工作组是 SIG 集群生命周期与 Kubernetes 生态系统中的其他参与方之间正在进行的一项工作。该工作组致力于使 kubeadm 更具可扩展性，以促进其在社区中其他端到端安装程序中的采用。欢迎所有人加入。到目前为止，我们很高兴地宣布 kubespray 已开始在底层使用 kubeadm，并同时获得了新功能！我们很高兴看到其他人效仿并使生态系统更加强大。
kubeadm是了解Kubernetes的好方法：它将所有Kubernetes组件捆绑在一个包中。要了解kubeadm在底层实际做了什么，请查阅此文档，它描述了v1.8.0中的kubeadm功能。
如果您想参与这些工作，请加入 SIG Cluster Lifecycle。我们每周二世界协调时 16:00 通过 Zoom 开会。有关我们每周会议讨论内容的更多信息，请查阅我们的会议记录。会议是一个很好的学习机会，即使您不想立即跳进去并提出自己的想法。您也可以注册我们的邮件列表，加入我们的Slack 频道，或者查看我们过去会议的视频存档。即使您最初只对观看视频通话感兴趣，我们也热烈欢迎您成为 SIG Cluster Lifecycle 的新成员！
如果您想了解 kubeadm 开发人员在 Kubernetes 发布周期中特定时间的工作，请查阅此文档。最后，如果您对我们即将推出的任何项目感兴趣，请不要犹豫加入！