译自：How Kubernetes Became the New Linux
亚马逊EKS的首席项目经理Jesse Butler在KubeCon + CloudNativeCon North America上分享了他的观察：“我认为Kubernetes现在到了一个类似于Linux发展的阶段。我们已不再需要构建自己的定制化集群API服务器和控制平面，而是转向寻找标准来大规模构建我们的企业平台。” 他的核心观点是：Kubernetes不再专属于某个细分市场，它正在被各行各业普遍采用，成为一种企业级标准。
这种普遍性正在深刻改变着像亚马逊云科技（AWS）这样的巨头参与开源的方式。AWS近期通过Kubernetes社区的不同特别兴趣小组捐赠了两个开源项目：Kubernetes资源编排器 和 Karpenter。更重要的是，这揭示了AWS为何将它们构建为Kubernetes生态系统的原生功能，而非独立产品，以及这种转变对整个云原生生态系统意味着什么。
当“胶水代码”演变为技术债：Kro的诞生
Kro项目的催化剂，源于AWS观察到的客户在“控制器泛滥”方面遇到的困境。随着自定义资源定义（CRD）让将云基础设施、网络等各种资源表示为Kubernetes对象变得轻而易举，组织开始大量构建自定义控制器来粘合这些资源。
“我们的一些客户，即使在四五年前，也管理着20到30个不同的自定义资源，” Butler指出。“在一个大型组织里，这意味着需要一个小团队专门维护这些‘胶水代码’，而这部分代码甚至不包含核心业务逻辑。”
Kro的诞生就是为了解决这个问题。它旨在自动生成CRD以及一个轻量的微控制器来管理它。平台工程师只需使用Kro的Simple Schema，通过YAML定义他们想要聚合的资源组合。Kro会自动推断依赖关系，生成有向无环图，并处理底层编排。这本质上是一种“控制器即服务”的模式，且完全在Kubernetes生态内完成，无需引入外部复杂系统。
无人愿解的节点配置难题：Karpenter的破局
Karpenter则源于一个不同的运维痛点：传统的集群自动扩缩器难以跟上云原生工作负载的动态变化。“云原生工作负载往往是突发性、不可预测的，” Butler解释道。基于历史数据预测容量需求的传统方法很快会失效。
Karpenter提供了解决方案：即时节点配置。它不仅能根据实时需求进行秒级伸缩，还集成了成本优化算法，例如智能选择实例类型和利用 spot 实例。其流行的另一个关键因素是优雅的API设计。正如Butler所说：“Karpenter的API允许你实现极简的配置——比如‘给我一个节点’——也可以深入到节点配置的每一个细节。” 这种灵活性结合实实在在的成本节省，推动了其快速采用，并最终促使其被捐赠给Kubernetes SIG Autoscaling。
哲学转变：构建面向整个生态的解决方案
无论是Kro还是Karpenter，都反映了AWS在开源贡献哲学上的一次重要转变：从构建仅服务于AWS客户的解决方案，转向构建适用于整个Kubernetes生态系统的通用方案。
“在Kubernetes和云原生软件的语境下，我们身处一个社区，所有人都是用户，” Butler强调。“我们不能只为自己的云产品构建功能，然后简单地称之为‘Kubernetes方案’。”
这种转变促使AWS更倾向于将成熟的项目捐赠给Kubernetes社区内部的SIG，而不是创建独立的CNCF沙箱项目。这标志着Kubernetes从一个基础的容器编排工具，真正演进为一个成熟、可扩展的企业平台标准的必经之路。最成功的开源项目正是通过这样的社区协作和功能内化，最终走向成熟和普及，正如当年的Linux发行版一样。 | 
发表于