\n\n虚拟集群技术助平台团队消除Kubernetes控制平面隐性高成本。利用vCluster、Kamaji、k0smotron等工具，实现开发者自助服务与环境隔离，优化管理，并革新基础设施与应用开发模式。
译自：How platform teams are eliminating a $43,800 "hidden tax" on Kubernetes infrastructure
作者：Janakiram MSV
按需配置 Kubernetes 集群、具备完整的API访问权限、自定义RBAC和隔离的资源命名空间的能力，定义了现代平台团队所指的开发者自助服务。如果缺乏这种能力，平台团队最终会成为每个环境的守门人，串行处理本应并行的请求，并承担随着每个新租户而增加的控制平面成本。借助虚拟集群技术，平台团队可以配置数十个隔离的Kubernetes环境，而无需启动任何额外的控制平面。
这些模式反映了平台工程师在服务器虚拟化时代已经经历过的一次转型。在管理程序出现之前，每个工作负载都需要自己的物理机器。成本是显而易见的，但更深层的问题是供应速度和隔离粒度。VMware及其同行不仅降低了硬件开支，他们还改写了团队对工作负载边界的思考方式。虚拟集群正在对Kubernetes基础设施做同样的事情，推动这一转变的工具是vCluster、Kamaji和k0smotron。
Kubernetes基础设施的隐性税
一旦写下来，计算就很简单了。Amazon EKS上托管的Kubernetes控制平面每小时收费0.10美元，这意味着在运行任何Pod之前，每个集群每年大约需要876美元。对于管理50个开发、测试和生产环境集群的平台团队来说，这是一笔每年43,800美元的控制平面开销，这笔成本不会出现在任何单一预算线上，而是累积在各个团队、环境和租户之间。
当团队根据环境、地理、安全边界和租户进行划分时，问题会更加复杂。每个曾经看起来架构清晰的划分决策都变成了一个费用项目。平台团队了解这些成本，但共享命名空间会损害隔离性，而独立的完整集群则会使成本倍增。中间地带曾经不存在。
“Amazon EKS上托管的Kubernetes控制平面每小时收费0.10美元，这意味着在运行任何Pod之前，每个集群每年大约需要876美元。对于管理50个集群的平台团队来说，这是一笔每年43,800美元的控制平面开销，这笔成本不会出现在任何单一预算线上，而是累积在各个团队、环境和租户之间。”
虚拟集群占据了这个中间地带。它们以功能完整的Kubernetes集群形式呈现给使用它们的租户，拥有自己的API服务器和资源模型，同时作为工作负载运行在底层的共享宿主集群上。控制平面税费降至接近零，隔离保证得以保留，平台团队保留了单一的物理基础设施足迹进行操作和计费。
vCluster与命名空间范围的方法
vCluster是Loft Labs的一个开源项目，它将一个虚拟Kubernetes集群作为一组Pod运行在宿主集群的命名空间内。每个虚拟集群都有自己的API服务器、调度器和控制器管理器。租户通过标准的kubeconfig与虚拟集群交互。从他们的角度来看，他们拥有一个真实的集群，与宿主之间没有可见的缝隙。
将vCluster想象成一座大型建筑中的租户公寓。建筑的结构系统、电网和共享服务是宿主集群的节点和网络。每个公寓都有自己的上锁门、自己的布局和自己的钥匙。租户无法访问建筑的机械室，而建筑经理也不管理租户的家具。这种职责划分正是vCluster如何将平台运营商和应用程序团队的关注点分开的方式。
考虑一个拥有数十个微服务团队的金融科技组织，每个团队都需要一个Kubernetes环境进行集成测试。有了vCluster，创建一个新的开发环境只需创建一个命名空间即可。团队可以获得完整的API访问权限，可以安装自定义资源定义（CRD），并且可以运行自己的准入控制器，所有这些都可以在平台团队运营一个宿主集群且没有人为十几个空闲控制平面付费的情况下完成。
vCluster在虚拟集群和宿主之间同步最少量的资源。Pod通过同步层实际运行在宿主集群的节点上，整合计算利用率同时保持API级别的隔离。存储、网络和节点可见性保留在宿主上，对租户不可见。
开发者自助服务环境
vCluster非常适合需要开发者预置短暂环境而无需等待平台团队介入的平台。CI/CD流水线可以在集成测试运行开始时创建一个vCluster，并在完成后销毁它，只需为环境存在的几分钟付费。
自定义资源定义（CRD）隔离
当多个团队需要安装冲突的CRD版本时，共享命名空间模型就会失败。vCluster为每个团队提供独立的API注册表，消除了多租户Kubernetes部署中导致大量摩擦的版本冲突问题。
培训和实验集群
运行内部Kubernetes培训项目的组织可以为每个参与者预置vCluster实例。受训者可以在不影响其他人的情况下破坏他们的环境，讲师在会话结束时销毁所有实例，不在宿主上留下任何遗留资源。
虚拟集群在同一个包中提供了工作负载隔离边界和控制平面成本降低，以命名空间的预置速度提供专用集群的API完整性。
Kamaji与大规模托管控制平面
Kamaji以不同的方法解决相同的问题，它将Kubernetes控制平面从专用节点移出，放入管理集群中，并在其中作为常规Pod运行。vCluster通过命名空间范围的虚拟化实现开发者自助服务，而Kamaji则针对运营大量集群的基础设施团队，这些团队需要生产级的租户隔离，但又不想增加每个租户的基础设施开销。
这里的类比从公寓转向了数据中心托管。在托管设施中，客户租赁机架空间和电力，但无需拥有建筑物。设施运营物理层；客户运营其笼子中的一切。Kamaji为平台团队提供了相同的分离。管理集群是托管设施。租户控制平面是客户的笼子，由专业管理，单独计量，并且彼此之间操作不可见。
考虑一个托管Kubernetes服务提供商，它希望为企业客户提供专用集群，但又不想为每个客户控制平面预置单独的虚拟机。有了Kamaji，每个客户都可以获得一个在提供商管理集群中作为Pod运行的专用API服务器。客户正常连接其工作节点并操作其集群，而无需了解共享基础设施。提供商可以在以前只能运行三个集群的硬件上管理数十个控制平面。
Kamaji支持多租户etcd，其中单个etcd集群通过不同的前缀服务多个托管控制平面。它与Cluster API集成，这意味着平台团队可以通过他们用于管理车队中所有其他内容的相同声明式工作流来管理Kamaji托管的控制平面。
托管Kubernetes服务提供商
当提供商希望在不增加每个客户基础设施开销的情况下提供每个客户的集群隔离时，Kamaji是正确的工具。管理平面保持精简；客户获得标准的Kubernetes体验，拥有自己的API服务器和RBAC边界。
多租户SaaS基础设施
将客户特定工作负载部署在隔离的Kubernetes环境中的SaaS平台可以使用Kamaji在API级别完全分离这些环境，同时在共享计算资源上运行它们。无需进行每个客户集群的预置周期，即可满足客户数据隔离的合规性要求。
大规模车队管理
在边缘、区域和云部署中管理数百个集群的组织使用Kamaji来集中控制平面操作。升级控制平面变成了Pod替换，而不是节点清空和重新预置，显著缩短了维护窗口。
k0smotron与Cluster API原生虚拟化
k0smotron是一个基于k0s构建的Kubernetes操作器，它将托管控制平面作为Kubernetes原生资源进行管理。它从一开始就设计为与Cluster API兼容，将托管控制平面管理视为一流的基础设施自动化问题，而不是在现有工具之上叠加的操作性变通方法。
将k0smotron视为虚拟化控制平面概念之上的基础设施即代码层。如果vCluster是公寓楼，Kamaji是托管设施，那么k0smotron就是与您现有自动化工具链集成的楼宇管理系统。您声明控制平面车队的期望状态；k0smotron通过标准Kubernetes控制器进行协调。
使用Cluster API的平台团队添加k0smotron来在其管理集群中托管控制平面。AWS、Azure或本地的工作节点池通过标准Cluster API MachineDeployments连接。整个车队，包括托管控制平面和分布式工作节点，都以YAML形式表达，并通过团队已经操作的相同GitOps流水线进行管理。
k0smotron支持远程机器提供商，这意味着工作节点无需与管理集群共置。这使得混合和边缘场景变得实用，在这些场景中，控制平面位于中央数据中心，而工作节点运行在分支机构或边缘位置。
混合和边缘部署
k0smotron的远程机器支持使其成为集中控制平面管理地理分布式工作负载架构的正确工具。控制平面保留在连接良好的数据中心；工作节点运行在工作负载需要的地方，站点之间无需VPN隧道或私有链接。
GitOps驱动的集群生命周期管理
已经使用Cluster API进行基础设施自动化的团队可以采用k0smotron而无需改变其工作流。控制平面预置变成了与管理节点池、网络策略和存储类相同的存储库中的YAML声明，保留了团队已经依赖的单一事实来源。
托管控制平面的统一可观测性
k0smotron通过标准Kubernetes API公开控制平面健康状况和API服务器延迟。运行数十个托管控制平面的平台团队可以从单个Grafana仪表板监控整个车队，而无需为每个环境定制指标收集器。
这三种工具从不同角度解决了相同的核心问题，正确的选择取决于团队在组织中的位置以及他们正在优化的目标。vCluster适用于需要快速、短暂、面向开发者的环境且操作开销最小的团队。Kamaji适用于运营生产级、多租户车队，其中控制平面可靠性和etcd管理是首要关注的基础设施团队。k0smotron适用于已经投入Cluster API和GitOps工作流的团队，他们希望托管控制平面像任何其他基础设施资源一样运行。
| 工具 | 部署模型 | 主要受众 | Cluster API 原生 | 最佳适用场景 |
|---|---|---|---|---|
| vCluster | 宿主集群命名空间内的Pod | 平台团队、开发者 | 否 | 短暂的开发/测试环境、CRD隔离、自助服务门户 |
| Kamaji | 管理集群中作为Pod的控制平面 | 基础设施运维人员、托管服务提供商 | 是 | 生产级多租户车队、托管Kubernetes产品、SaaS隔离 |
| k0smotron | 声明为Kubernetes资源的托管控制平面 | 平台工程师、GitOps团队 | 是（一流支持） | 混合和边缘部署、GitOps驱动的集群生命周期管理 |
生产环境经常结合多种方法。平台团队可以为生产租户集群运行Kamaji，同时使用vCluster从同一宿主基础设施为开发者自助服务环境提供服务。这些工具是可组合的，而非互斥。
“采用虚拟集群技术的平台团队不仅是在削减云账单，他们还在改变平台基础设施与应用程序开发之间的关系。”
虚拟集群为平台团队带来了什么
成本论证开启了对话，但操作论证使其得以结束。采用虚拟集群技术的平台团队不仅是在削减云账单，他们还在改变平台基础设施与应用程序开发之间的关系。当预置集群的成本是命名空间成本而非控制平面成本时，开发者自助服务（团队无需提交工单即可预置Kubernetes环境）在操作上变得可行。集群蔓延曾是一个治理问题，现在却成了一个特性。团队在需要时启动环境，在不再需要时将其拆除。
租户隔离也达到了新的精度。在共享命名空间模型中，配置错误的CRD或过度预置的LimitRange会影响集群中的每个团队。虚拟集群为每个租户提供了API级别的影响范围边界。租户可以耗尽其配额、安装冲突的Operator版本或破坏其准入控制器，而不会触及其他任何人的环境。对于管理多租户SaaS基础设施或内部开发者平台的团队来说，这种隔离保证是安全自助服务的前提，而不是可有可无的特性。
由此产生的组织模式有时被称为“管理集群加虚拟集群车队架构”。一个由平台团队操作的物理集群，托管数十个由应用程序团队使用的虚拟集群。成本分摊变得精确，隔离通过构建强制执行，控制平面账单不再随人数线性增长。
虚拟集群为Kubernetes带来了与服务器虚拟化为裸机带来的相同的经济效益：固定的物理足迹、弹性的逻辑容量，以及一个随组织而非与组织对抗而扩展的治理模型。
下一步
对于平台工程师来说，这里的模式很熟悉。vCluster的行为类似于具有完整API表面的命名空间。Kamaji类似于控制平面的托管服务模型。k0smotron作为集群生命周期管理的基础设施即代码层。它们共同代表了行业对Kubernetes租户思考方式的成熟，从每个关注点一个集群转向每个车队一个控制平面。
随着平台团队转向内部开发者平台和自助服务基础设施门户，集群预置的经济效益成为这些平台是否真正被使用的核心。虚拟集群技术将这种摩擦降至接近零。下一个问题是这些托管控制平面如何与更广泛的平台编排框架集成，以及当任何开发者都能在几秒钟内预置一个集群时，治理和策略执行会是什么样子。敬请关注。全 工智能
