本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

为创建和管理 Kubernetes 集群奠定更坚实的基础

作者：Lucas Käldström（独立） |

上次收到我们的消息是在 9 月，当时我们宣布了 kubeadm。kubeadm 成为 Kubernetes 生态系统中一流公民的工作仍在继续并不断发展。我们中的一些人还在 KubeCon 之前见过面，并进行了一次非常富有成效的会议，讨论了我们 SIG、kubeadm 和 kops 的范围。

继续定义 SIG-Cluster-Lifecycle

kubeadm 的范围是什么？
我们希望 kubeadm 成为所有 Kubernetes 部署的通用构建块；提供安全和推荐的 Kubernetes 引导方式。由于没有一种真正的方法来设置 Kubernetes，因此 kubeadm 将支持每个阶段的多种方法。我们希望确定每个 Kubernetes 部署的共同阶段，并为这些阶段制定可配置且易于使用的 kubeadm 命令。例如，如果您的组织要求您手动或以自定义方式分发集群中的证书，请跳过仅针对该阶段使用 kubeadm。在这种情况下，我们的目标是使 kubeadm 可用于所有其他阶段。我们希望您能够选择您希望 kubeadm 执行的操作，并让您自己完成其余操作。

因此，kubeadm 的范围是易于扩展、模块化且非常易于使用。目前，使用此 v1.5 版本，kubeadm 只能为您提供“全套服务”。在未来的版本中，随着 kubeadm 变得更加组件化，这种情况将会改变，同时仍然有机会为您完成所有工作。但 kubeadm 仍然只处理 Kubernetes 的引导；它永远不会为您处理机器的配置，因为这可以通过更多的方式完成。此外，我们希望 kubeadm 能够在任何地方工作，即使在多种架构上，因此我们从一开始就内置了 多架构支持。

kops 的范围是什么？
kops 的范围是自动化完整的集群操作：安装、重新配置集群、升级 kubernetes 以及最终删除集群。kops 具有基于 Kubernetes API 机制的丰富配置模型，因此您可以轻松地根据需要自定义一些参数。kops（与 kubeadm 不同）会为您处理资源的配置。kops 的目标是在 AWS（以及未来可能的其他提供商）上提供最终的开箱即用体验。未来，kops 将在引导阶段越来越多地采用 kubeadm。这将把 kops 内部的一些复杂性以 kubeadm 的形式转移到一个中心位置。

SIG-Cluster-Lifecycle 的范围是什么？
SIG-Cluster-Lifecycle 积极尝试简化 Kubernetes 的安装和管理。这在许多情况下是通过修改 Kubernetes 本身并分解常见任务来完成的。我们还试图解决集群生命周期中的常见问题（顾名思义！）。我们维护并负责 kubeadm 和 kops。我们讨论了当前在 AWS（及其他）上引导集群的方式存在的问题，并试图使其更容易。我们在 Slack 的 #sig-cluster-lifecycle 和 #kubeadm 频道中闲逛。我们每周在 Zoom 上开会讨论当前的主题。随时来打个招呼！另外，不要羞于贡献；我们欢迎您的评论和见解！

展望 v1.6

我们对 v1.6 的目标集中在重构、稳定性和安全性方面。

首先，我们希望 kubeadm 及其可组合的配置体验达到 beta 版本。我们将重构 kubeadm，以便引导过程中的每个阶段都可以单独调用。我们希望将 TLS Bootstrap API、Certificates API 和 ComponentConfig API 引入 beta 版本，并让 kops（和其他工具）使用它们。

我们还将通过向控制器管理器添加一个新的控制器：BootstrapSigner，将我们现在使用的令牌发现（又名 gcr.io/google_containers/kube-discovery:1.0 镜像）升级到 beta 版本。使用作为 Secret 管理的令牌，该控制器将在新的 kube-public 命名空间中签署众所周知的 ConfigMap 的内容（一个 kubeconfig 文件）。此对象将对未经身份验证的用户可用，以便能够使用简单且简短的共享令牌进行安全引导。您可以阅读完整的提案此处。

除了可以单独调用各个阶段之外，我们还将添加一个新阶段，用于以自托管模式（而不是当前的静态 Pod 技术）启动控制平面。自托管技术由 CoreOS 以 bootkube 的形式开发，现在将作为一种替代方案并入官方 Kubernetes 产品中。感谢 CoreOS 推动这种模式的发展！这将首先通过静态 Pod 建立一个临时控制平面，根据需要注入 Deployment、ConfigMap 和 DaemonSet，最后关闭临时控制平面来完成。目前，etcd 默认情况下仍将位于静态 Pod 中。

我们最初支持自托管是因为我们希望支持使用 kubeadm 进行补丁版本升级。例如，从 v1.6.2 升级到 v1.6.4 应该很容易。我们将内置升级支持视为真正的集群生命周期工具的关键功能。仍然可以在不自托管的情况下进行升级，但这将需要更多的手动操作。

在稳定性方面，我们希望开始运行 kubeadm 端到端测试。在 v1.5 时间框架内，我们添加了单元测试，并且我们将继续增加测试覆盖率。我们希望将其扩展到每个 PR 的端到端测试，这些测试将使用 *kubeadm init* 和 *kubeadm join* 启动集群；运行一些特定于 kubeadm 的测试，并可选地运行一致性测试套件。

最后，在安全性方面，我们还希望 kubeadm 默认情况下尽可能安全。我们希望为 v1.6 启用 RBAC，锁定 kubelet 和 kube-dns、kube-proxy 等内置服务可以执行的操作，并可能创建具有不同权限的特定用户帐户。

关于发布，我们希望在 kubernetes v1.6 tarball 中包含官方的 kubeadm v1.6 二进制文件。这意味着将我们的发布与官方发布同步。可以在此处找到有关我们迄今为止所做工作的更多详细信息。一旦可行，我们的目标是将 kubeadm 代码移至 kubernetes/kubeadm 仓库（这取决于一些 Kubernetes 代码特定的基础设施问题，这些问题可能需要一些时间才能解决）。

v1.6 的期望功能包括一个官方的 CoreOS Container Linux 安装程序容器，该容器的功能与 Ubuntu/CentOS 的 deb/rpm 相同。通常，扩展发行版支持会很好。我们还想采用Kubelet 动态设置，以便传递给 kubeadm init 的配置自动流向节点（目前需要手动配置）。我们希望能够通过使用 kubeadm 来测试 Kubernetes 的 HEAD 版本。

展望 2017 年及以后

除了上面提到的所有内容之外，我们希望 kubeadm 只是一个您可以用来引导 Kubernetes 集群的生产级（GA）工具。我们希望 HA/多主控比现在跨平台更容易实现（尽管 kops 如今在 AWS 上很容易做到这一点！）。我们希望云提供商是树外（out-of-tree）的，并且可以单独安装。*kubectl apply -f my-cloud-provider-here.yaml* 应该可以正常工作。文档应该更强大，应该更深入。容器运行时接口 (CRI) 和联合应该与 kubeadm 良好地协同工作。应删除过时的入门指南，以免误导新用户。

重构云提供商集成插件
目前，云提供商集成内置于控制器管理器、kubelet 和 API 服务器中。这与人们对 Kubernetes 日益增长的兴趣相结合，使得将云提供商集成编译到核心中变得难以维护。明确特定于供应商的功能不应成为核心 Kubernetes 项目的一部分，而应作为第三方供应商的插件提供。所有特定于云的内容都应移至一个控制器，或者如果需要，可以移至几个控制器。该控制器将由第三方（通常是集成背后的公司）维护，并将实现特定于云的功能。这种从内核到核外的迁移是破坏性的，是的，但它具有非常好的副作用：更精简的核心，使 Kubernetes 可以集成七个以上的现有云，并且安装更容易。例如，您可以在 Deployment 中运行云控制器二进制文件，并使用 *kubectl apply* 轻松安装它。

v1.6 的计划是使其能够

  • 创建和运行核外云提供商集成控制器
  • 在 Kubernetes 版本中发布一个新的临时二进制文件：cloud-controller-manager。该二进制文件将包含七个现有的云提供商，并将用作验证、测试和迁移到新流程的一种方式。在未来的版本（建议使用 v1.9）中，`--cloud-provider` 标志将停止工作，并且临时 cloud-controller-manager 二进制文件将不再提供。相反，一个名为 kubernetes/cloud-providers 之类的存储库将作为官方验证的云提供商发展和存在的场所，但那里的所有提供商都将彼此独立。（问题 #2770；提案 #128；代码 #3473。）

v1.4 到 v1.5 的变更日志

kubeadm

v1.5 是 kubeadm 的稳定版本。我们致力于使 kubeadm 更易于使用、更透明、更稳定。添加了一些新功能，使其更具可配置性。

以下是更改内容的简短摘录

  • 使 kubeadm 的 *控制台输出* 更清晰，更 *用户友好* #37568
  • 实现了 *kubeadm reset* 以及清空和清理节点 #34807 和 #37831
  • *预检* 实施，如果环境无效，则快速失败 #34341 和 #36334
  • *kubectl logs* 和 *kubectl exec* 现在可以与 kubeadm 一起使用 #37568
  • 以及许多其他改进，请阅读完整的 变更日志。

kops

以下是更改内容的简短摘录

  • 支持 CNI 网络插件（Weave、Calico、Kope.io）
  • 完全私有部署，其中节点和主节点没有公共 IP
  • 改进了集群的滚动更新，尤其是 HA 集群的滚动更新
  • 支持 CentOS / RHEL / Ubuntu 以及 Debian 的操作系统，并支持 sysdig 和 perf 工具

请查看 kops 发布页面 以获取有关最新和最棒的 kops 版本的信息。

总结

简而言之，我们对未来的路线图感到兴奋，将在即将发布的版本中为您带来许多这些改进。我们希望这将使入门体验更加轻松，并促使 Kubernetes 的采用率提高。

感谢所有反馈和贡献。希望这能让您了解我们正在做的事情，并鼓励您参加我们的会议并与我们打招呼！