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

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

作者：Lucas Käldström (独立开发者) |

上次您听到我们的消息是在九月，当时我们宣布了 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 Machinery 的丰富配置模型，因此您可以轻松地根据自己的需求定制一些参数。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 引导 API、证书 API 和 ComponentConfig API 推向 beta 版，并让 kops（和其他工具）使用它们。

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

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

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

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

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

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

v1.6 的理想功能包括一个官方的 CoreOS Container Linux 安装程序容器，它执行 debs/rpms 为 Ubuntu/CentOS 所做的工作。总的来说，扩展发行版支持会很好。我们还希望采用 Kubelet 动态设置，以便传递给 kubeadm init 的配置自动流向节点（目前需要手动配置）。我们希望通过使用 kubeadm 可以测试 Kubernetes 的 HEAD 版本。

2017 年及以后

除了上述所有内容，我们希望 kubeadm 成为一个可用于引导 Kubernetes 集群的生产级（GA）工具。我们希望 HA/多主节点在不同平台上比现在更容易实现（尽管 kops 现在在 AWS 上已经很容易实现！）。我们希望云提供商能够脱离树，并可单独安装。_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 的仓库将作为官方验证的云提供商发展和存在的地方，但那里的所有提供商都将彼此独立。（issue #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 集群
  • 除了 Debian 之外，还支持 CentOS / RHEL / Ubuntu 操作系统，并支持 sysdig 和 perf 工具

前往 kops 发布页面以获取有关最新和最出色的 kops 版本的信息。

总结

简而言之，我们对即将发布的版本中将为你们带来这些改进感到兴奋。我们希望这将使入门体验更加轻松，并促进 Kubernetes 的广泛采用。

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