本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已不再准确。
kubeadm v1.8 发布：介绍简易的 Kubernetes 集群升级
编者注：本文是关于 Kubernetes 1.8 新特性的一系列深度文章中的一篇。
自 2016 年 9 月首次亮相以来，Cluster Lifecycle 特别兴趣小组 (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 server 端口，开始授权所有对 kubelets 的 API 调用，并改进了先前在 v1.5 中使用的 token discovery (令牌发现) 方法。Token discovery (也称为 Bootstrap Tokens) 在 v1.8 中晋升 Beta。
就特性数量而言，kubeadm v1.7.0 相比 v1.6.0 和 v1.8.0 是一个规模小得多的版本。主要新增功能是强制执行节点授权器 (Node Authorizer)，这显著减少了 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 Server、Controller Manager 和 Scheduler 本身是它们运行的集群中的工作负载。这意味着控制平面组件可以使用 Kubernetes 的原生能力进行管理，这具有许多优点。例如，像 scheduler 和 controller-manager 这样进行领导者选举的组件，如果以 DaemonSet 的形式运行，在实现高可用性时将自动在所有主节点上运行。Kubernetes 中的滚动升级可用于控制平面组件的升级，并且几乎无需为此编写额外的代码；它是 Kubernetes 内置的功能之一！
自托管在 v1.9.0 之前不会成为默认设置，但用户可以在实验性集群中轻松测试此特性。如果你测试了此特性，我们很乐意听到你的反馈！
你可以通过启用其功能门来测试自托管：
$ kubeadm init --feature-gates=SelfHosting=true
可扩展性
我们新增了一些可扩展性特性。你可以将一些任务委托给 kubeadm，例如生成证书或编写控制平面参数，但仍可自行驱动控制平面引导过程。基本上，你可以让 kubeadm 完成一部分工作，并在你需要自定义的地方自行填充。以前，你只能使用 kubeadm init 来执行“完整的套餐”。包含 kubeadm alpha phase 命令支持我们的目标，即将 kubeadm 构建得更加模块化，允许你调用引导过程中的原子子步骤。
在 v1.8.0 中，kubeadm alpha phase 只是一个 Alpha 预览版。我们希望在 v1.9.0 中将其晋升为 kubeadm phase 的 Beta 版。我们迫不及待地想收到社区关于如何更好地改进此特性的反馈！
改进
除了我们新的 kubeadm 特性之外，我们还改进了现有特性。使得 kubeadm join 如此简短便捷的 Bootstrap Token 特性已从 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 server 及其他控制平面组件）作为 Alpha 特性来解决。这是我们用户群体的常见请求。
此外，我们希望将自托管作为部署控制平面的默认方式：如果我们能够依赖 Kubernetes 自己的工具来管理集群组件，Kubernetes 将变得更容易管理。
推广 kubeadm 采用并参与其中
kubeadm 采用工作组是 SIG Cluster Lifecycle 与 Kubernetes 生态系统中其他方之间正在进行的一项努力。这个工作组专注于使 kubeadm 更具可扩展性，以便在社区中的其他端到端安装程序中推广对其的采用。欢迎所有人加入。到目前为止，我们很高兴地宣布 kubespray 已开始在底层使用 kubeadm，并同时获得了新特性！我们很期待看到其他人也跟随加入，共同壮大生态系统。
kubeadm 是了解 Kubernetes 的绝佳途径：它将 Kubernetes 的所有组件捆绑在一个包中。要了解 kubeadm 在底层真正做了什么，此文档描述了 v1.8.0 中 kubeadm 的功能。
如果你想参与这些工作，请加入 SIG Cluster Lifecycle。我们每周二 16:00 UTC 通过 Zoom 见面一次。有关我们每周会议讨论内容的更多信息，请查看我们的会议记录。会议是极好的学习机会，即使你不想立即跳进去展示自己的想法。你也可以注册我们的邮件列表，加入我们的Slack 频道，或者查看我们过去会议的视频存档。即使你最初只想观看视频通话，我们也热烈欢迎你成为 SIG Cluster Lifecycle 的新成员！
如果你想了解 kubeadm 开发者在 Kubernetes 发布周期中特定时间点的工作，请查阅此文档。最后，如果我们的任何即将开展的项目让你感兴趣，请不要犹豫加入我们！