这篇文章已超过一年。较早的文章可能包含过时内容。请检查页面中的信息自发布以来是否仍正确。

创建和管理 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 的引导；它绝不会处理机器的 Provisioning，因为这可以通过更多方式完成。此外，我们希望 kubeadm 能在任何地方工作，即使是在多种架构上，因此我们从一开始就内置了多架构支持。

kops 的范围是什么？
kops 的范围是自动化整个集群操作：安装、重新配置集群、升级 Kubernetes 以及最终的集群删除。kops 基于 Kubernetes API Machinery 具有丰富的配置模型，因此你可以轻松根据需要自定义一些参数。kops（与 kubeadm 不同）为你处理资源的 Provisioning。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（及其他工具）使用它们。

我们还将通过向 controller manager 添加一个新的控制器 BootstrapSigner，使我们当前使用的 token discovery (即 gcr.io/google_containers/kube-discovery:1.0 镜像) 升级到 beta。使用作为 Secrets 管理的 token，该控制器将对新 kube-public 命名空间中一个已知 ConfigMap 的内容（一个 kubeconfig 文件）进行签名。该对象将对未认证的用户可用，以便通过一个简单短小的共享 token 实现安全引导。你可以在此处阅读完整的提案。

除了可以单独调用各个阶段之外，我们还将添加一个新的阶段，用于在自托管模式下启动控制平面（与当前的静态 Pod 技术不同）。自托管技术由 CoreOS 以 bootkube 的形式开发，现在将作为一种替代方案整合到官方 Kubernetes 产品中。感谢 CoreOS 推动了这种模式！实现方法是：首先使用静态 Pod 搭建一个临时控制平面，根据需要注入 Deployments、ConfigMaps 和 DaemonSets，最后关闭临时控制平面。目前，etcd 默认仍将在静态 Pod 中运行。

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

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

最后，在安全性方面，我们也希望 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 从 HEAD 测试 Kubernetes。

2017 年及以后

除了上面提到的所有内容，我们希望 kubeadm 成为一个简单易用的生产级 (GA) 工具，用于引导 Kubernetes 集群。我们希望 HA/多主节点在跨平台方面比现在更容易实现（尽管 kops 目前在 AWS 上已能轻松实现！）。我们希望云提供商插件能移到树外并可独立安装。kubectl apply -f my-cloud-provider-here.yaml 应该可以直接工作。文档应该更完善、更深入。Container Runtime Interface (CRI) 和 Federation 应该能与 kubeadm 很好地协作。应移除过时的入门指南，以免误导新用户。

重构云提供商集成插件
目前，云提供商集成被内置在 controller-manager、kubelet 和 API Server 中。这与 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
  • 实现了 预检（Preflight checks），如果环境无效则快速失败 #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 的普及度。

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