这篇文章已超过一年。较旧的文章可能包含过时的内容。检查页面中的信息自发布以来是否已不正确。
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)，因为它已升级为测试版，为集群中的不同系统组件提供了唯一的身份和锁定权限，禁用了不安全的 localhost:8080 API 服务器端口，开始授权对 kubelets 的所有 API 调用，以及改进了以前在 v1.5 中使用的令牌发现方法。令牌发现（又名引导令牌）在 v1.8 中升级为测试版。
在功能数量上，与 v1.6.0 和 v1.8.0 相比，kubeadm v1.7.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 中以 kubeadm phase 的形式升级为测试版。我们迫不及待地想听到社区关于如何更好地改进此功能的反馈！
改进
除了我们新的 kubeadm 功能外，我们还对现有功能进行了改进。使 kubeadm join 如此简洁的引导令牌功能已从 alpha 升级为测试版，并获得了更多安全功能。
如果您在 v1.6 或 v1.7 中对系统进行了自定义，则在升级集群时必须记住这些自定义项是什么。不再需要：从 v1.8.0 开始，kubeadm 会将您的配置上传到集群内的 ConfigMap，并在升级时读取该配置，以实现无缝的用户体验。
第一个证书轮换功能已在 v1.8 中升级为 Beta 版，这非常值得高兴。 感谢 Auth 特别兴趣小组，Kubernetes 节点组件 kubelet 现在可以自动轮换其客户端证书。 我们预计这一领域会持续改进，并将继续参与这项跨 SIG 的工作，以便轻松轮换任何集群中的所有证书。
最后但并非最不重要的是，kubeadm 现在更具弹性。 kubeadm init 将更早地检测到更多故障环境，并超时而不是无限期地等待预期条件。
kubeadm 的范围
由于 Kubernetes 有如此多不同的端到端安装程序，生态系统中存在一些碎片化。随着 Kubernetes 的每次新版本发布，这些安装程序自然会变得更加分歧。如果用户依赖于任何方式都未标准化的特定于安装程序的变体和钩子，则可能会在未来造成问题。我们从一开始的目标就是使 kubeadm 成为部署 Kubernetes 集群的构建块，并为新的 Kubernetes 用户提供 kubeadm init 和 kubeadm join 作为最佳实践的“快速路径”。理想情况下，使用 kubeadm 作为所有部署的基础将使创建符合标准的集群更容易。
kubeadm 执行使最小可行集群启动并运行所需的操作。它只关心引导，而不是机器的供应，这是经过设计的。同样，默认安装各种不错的功能插件（如 Kubernetes Dashboard、一些监控解决方案、特定于云提供商的插件等）不在范围内。相反，我们希望在 kubeadm 之上构建更高层次和更具针对性的工具，以安装最终用户需要的软件。
v1.9.0 及以后
kubeadm 的未来有哪些计划？
计划的功能
我们计划在 v1.9.0 中以 Alpha 功能的形式解决高可用性（复制的 etcd 和多个冗余的 API 服务器以及其他控制平面组件）。这是来自我们用户群的常规请求。
此外，我们希望使自托管成为部署控制平面的默认方式：如果我们能够依靠 Kubernetes 自己的工具来管理集群组件，Kubernetes 的管理将变得更加容易。
推广 kubeadm 的采用并参与其中
kubeadm 采用工作组是 SIG Cluster Lifecycle 和 Kubernetes 生态系统中其他各方之间正在进行的努力。该工作组专注于使 kubeadm 更加可扩展，以便促进其在社区中其他端到端安装程序中的采用。欢迎所有人加入。到目前为止，我们很高兴地宣布，kubespray 开始在底层使用 kubeadm，并同时获得了新功能！我们很高兴看到其他人效仿并使生态系统更加强大。
kubeadm 是了解 Kubernetes 的好方法：它将 Kubernetes 的所有组件绑定到一个软件包中。要了解更多关于 kubeadm 在底层真正做了什么的信息，这份文档描述了 v1.8.0 中的 kubeadm 功能。
如果您想参与这些工作，请加入 SIG Cluster Lifecycle。我们每周二 UTC 时间 16:00 在 Zoom 上开会。有关我们在每周会议上讨论内容的更多信息，请查看我们的会议记录。会议是很好的学习机会，即使您不想马上加入并提出自己的想法。您还可以注册我们的邮件列表，加入我们的 Slack 频道，或查看我们过去会议的视频存档。即使您最初只对观看视频通话感兴趣，我们也欢迎您成为 SIG Cluster Lifecycle 的新成员！
如果您想知道 kubeadm 开发人员在 Kubernetes 发布周期的特定时间会做什么，请查看这份文档。最后，如果您对我们即将开展的任何项目感兴趣，请随时加入！