导读

虽然开发人员可以独立构建Kubernetes应用程序，但配置云基础设施依赖项仍然是一个瓶颈，通常需要数周时间。将云基础设施封装在API中的目标一直具有挑战性，传统上需要具备编程和云基础设施技能的工程师。为了使API驱动的方法得到广泛采用，创建这些API必须简单且无需编码专业知识即可访问。本次会议探讨了基础设施作为Kubernetes API的趋势、对新工具的需求、真实客户使用案例以及如何入门。它还演示了如何使用ArgoCD、亚马逊云科技 Controllers for Kubernetes (ACK)和Gatekeeper等开源工具构建现代平台。

演讲精华

以下是小编为您整理的本次演讲的精华。

Christina Inov在亚马逊云科技 re:Invent 2024活动上的演讲深入探讨了不断演进的Kubernetes平台的复杂性，为观众呈现了一个引人入胜的故事情节，阐明了组织在实现平衡的组织变革过程中所面临的挑战和机遇。

Christina首先强调，高管在引导组织时有三个可用的杠杆:文化、技术和流程。在这三个方面中，技术通常被认为是最容易改变的，而流程则处于中间地带。然而，文化，通常被称为“我们在这里做事的方式”，无疑是最难以转变的，尤其是在由人类物种中富有独立见解的个体组成的工程组织中。

她接着生动地描绘了一幅不平衡的组织变革画面，其中三个杠杆都被拉到了最高程度。很多观众都能亲身体会到这种情况，因为他们在迁移到云端时曾经历过类似的过程。Christina回忆说，组织通常会从让几个团队获得访问亚马逊云科技控制台的权限开始，迅速创建EC2实例。然而，随着安全和合规团队的介入，开发人员被禁止直接访问亚马逊云科技，这导致了容器和平台(如EKS和ECS)的采用。

随着时间的推移，组织收购了拥有自己平台的公司，其中一些利用了无服务器架构。人工智能和机器学习的兴起进一步加剧了复杂性，将数据平台引入了这一混合体。Christina透露，平均而言，亚马逊云科技客户管理着7到8个不同的平台，这个惊人的数字凸显了整合和简化的必要性。

正如Christina所解释的，通常的做法是建立一个中央平台团队，负责基于Kubernetes进行标准化，因为它具有跨云和本地部署的能力。虽然从ECS迁移到Kubernetes看起来相对简单，因为它们共享容器基础，但当考虑到Lambda和ML平台时，挑战就出现了。即使在运行时标准化方面取得了成功，从开发人员体验的角度来看，未来的平台会是什么样子?

Christina生动地描绘了创建微服务及其关联数据库的典型开发人员工作流程。开发人员会调用各种管道，将一个管道的输出传递给另一个管道，收集网络细节、安全组ID、VPC ID和数据库凭证。理想情况下，安全团队会与数据库团队合作，不仅提供RDS数据库，还提供访问它所需的凭证。然后，开发人员会将RDS端点和密钥传递给Kubernetes管道，希望一切能够顺利运行，使微服务能够访问数据库。

然而，现实远非理想。开发人员常常会焦虑地等待，像鹰一样盯着数据库，因为如果有一个设置与合规性团队的政策不符，他们随时可能会将其抹去。这种情况凸显了管道方法固有的缺陷，它缺乏可组合性、自我修复能力和用于状态管理的单一事实来源。如果开发人员需要部署一个单一的微服务和一个数据库，可能需要花费半天时间才能让一切正常运行。

虽然对于不频繁的部署来说这可能是可以接受的，但Christina强调，对于大规模的工作，如扩展到新区域或将大型机迁移到亚马逊云科技，工作量将是巨大的，可能需要开发人员的整个职业生涯才能完成。观众能够感受到这种情况的严重性，认识到需要采用更好的方法。

Christina质疑管道是否适合于此目的，并建议使用可组合、自我修复且提供状态的API可能是一个更好的方法。她将之与互联网进行了类比，互联网运行在API之上，并举例说，通过API而不是调用管道来开设亚马逊云科技账户。

虽然为开发人员创建HTTP API是一项常见任务，每种编程语言都有许多框架可用，但Christina却遗憾地指出，在云基础设施方面缺乏API框架。这一空白促使一些大型组织探索使用Kubernetes自定义资源定义(CRD)，大约五年前，CRD已经达到了通用可用性(GA)。

这些组织认识到CRD可以作为API框架，提供内置权限、协调循环和开箱即用的机制等功能。然而，尽管在技术上是可行的，但挑战在于参与人员的技能。大多数平台工程师擅长大规模运营Kubernetes、管理开源项目以及使用Terraform和CloudFormation等基础设施即代码工具。但编写自定义控制器却不是他们的强项。相反，开发人员在编码环境中表现出色，但不太习惯于测试和排查Terraform管道的问题。

虽然Christina承认存在擅长编写控制器的平台工程师和精通Terraform的开发人员，但她强调这种“独角兽”人才实属凤毛麟角。支持由这些人才构建的平台将需要大多数平台工程师具备他们目前所缺乏的技能。

认识到这一差距，亚马逊云科技大约四年前创建了开源项目亚马逊云科技 Controller for Kubernetes (ACK)。该项目旨在为常见的亚马逊云科技服务(如S3和RDS)提供控制器，从而使组织无需自行创建控制器。在最初阶段，每个亚马逊云科技服务团队都负责维护各自的控制器，导致维护和支持方面存在不一致性。然而，今年早些时候，服务团队接手了所有控制器的维护工作，截至前一天，已有50个GA控制器，并获得了企业级支持。

为了说明如何使用ACK部署服务及其数据库，Christina解释说，需要安装一些控制器，如S3、EKS(用于Pod身份)和IAM。虽然这提供了创建S3存储桶、IAM角色和策略以及将它们连接起来所需的API，但还需要一个额外的构造来组合这些资源，并将复杂性从开发人员那里抽象出来。

Christina强调需要一种在资源之间执行逻辑操作、从一个资源传递字符串或参数到另一个资源以及实现条件语句的方式。虽然Helm可以部分解决这个问题，但编写自定义控制器被认为是一种“独角兽业务”，因为具备所需技能的人才实在太少。

经过多年与这些挑战的斗争，Christina宣布是时候有了更好的东西，她介绍了Cro，这是一个由亚马逊云科技开发的开源项目，旨在成为Kubernetes资源的“胶水”。她称赞Cro是利用Kubernetes资源模型构建具有开发人员友好界面的平台的最后一块拼图。

在这一点上，Christina邀请了EKS团队的软件工程师Amin加入她，Amin是Cro的创建者。Amin介绍了自己，并承认现场演示可能会出现问题，但向观众保证任何问题都可以解决。

Amin首先解释了在Kubernetes中部署应用程序的典型过程，包括创建部署、服务和入口来向世界公开它。传统上，开发人员会使用Helm等工具进行模板化，或使用Kustomize将资源组合在一起。对于勇敢的人来说，构建自定义控制器并将资源暴露为集群中的CRD也是一种选择。然而，Amin建议使用Cro作为这些方法的替代方案，允许开发人员管理自定义应用程序，而无需使用Helm、Kustomize或构建自己的控制器。

为了演示Cro的功能，Amin展示了如何指示Cro为Web应用程序提供CRD，在这里开发人员只需提供名称、端口、入口配置和镜像(默认为Nginx)。这是通过提交一个YAML文件来实现的，该文件配置Cro创建一个名为“web app”的CRD，并在后台开始提供应用程序。

该YAML文件定义了一个资源组，这是Kubernetes中另一个CRD，它充当配置Cro监听新对象和管理应用程序的入口点。在资源组中，Amin指定了所需的CRD版本和种类，以及一个OpenAPI模式，定义了用户输入的预期内容，如名称、命名空间、镜像、端口，以及是否启用入口或服务。此外，他还指示Cro使用CEL(通用表达式语言)表达式将某些字段(如部署条件、可用副本(一个数据点)和入口主机名)发布回用户。

CEL最近被引入API服务器，是一种类似于JSONPath但旨在可移植、安全的语言。它通常用于Webhooks、验证准入策略和变更准入策略。

在定义了CRD之后，Amin演示了如何指示Cro基于用户输入创建部署，使用CEL表达式注入值，如名称、副本(一个数据点)、镜像和端口。然后，他展示了如何创建一个服务，其选择器指向与部署相同的标签，以及一个依赖于该服务的入口，确保资源创建的正确拓扑顺序。

Amin强调Cro了解资源之间的关系和依赖关系，即使用户指定的顺序不同，也能按正确的顺序创建它们。这种抽象简化了开发人员的工作，他们不再需要担心资源创建和依赖关系的复杂性。

为了验证配置，Amin描述了资源组，显示Cro正在主动管理“web app”CRD，并提供了资源创建的拓扑顺序。然后他检查了由Cro管理的CRD，揭示了从简单的YAML配置生成的OpenAPI模式。

在注册了资源组之后，Amin通过提交一个YAML文件来演示创建Web应用程序实例，该文件指定了名称、镜像、端口以及是否启用Ingress或服务。Cro将根据提供的配置创建部署、服务和Ingress。

为了进一步展示Cro的功能，Amin介绍了与其他控制器(如ACK)集成以创建额外资源(如S3存储桶、IAM策略和Pod身份)的概念。他演示了如何将这些资源组合到一个“web stack”资源组中，从而抽象出开发人员的复杂性，并允许他们使用单一配置部署完整的应用程序堆栈。

在现场演示过程中，Amin遇到了一个错误，他将其视为展示Cro协调能力的机会。作为Kubernetes控制器，Cro会不断协调期望状态与实际状态，尝试解决任何出现的问题。Amin监控了资源创建的进度，观察到51秒前创建了一个S3存储桶、一个带有“awesome”标签的新IAM角色以及一个新的Pod身份关联。

最终，Cro成功部署了Web堆栈，提供了一个Ingress端点，Amin在浏览器中显示了正在运行的应用程序。他还演示了与S3存储桶的交互，上传了一个名为“hello world. Reinvent is awesome”的文件，以说明应用程序与已配置资源之间的集成。

Amin强调了在Kubernetes生态系统中使用Cro的好处，例如内置的RBAC、命名空间隔离以及能够利用现有的Kubernetes工具和工作流程。然后他介绍了Cro CLI，这是一个kubectl插件，允许用户管理资源组、生成RBAC清单以及打包资源组以在团队或集群之间分发。

Cro CLI使Amin能够列出资源组的所有实例，包括子资源如S3存储桶、Pod身份和Web应用程序。他演示了为特定资源组生成RBAC清单，确保Cro只拥有管理这些资源所需的权限。例如，要管理“web stack”应用程序，Cro需要S3存储桶访问权限、Pod身份、Web应用程序以及所有必需的动词。

此外，Amin展示了生成资源组示例实例的能力，为开发人员提供了可以参考的示例。CLI生成了一个带有种类、名称、命名空间和访问权限的实例，以及名称的字符串，展示了创建新实例的简单性。

Cro CLI的一个关键特性是能够将资源组打包成符合OCI标准的镜像，并发布到容器注册表(如ECR)。Amin演示了与ECR进行身份验证、将“web stack”资源组打包成tar.gz文件，并使用“v1”标签将其发布到他的个人ECR存储库的过程。这种能力使平台团队能够在团队或集群之间分发标准化的资源组，促进一致性和可重用性。

在现场演示之后，Christina讨论了Cro和ACK的潜在使用案例。对于遵循每个团队一个Kubernetes集群模型的组织，Cro和ACK可以安装在管理集群中，为团队提供一个API来创建和管理自己的Kubernetes集群。这种方法可以扩展到与ArgoCD等工具集成，实现跨多个集群的集中应用程序部署。

Christina承认，尽管Cro是一个在两周前刚刚发布的开源项目，但它仍在积极开发中，资源组API处于Alpha阶段。她警告观众在生产环境中使用Alpha API可能存在风险，包括意外的副作用、功能突然消失、在凌晨3点调试的挑战以及可能失去耐心或随机重写一切的冲动。

尽管处于Alpha阶段，但Christina鼓励观众开始使用ACK，它现在提供了50个GA控制器，涵盖了大多数Kubernetes平台的常见需求。由于ACK控制器已经达到GA，组织可以开始使用Kubernetes API作为基础设施来构建平台基础。

随着Cro的交互式开发继续进行，Christina敦促观众尝试使用它、提供反馈，并在GitHub和Kubernetes Slack频道上参与该项目。实施这些API将构成一种平衡的组织变革，改变技术而保持开发人员界面不变，确保开发人员采用。

一旦为所有开发人员建立了统一的平台，Christina设想在这个新的API世界中扩展运行时，以满足平台工程师和开发人员的需求。Cro和ACK与平台工程师的技能相符，因为它们不需要大量编程，类似于基础设施即代码的实践。

Christina强调与开发人员合作以确保所呈现的界面满足他们的需求的重要性，并邀请那些同时精通平台工程和开发的“独角兽”为Cro和ACK的开源开发做出贡献。

通过采用Kubernetes API作为基础设施，Christina描绘了一个未来，组织可以在这里显著增强平台能力，更有效地实现目标。

最后，Christina鼓励观众探索会议资源、为开源项目做出贡献，并加入亚马逊云科技一起开发Cro和ACK，以Kubernetes API作为基础设施来革新平台开发。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。