将 Kubernetes 控制平面作为 Pod 托管可以为多集群和边缘用例启用（并简化）操作。但是，会带来一些新的要求和问题。而且标准可能来得比较慢。

译自 Simplify Kubernetes Hosted Control Planes with K0smotron，作者 Jussi Nummelin。

本文是 Jussi 将在 3 月 21 日发表 KubeCon+CloudNativeCon EU 的演讲的预览。

多集群

Kubernetes 变得复杂且昂贵——尤其是在动态环境中。私有云多集群解决方案需要协调许多活动部分：

私有或公有云 API 和计算/网络/存储资源（或裸机管理）Linux 和 Kubernetes 依赖项Kubernetes 部署etcd 配置负载均衡器集成

而且，可能还有其他详细信息。因此，它们很脆弱——私有云上的 Kubernetes 控制平面往往会变成“宠物”（而不是可爱的这一面）。与此同时，公有云上的多集群隐藏了一些复杂性问题（以牺牲灵活性为代价）——但带来了集群激增、难以预测的成本和锁定等挑战。

托管控制平面 (HCP) 是什么？

托管控制平面 (HCP) 绕过了一些（并非全部）这些挑战，同时带来了一些新的挑战。HCP 是一组 Kubernetes 管理器节点组件，在主机 Kubernetes 集群 上的 Pod 中运行。HCP 更像“牲畜”，而不是“宠物”。

与其他 Kubernetes 工作负载一样，它们在代码（YAML 清单）中定义、操作和更新——因此具有可重复性、可版本控制、易于标准化。但是，与往常一样，工作节点需要驻留在某个地方并连接到控制平面，这里有几个挑战。它们从 Kubernetes 本身获得了基本的弹性：如果 HCP 死亡，Kubernetes 会将其带回，并且负载均衡器会将 API 和工作程序流量定向到新实例。还可以将 HCP 控制平面配置为横向扩展以实现强大的高可用性，但这可能涉及一些新的挑战。HCP 共享工作负载入口、负载均衡和其他与母舰集群集成的服务，消除了将这些服务集成到各个多集群控制平面的需要。但是，也就是说，母舰集群变成了许多控制平面的潜在单点故障，因此如果需要高可用性，则需要仔细构建它。

因此，总体而言，使用 HCP 可以显著简化多集群——减少资源消耗，提高利用率，并整合整体 Kubernetes 占用空间。原则上，HCP 可以为从经典多集群到混合、边缘和物联网的用例提供运营效率。但实现收益意味着克服挑战——这取决于特定 HCP 解决方案的设计方式、自动化方式及其主机集群。

HCP 的技术挑战

Controller/Worker 网络互联。在典型的 Kubernetes 集群中，容器网络接口（CNI）网络跨越控制器和工作程序。对于合并的集群架构来说，这使得事情变得简单，但如果你想构建分布式架构（NAT、防火墙等），则会变得更加复杂。

在 HCP 集群中，控制平面是在母舰集群上运行的工作负载，而工作程序通常设置在它们自己的单独 CNI 上。因此，你需要在 HCP 的 API 服务器和工作程序节点的 CNI 之间启用安全连接。并且它需要健壮且易于设置和管理，因为许多有趣的用例（更多内容如下）取决于能够将工作程序基本上放在任何地方（边缘位置、移动位置和连接等），可能在低质量和/或不安全的网络链路的另一端。

历史上，SSH 隧道用于建立这种连接。最近，Konnectivity Kubernetes 子项目 提供了一个高效的解决方案（尽管仍有一些缺点——见下文）。并且 Kubernetes 提供了一个用于配置这种外部连接（egress-selector）的抽象。但是，如何在实践中建立连接取决于 HCP 的实现方式：当前的项目/产品以多种不同的方式执行此操作。

构建和维护工作程序节点。 为 HCP 设置工作程序节点显然可以通过多种不同的方式完成，具体取决于不同的情况。其中包括（部分列表）：

在与托管母舰集群相同的公共或私有云架构上的虚拟机上构建工作节点——在同一 VPC 内或其他 VPC 中（例如，为了在所需的地理区域或监管制度内确定性地放置工作节点和关联的持久性数据）在与托管母舰集群不同的云架构（例如，像 OpenStack 这样的私有云架构）上的虚拟机上构建工作节点在由支持母舰的 IaaS 管理的裸机上构建工作节点，或在远程（和/或不同的）IaaS 上构建工作节点（例如，在配备了 Ironic 裸机管理 的 OpenStack 云 上）在远程裸机上构建工作节点，在集中式裸机管理系统或独立系统下，甚至……在母舰集群本身上构建工作节点，使用 KubeVirt 在 Kubernetes 上托管虚拟机 + 主机操作系统 + 工作节点

无论用例决定采用哪种策略，在这一点上，最吸引人的做法是考虑使用 Kubernetes 自身的集群 API 设施通过安装在母舰集群（或其他地方，例如堡垒服务器上）的 CAPI 运营商来完成此设置——理想情况下，在所有相关的目标环境中。

现在，使用虚拟服务器作为节点对于存在 CAPI 提供商的私有云和公有云来说很容易实现。只要您有系统的方法来解决上面提到的网络挑战，这一切都很简单。因此，“集中式、云驻留多集群”用例已经很好地掌握。

然而，对于裸机——边缘和物联网用例必不可少——情况并没有那么标准化，实际上在很大程度上取决于具体情况。在配置了 Ironic（裸机管理）的 OpenStack 上，CAPI（通过 OpenStack 提供商）可以利用 Ironic 来配置裸机服务器。

对于没有 OpenStack 集群的用户，metal3-io 项目是一个 CAPI 提供商，可以利用独立的 Ironic。对于希望在裸机节点上使用 Ubuntu 的用户，还可以使用采用 Canonical MaaS 来执行裸机管理的提供商。VMware BMA 旨在在物理节点上安装 ESXi 裸机管理程序，目前还没有 CAPI 提供商可以实现此功能。

此外，即使对于工作范例，这些设置也都不简单——裸机管理系统通常需要 PXE 启动数据源，并且对节点有其他本地要求。因此，它们都更适用于数据中心应用程序（尤其是在您可能出于性能原因需要裸机的情况下），对于真正的边缘应用程序来说有点太繁重——对于物联网来说肯定太繁重了。同样，这是一个需要社区关注以开发广泛有用的通用解决方案的领域。

一旦您配置好基础设施，就可以使用 kubeadm 或其他工具再次创建 HCP 工作节点。然而，有很多话要说，让它尽可能简单且关键步骤尽可能少（这是 kubeadm 所没有的），并且让工作节点创建成为可能（而且再次简单），而无需互联网访问。

水平扩展 HCP 可能有点复杂。Kubernetes 可以确保在 HCP 发生故障时重新启动它。只要导致 HCP 发生故障的原因不会损害其持久性存储，并且提供了一个负载均衡器来帮助将工作节点通信和 API 命令路由到新的 HCP 实例，这种方法就能很好地发挥作用。

但是，如果您需要水平扩展 HCP——为了获得性能或真正的可用性——通常会有一些注意事项。第一个是 etcd，它难以配置且很挑剔。因此，一些 HCP 解决方案要求您使用 Kind 将 etcd 替换为 SQL 数据存储（例如 Postgres）。

第二个挑战是您还需要扩展工作节点连接到控制平面的系统。超越一个控制器实例，您现在需要在工作节点和可用控制器之间建立一个一对多的连接网格。一些连接方法（如 Konnectivity）允许这样做，但方式非常复杂。

“母舰”集群提供共享服务，但可能会成为单点故障。托管 HCP 的“母舰”集群的基本要求并不难满足。您需要提供一个负载均衡器，以一种能够在 HCP 重启后继续存在的方式公开 HCP API。您需要启用持久性卷，以便 HCP 可以在节点重启后调用状态。

但是，为了满足更高级别的可用性要求，您需要进行更多的工程设计——因为母舰是一个单点故障，最终可能托管大量（可能是关键的）控制平面。这些是您在设计/配置 Kubernetes 上任何高可用工作负载时需要考虑的相同必需品。

您可能希望将母舰控制器和工作节点分布在三个或更多个可用性区域 (AZ) 的奇数个中（以满足 Kubernetes 法定人数要求），并确保持久卷的存储具有弹性，在 AZ 故障后仍可访问，并且持久卷在所有 AZ 中镜像（以便在 AZ 故障时，重新启动的控制平面可以找到其存储）。

如果您的母舰集群将使用 etcd 进行状态管理（而不是 Kind+SQL 或其他更能容忍延迟的状态数据库），您还需要确保 AZ 之间的网络链接延迟不超过 5 毫秒（以避免影响 Raft 共识）。还需要评估和根据需要应用许多其他构建高可用性和安全 Kubernetes 集群的最佳实践。

有趣的是，鉴于母舰集群具有高可用性，您实际上可能不需要横向扩展 HCP，因为母舰实际上确保了功能控制器和工作节点的生存能力，可以在其上重新启动故障的 HCP 实例。但是，如果您也需要 HCP 具有高可用性，则需要更进一步，使其以奇数（3+）横向扩展，并配置各项内容，以便每个 HCP 的控制器进入不同的 AZ。（注意：如果使用 Kind+SQL 来维护状态，则可以放弃“始终为三个或更多，始终为 Raft 共识的奇数”要求，这可能会让您在确定需要多少个控制器时拥有更大的自由度。）

当然，有一些折衷方案可以使母舰集群非常有弹性，而无需达到高可用性所需的程度。例如， Mirantis 经常使用 Velero，这是一种了解工作负载的集群备份工具，可以获取集群的全部内容，包括存储，并将“快照”保存在安全的地方（例如，Amazon Web Services 的 S3 存储桶中）。如果集群发生故障，您可以重建它，安装 Velero，然后重新安装快照。不过，没有免费的午餐：让 Velero 在某些场景中发挥作用可能要求开发人员特别注意卷存储和数据库。

自动化 HCP 设置并保持其简单性是一件难事。大多数当前的 HCP 解决方案利用 Kubernetes 运营商将 HCP 作为自定义资源提供支持。除此之外，每个人都以自己的方式做事，运营商所需的复杂性将反映首选的部署策略、使用的 Kubernetes 集群模型、通信架构、HA 要求和其他详细信息。总体而言，挑战在于尽可能保持 HCP 配置文件简单且简短，以便运营商无需在意（当然，也无需修改）1000 行 YAML 即可启动并运行 HCP 或执行应为简单操作的操作。而且，总有一些事情是运营商无法知道的，需要在配置文件中指定。例如，运营商无法检测到母舰已与实现负载均衡器的某个内容集成。

现在，我们已经回顾了挑战，让我们看看开源如何提供帮助。

k0s 和 k0smotron 如何处理 HCP

Mirantis 的开源项目 k0s Kubernetes 和 k0smotron HCP 运营商 提供了托管控制平面解决方案的基础知识，该解决方案可以很好地适应许多不同的用例。以下是 k0s/k0smotron 的一些重要亮点。

K0smotron 将在任何 云原生计算基金会 验证的 Kubernetes 上运行，因此它限制了用户获取和运行母舰集群的方式。任何公共云 Kubernetes 都可以使用，DIY “上游”Kubernetes 设置和企业 Kubernetes 解决方案提供商提供的 CNCF 验证的 Kubernetes 平台也可以使用。

但是，k0smotron 仅安装基于 k0s Kubernetes 的 HCP，这些 HCP 将与使用相同版本 k0s 的工作节点集成。这样做有几个重要原因。

K0s 是一个零依赖项的 Kubernetes 发行版，可以通过单个二进制文件下载和几个简短命令安装在任何节点（控制器或工作节点）上——安装 k0s 及其工具，在分配的角色（例如，工作节点）中启动节点，检索凭据并连接到控制平面。零依赖项极大地简化了为 Kubernetes 安装准备操作系统的工作（对于大多数流行的企业级 Linux 变体，您只需运行更新即可）。这意味着构建、配置、启动和附加工作节点的工作非常简单，并且与几乎任何类型的自动化工具（包括 Cluster API——见下文）兼容。K0s 是一款极简（但灵活）的多平台发行版，可以在 x86-64、ARM64 和 ARMv7 硬件上从单个二进制文件进行安装和运行。一个 k0s 工作节点可以在一个 CPU/vCPU 上很好地工作，只需 0.5GB 的 RAM 和 1.3GB 的存储空间（首选 SSD）。因此，k0s 为您提供了最大的自由度，可以将应用程序构建到边缘及更远的地方。K0s 使用 Konnectivity 来启用控制平面/工作节点分离，即使在使用 k0s 以正常方式构建标准集群时也是如此。因此，“开箱即用”，k0s 极大地简化了 HCP 使用案例中可能遇到的网络挑战。在许多远程工作节点网络场景（NAT 等）中，它都能正常工作。K0s 知道如何在将控制器扩展到 HA 配置的同时水平扩展 Konnectivity，因此实现 HA 只需扩展容器化控制器并告知配置的负载均衡器将入站数据包适当地转发到 APIserver 和 Konnectivity 端口即可。K0s 确实需要 Kind+SQL 来扩展 HA 控制平面，但如上所述，不使用 etcd 允许放弃 etcd 对 Raft 共识的要求，这意味着 2 个以上的控制器可以工作，偶数个控制器也可以，并且控制器间延迟要求不那么严格。K0s 具有一个集群 API 运营商，可以很好地编排公共和私有云上工作节点的基础设施，并基于开源 k0sctl 集群部署工具引入了一个基本的通用裸机部署提供程序。这为构建和操作完全以 Kubernetes 为中心的 Kubernetes 多集群环境打开了大门。

图 1. k0s 控制器/工作节点分离和简单、稳健的控制器/工作节点网络是在 Kubernetes Konnectivity 子项目的帮助下完成的。

为什么不将这一切标准化？

标准化 HCP 的想法非常有吸引力。这也很困难——部分原因是不同的组织有不同的优先级。最大的问题是，您在 HCP 解决方案中使用的 Kubernetes 非常重要。k0s 和 k0smotron 适用于 HCP（而且很简单），因为 k0s 专门设计为零依赖项，可以在各种硬件上运行，并使用 Konnectivity 实现控制器/工作节点分离。这使得构建 k0smotron 变得更简单。它简化了与集群 API 的构建和集成。它为用户提供了最大的支持，用于构建和运行 HCP 应用程序，而无需强迫他们掌握和构建大量复杂性。

HCP 的技术和业务驱动因素是什么？

尽管有上述挑战，托管控制平面解决方案具有巨大的潜在优势。

HCP 高效地支持许多用例，包括多集群、多云、混合云、边缘，甚至物联网——所有这些都在自管理或第三方管理的上下文中。集中式控制平面（因此，集中式操作）和分布在任何地方的分布式工作节点是一个强大的支持命题，无论您的目标是为团队提供自助服务 Kubernetes 还是设计边缘应用程序以在数千个位置或客户站点上的工作节点上运行。

在其他架构优势中，它为您提供了很大的自由度，可以决定计算发生在哪里以及数据驻留在哪里，同时允许规模经济和集中控制以进行操作和开发，因为平台工程师、运营商、开发人员和其他人员都通过母舰控制集群。所有这些都有助于提高成本效益、时间效益、安全性以及与在许多环境中使用独立集群的传统策略相比的标准化。

整合和简化

以这种方式在 Kubernetes 上整合托管控制平面（并使用集群 API 进行基础设施管理）——将 Kubernetes 视为您的云——也有巨大的优势。显然，它更快、更简单。您有一个 API 来控制。一个“平台工程和运营环境”进行调整。一个自动化模型——Kubernetes HCP 集群和相关清单——进行维护和版本控制。这带来了清晰度、标准化、优化和重用。它减少或消除了直接管理基础设施的“增加技能负担”。所有这些都有助于减少运营开销，提高效率和速度，并最大程度地降低安全和合规风险。

标准化平台服务

与 HCP 集成意味着不再需要构建和维护大量独立集群，这是繁琐、复杂、风险和成本的巨大来源。减少您的整体 Kubernetes 占用空间简化了平台工程，并鼓励在所有 HCP 和应用程序都可以共享的一组平台服务上进行标准化。而这反过来又鼓励采用 DevOps 和开发人员可以共享的标准工具和工作流。结果：每个人都可以专注于真正重要的事情——平台不断优化，开发人员的生产力更高，应用程序更安全、更合规、更具弹性。

改进访问、安全、合规

在整合模型中，安全性更易于架构和管理——提高安全状态的清晰度和可见性，并减少导致漏洞的错误和遗漏的可能性。主机集群访问控制保护 HCP API。您有一个要管理的 IAM 框架（Kubernetes RBAC）和一个机密存储（Kubernetes Secrets）。Kubernetes 和容器运行时策略可以在主机环境和 HCP 配置中标准化。

控制和灵活性

由于 HCP 实际上只是 Kubernetes 工作负载，因此您可以非常灵活地配置它们——比大多数公有云允许配置按需集群灵活得多。例如，您可以根据自己的喜好设置 Kubernetes API 功能标志——公有云通常不允许这样做。

简化的更新和升级

与维护遍布各处的独立集群的混乱相比，整合的 HCP 模型使更新（和升级）更易于管理且风险更低。要更新 HCP 控制平面，您只需更新其清单，然后重新应用以加载新的控制平面容器。

真实世界的 HCP 使用案例示例

一家公共部门组织最近找到 Mirantis，寻求帮助解决一项业务挑战：他们如何利用 k0s 和 k0smotron 为多个客户按需提供 Kubernetes 集群？

他们希望他们的解决方案仅包含开源组件，并且对 k0s+k0smotron 的简单性印象深刻。在 Broadcom 收购 VMware 以及对许可成本增加的担忧之后，该组织正在寻找一种衡量的方式来减少对专有技术的依赖。尽管如此，他们还是希望利用现有的 vSphere（一个已知数量）在虚拟机上托管他们的解决方案。

当然，这并不是障碍：k0s 在 VMware/ESXi 虚拟机 上运行良好，并且提供了适用于 VMware 的集群 API 提供程序。此外，由于该组织已在多个故障域中实施了 vSphere，因此 Mirantis 可以利用这一点使多集群解决方案具有高可用性：这是另一项客户要求。

图 2. 基于 k0s+k0smotron 的多租户/多集群解决方案的抽象架构。

该解决方案实现了一个 k0s“母舰”集群，为最终客户提供由 k0smotron 管理的 k0s 子集群。母舰将配置在共享负载均衡器之后，提供用于入口、安全、日志记录/监控/警报和遥测的标准服务，使服务提供商能够监控解决方案，并根据需要选择性地调用 Mirantis 以进行托管操作和主动维护。

还指定了一个 CI/CD 框架，用于促进母舰的 GitOps 风格操作。LMA/遥测和 GitOps 也可以安装在子集群中（使用变体清单），并作为增值服务提供给最终客户。在大多数功能方面（规模除外），这相当于公有云 Kubernetes 服务，但运行在虚拟化私有基础设施上。

母舰集群控制平面以 HA 模式部署，每个 AZ 中有一个节点。如前所述，这需要 AZ 之间具有低延迟链路以进行 etcd Raft 共识。子集群也可以以 HA 模式部署，其中容器化控制器节点和工作节点分布到所有 AZ——对于需要集群和应用程序高可用性的客户来说，这是一项有用的增值服务。母舰集群配备了备份和恢复以及外部共享弹性存储。

操作解决方案很简单：

运营商（通过自动化流程）使用 k0smotron 和集群 API 运营商创建 k0s 子集群，使用 VMware 提供商来配置工作节点，并使用子集群的 Kubernetes API 服务器地址更新负载均衡器。使用单个身份提供程序来管理对母舰和子集群的访问，利用 k0s 强大的 RBAC 机制——为最终客户配置了管理员角色。自动化检索子集群访问密钥并将其交付给最终客户。为了保护隐私和数据，密钥随后可以从母舰集群中删除。最终客户控制其子集群，并通过子集群的 API 或 kubectl 启用进一步的访问/权限。结论

托管控制平面标志着 Kubernetes 管理模式的转变。资源效率、集中式编排和新发现用例的好处展示了这种方法的变革力量。随着组织采用不断发展的部署场景，托管控制平面成为高效、可扩展且安全的 Kubernetes 编排之旅中的基石。

在 KubeCon + CloudNativeCon 加入对话

是否好奇深入了解托管控制平面以及 k0smotron 如何推动这一演变？参加由 Apple、Clastix、Red Hat 和 Mirantis 代表参加的托管控制平面的 Kubecon+CloudNativeCon EU 小组讨论。Mirantis 展位号为 J27：过来与行业先驱互动，探索实际应用，并参与塑造 Kubernetes 未来的对话。