EKS 托管型 kro 注意事项 - Amazon EKS
kro 的适用场景RBAC 模式与其他 EKS 功能集成ResourceGraphDefinition 的组织方式版本控制与更新验证与测试上游文档后续步骤
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。

EKS 托管型 kro 注意事项

本主题旨在介绍使用 EKS 托管型 kro 的重要注意事项，包括资源组合编排的适用场景、RBAC 配置模式以及与其他 EKS 托管功能的集成方法。

kro 的适用场景

kro 旨在创建可复用的基础设施模式与自定义 API，以简化复杂的资源管理工作。

需要使用 kro 的场景：

  • 为应用团队构建带有简化 API 的自助式平台

  • 在团队间统一基础设施模式（如数据库 + 备份 + 监控的组合）

  • 管理资源间的依赖关系，并实现资源间的值传递

  • 构建自定义抽象资源，隐藏底层的实现复杂度

  • 将多个 ACK 资源组合为更高级别的基础设施组件

  • 为复杂的基础设施栈启用 GitOps 工作流程

无需使用 kro 的场景：

  • 管理简单的独立资源（直接使用 ACK 或 Kubernetes 原生资源）

  • 需要动态运行时逻辑（kro 为声明式框架，不支持命令式操作）

  • 资源之间不存在依赖关系或共享配置

kro 的优势在于构建标准化部署流程，即提供预设规则、可复用模式，帮助各团队轻松、合规地部署复杂的基础设施。

RBAC 模式

kro 可实现职责分离，将创建 ResourceGraphDefinition 的平台团队与创建实例的应用团队的工作边界清晰划分。

平台团队职责

平台团队负责创建并维护用于定义自定义 API 的 ResourceGraphDefinition（RGD）。

所需权限：

  • 创建、更新、删除 ResourceGraphDefinition

  • 管理各类底层资源（Deployment、Service、ACK 资源）

  • 拥有 RGD 待使用的所有命名空间的访问权限

平台团队的 ClusterRole 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

有关 RBAC 配置的详细信息，请参阅配置 kro 权限。

应用团队职责

应用团队负责创建由 RGD 定义的自定义资源实例，无需理解底层实现的复杂逻辑。

所需权限：

  • 创建、更新、删除自定义资源实例

  • 拥有其所在命名空间的读取权限

  • 不授予底层资源或 RGD 的访问权限

优点：

  • 团队可直接使用简洁的高层级 API

  • 平台团队把控底层实现细节

  • 降低配置错误的风险加快

  • 新团队成员的上手速度

与其他 EKS 功能集成

ACK 资源组合编排

kro 与 ACK 结合使用时，在创建基础设施模式方面的能力尤为突出。

常见模式：

  • 带存储功能的应用程序：S3 存储桶 + SQS 队列 + 通知配置

  • 数据库资源栈：RDS 实例 + 参数组 + 安全组 + Secrets Manager 密钥

  • 联网资源：VPC + 子网 + 路由表 + 安全组 + NAT 网关

  • 带存储功能的计算资源：EC2 实例 + EBS 卷 + IAM 实例配置文件

kro 会自动处理资源的依赖顺序、实现资源间的值传递（如 ARN、连接字符串），并将所有资源作为单一单元进行全生命周期管理。

有关 ACK 资源组合编排的示例，请参阅 ACK 概念。

将 Argo CD 与 GitOps 搭配使用

借助适用于 Argo CD 的 EKS 功能，可从 Git 存储库中部署 RGD 及实例。

存储库组织方式：

  • 平台存储库：存放由平台团队管理的 ResourceGraphDefinition

  • 应用存储库：存放由应用团队管理的自定义资源容器实例

  • 共享存储库：小型组织可将 RGD 与实例存放于同一存储库

注意事项：

  • 需先部署 RGD，再部署实例（可借助 Argo CD 的同步波功能实现）

  • 为平台团队与应用团队分别配置独立的 Argo CD 项目

  • 由平台团队管控 RGD 存储库的访问权限

  • 为应用团队分配 RGD 定义文件的只读访问权限

有关 Argo CD 的更多信息，请参阅使用 Argo CD。

ResourceGraphDefinition 的组织方式

可按照用途、复杂度和归属方对 RGD 进行分类管理。

按用途分类：

  • 基础设施：数据库资源栈、联网资源、存储资源

  • 应用程序：Web 应用、API 服务、批处理任务

  • 平台：共享服务、监控组件、日志组件

按复杂度分类：

  • 简单：包含 2-3 个资源，依赖关系极少

  • 中等：包含 5-10 个资源，存在部分依赖关系

  • 复杂：包含 10 个以上资源，依赖关系复杂

命名规范：

  • 采用描述性名称，例如：webapp-with-database、s3-notification-queue

  • 若存在破坏性变更，可在名称中加入版本号，例如：webapp-v2

  • 为同类型 RGD 添加统一前缀，例如：platform- 、app-

命名空间策略：

  • RGD 为集群级资源（非命名空间级资源）

  • 实例为命名空间级资源

  • 可在 RGD 中配置命名空间选择器，管控实例允许被创建的命名空间范围

版本控制与更新

需提前规划 RGD 的迭代优化与实例的迁移方案。

RGD 更新：

  • 非破坏性变更：直接原地更新 RGD 即可（操作包括新增可选字段、添加带 includeWhen 条件的新资源）

  • 破坏性变更：需创建名称不同的新 RGD（例如 webapp-v2）

  • 弃用策略：通过注解标记旧版 RGD，并同步告知用户迁移时间规划

实例迁移：

  • 基于更新版 RGD 创建新的实例

  • 验证新实例运行状态正常

  • 删除旧版实例

  • kro 会自动处理底层资源的更新操作

最佳实践

  • RGD 变更需先在非生产环境完成测试

  • 有重大变更时，在 RGD 名称中采用语义版本控制命名规则

  • 记录破坏性变更内容及对应的迁移方案

  • 为应用团队提供可直接参考的迁移示例

验证与测试

将 RGD 部署到生产环境前，需对其进行验证。

验证策略：

  • 模式验证：kro 会自动对 RGD 模式进行验证

  • 实例试运行：在开发命名空间中创建测试用实例

  • 集成测试：验证组合后的各类资源是否能协同正常工作

  • 策略强制执行：通过准入控制器落实组织内部的标准规范

需测试的常见问题：

  • 资源依赖关系与创建顺序

  • 资源间的值传递逻辑（CEL 表达式）

  • 条件式资源的包含规则（includeWhen）

  • 底层资源的状态反馈机制

  • 实例创建操作对应的 RBAC 权限配置

上游文档

有关使用 kro 的详细信息，请参阅以下内容：

后续步骤