**帮助改进此页面** 

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

# 针对 EKS 的 ACK 注意事项
<a name="ack-considerations"></a>

本主题涵盖使用适用于 ACK 的 EKS 功能的重要注意事项，包括 IAM 配置、多账户模式以及与其他 EKS 功能集成。

## IAM 配置模式
<a name="_iam_configuration_patterns"></a>

ACK 功能使用 IAM 功能角色向 AWS 进行身份验证。根据需求选择合适的 IAM 模式。

### 简易模式：单一功能角色
<a name="_simple_single_capability_role"></a>

适用于开发、测试或简单使用案例，直接向功能角色授予所有必要权限。

 **何时使用**：
+ 开始使用 ACK
+ 单账户部署
+ 所有资源均由一个团队托管
+ 开发和测试环境

 **示例**：向功能角色添加带有资源标记条件的 S3 和 RDS 权限：

```
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": ["rds:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        },
      }
    }
  ]
}
```

此示例将 S3 和 RDS 操作限制在特定区域，并要求 RDS 资源必须带有 `ManagedBy: ACK` 标签。

### 生产模式：IAM 角色选择器
<a name="_production_iam_role_selectors"></a>

对于生产环境，请使用 IAM 角色选择器来实现最低权限访问和命名空间级隔离。

 **何时使用**：
+ 生产环境
+ 多团队集群
+ 多账户资源管理
+ 满足最低权限安全要求
+ 不同的服务需要不同的权限

 **优点：**
+ 每个命名空间仅获得其所需的权限
+ 团队隔离：团队 A 无法使用团队 B 的权限
+ 更易于审计和合规
+ 需要进行跨账户资源管理

有关 IAM 角色选择器配置的详细信息，请参阅[配置 ACK 权限](ack-permissions.md)。

## 与其他 EKS 功能集成
<a name="_integration_with_other_eks_capabilities"></a>

### 将 Argo CD 与 GitOps 搭配使用
<a name="_gitops_with_argo_cd"></a>

使用适用于 Argo CD 的 EKS 功能，从 Git 存储库部署 ACK 资源，从而为基础设施管理启用 GitOps 工作流程。

 **注意事项：**
+ 将 ACK 资源与应用程序清单存储在一起，实现端到端 GitOps
+ 根据团队结构，按环境、服务或资源类型整理
+ 使用 Argo CD 的自动同步功能实现持续协调
+ 启用修剪来自动移除已删除的资源
+ 考虑采用轴辐模式进行多集群基础设施管理

GitOps 提供审计跟踪记录、回滚功能和声明式基础设施管理。有关 Argo CD 的更多信息，请参阅[使用 Argo CD](working-with-argocd.md)。

### 使用 kro 进行资源组合
<a name="_resource_composition_with_kro"></a>

使用适用于 kro 的 EKS 功能（Kube Resource Orchestrator），将多个 ACK 资源组合成更高级别的抽象和自定义 API。

 **何时将 kro 与 ACK 结合使用**：
+ 为常见的基础设施堆栈创建可重复使用的模式（数据库 \$1 备份 \$1 监控）
+ 为应用团队构建带有简化 API 的自助式平台
+ 管理资源依赖项并在资源之间传递值（例如将 S3 存储桶 ARN 传递给 Lambda 函数）
+ 跨多个团队标准化基础设施配置
+ 通过将实现细节隐藏在自定义资源背后来降低复杂性

 **示例模式**：
+ 应用程序堆栈：S3 存储桶 \$1 SQS 队列 \$1 通知配置
+ 数据库设置：RDS 实例 \$1 参数组 \$1 安全组 \$1 密钥
+ 联网：VPC \$1 子网 \$1 路由表 \$1 安全组

kro 负责处理组合资源的依赖项排序、状态传播和生命周期管理。有关 kro 的更多信息，请参阅 [kro 概念](kro-concepts.md)。

## 整理资源
<a name="_organizing_your_resources"></a>

使用 Kubernetes 命名空间和 AWS 资源标签来整理 ACK 资源，以便更轻松地进行管理、访问控制和成本跟踪。

### 整理命名空间
<a name="_namespace_organization"></a>

使用 Kubernetes 命名空间按环境（生产、暂存、开发）、团队（平台、数据、ml）或应用程序在逻辑上分隔 ACK 资源。

 **优点：**
+ 通过作用域为命名空间的 RBAC 实现访问控制
+ 使用注释为每个命名空间设置默认区域
+ 更轻松地管理和清理资源
+ 逻辑分隔与组织结构一致

### 资源标签
<a name="_resource_tagging"></a>

EKS ACK 功能会自动为它创建的所有 AWS 资源应用默认标签。这些标签与自主管理的 ACK 的标签不同，可提供增强的可追溯性。

 **该功能应用的默认标签**：


| 标签密钥 | 说明 | 
| --- | --- | 
|   `eks:controller-version`   |  ACK 控制器的版本  | 
|   `eks:kubernetes-namespace`   |  ACK 资源的 Kubernetes 命名空间  | 
|   `eks:kubernetes-resource-name`   |  Kubernetes 资源的名称  | 
|   `eks:kubernetes-api-group`   |  Kubernetes API 组（例如 `s3.services.k8s.aws`）  | 
|   `eks:eks-capability-arn`   |  EKS ACK 功能的 ARN  | 

**注意**  
自主管理的 ACK 使用不同的默认标签：`services.k8s.aws/controller-version` 和 `services.k8s.aws/namespace`。功能的标签使用 `eks:` 前缀，以与 EKS 的其他功能保持一致。

 **其他推荐标签**：

为成本分配、所有权跟踪和整理目的添加自定义标签：
+ 环境（生产、暂存、开发）
+ 团队或部门所有权
+ 用于账单分配的成本中心
+ 应用程序或服务名称

## 从其他基础设施即代码工具迁移
<a name="_migration_from_other_infrastructure_as_code_tools"></a>

许多组织发现，将 Kubernetes 标准化扩展到工作负载编排之外具有重要价值。将基础设施和 AWS 资源管理迁移到 ACK，可以让您使用 Kubernetes API 来标准化基础设施管理，并与应用程序工作负载一起管理。

 **在 Kubernetes 中标准化基础设施管理的优势**：
+  **单一事实来源**：在 Kubernetes 中同时管理应用程序和基础设施，实现端到端 GitOps 实践
+  **统一工具**：团队使用 Kubernetes 资源和工具，无需学习多种工具和框架
+  **一致协调机制**：ACK 会像 Kubernetes 协调工作负载一样持续协调 AWS 资源，相比命令式工具，ACK 能检测和纠正状态偏差
+  **原生组合**：通过将 kro 与 ACK 结合，直接在应用程序和资源清单中引用 AWS 资源，在资源之间传递连接字符串和 ARN
+  **简化操作**：为整个系统提供统一的控制面板，用于实现部署、回滚和可观测性

ACK 支持在不重新创建的情况下接管现有 AWS 资源，从而实现从 CloudFormation、Terraform 或集群外部资源进行零停机时间迁移。

 **接管现有资源**：

```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: existing-bucket
  annotations:
    services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
  name: my-existing-bucket-name
```

接管后，资源将由 ACK 管理，并且可以通过 Kubernetes 清单进行更新。您可以增量迁移，根据需要接管资源，同时为其他资源保留现有 IaC 工具。

ACK 也支持只读资源。对于由其他团队或工具管理、您希望引用但不希望修改的资源，可以将接管与 `retain` 删除策略结合使用，并授予 IAM 只读权限。这使得应用程序可以通过 Kubernetes API 发现共享基础设施（VPC、IAM 角色、KMS 密钥），而无需承担修改风险。

有关资源接管的更多信息，请参阅 [ACK 概念](ack-concepts.md)。

## 删除策略
<a name="_deletion_policies"></a>

删除策略决定了当您删除 Kubernetes 资源时，相应 AWS 资源的处置方式。根据资源生命周期和运营需求选择合适的策略。

### 删除（默认）
<a name="_delete_default"></a>

当您删除 Kubernetes 资源时，相应的 AWS 也将删除。这样可以保持集群与 AWS 之间的一致性，确保资源不会累积。

 **何时使用删除**：
+ 开发和测试环境中的清理操作至关重要时
+ 临时资源与应用程序生命周期（测试数据库、临时存储桶）相关联时
+ 涉及不应超过应用程序生命周期的资源时（SQS 队列、ElastiCache 集群）
+ 成本优化：自动清理未使用的资源
+ 涉及通过 GitOps 管理的环境时，其中从 Git 中移除资源即应删除基础设施

默认的删除策略与 Kubernetes 的声明式模型一致：集群中存在的内容与 AWS 中存在的内容相匹配。

### 保留
<a name="_retain"></a>

删除 Kubernetes 资源时，相应的 AWS 资源将保留。这样可以保护关键数据，并使资源的存在时间超过其 Kubernetes 表示形式。

 **何时使用保留**：
+ 生产数据库包含关键数据且此类数据必须在集群更改后保留时
+ 长期存储桶需符合合规性或审计要求时
+ 多个应用程序或团队使用共享资源时
+ 资源正在迁移到不同管理工具时
+ 希望保留基础设施的灾难恢复场景中
+ 涉及具有复杂依赖项、需要谨慎停用的资源时

```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: production-db
  annotations:
    services.k8s.aws/deletion-policy: "retain"
spec:
  dbInstanceIdentifier: prod-db
  # ... configuration
```

**重要**  
被保留的资源将继续产生 AWS 费用，如果您不再需要这些资源，则必须手动将其从 AWS 中删除。使用资源标记来跟踪保留的资源，以便后续清理。

有关删除策略的更多信息，请参阅 [ACK 概念](ack-concepts.md)。

## 上游文档
<a name="_upstream_documentation"></a>

有关使用 ACK 的详细信息，请参阅下列文档：
+  [ACK 使用指南](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/)：创建和管理资源
+  [ACK API 参考](https://aws-controllers-k8s.github.io/community/reference/)：所有服务的完整 API 文档
+  [ACK 文档](https://aws-controllers-k8s.github.io/community/docs/)：全面的用户文档

## 后续步骤
<a name="_next_steps"></a>
+  [配置 ACK 权限](ack-permissions.md)：配置 IAM 权限和多账户模式
+  [ACK 概念](ack-concepts.md)：了解 ACK 概念和资源生命周期
+  [排查 ACK 功能问题](ack-troubleshooting.md)：排查 ACK 问题
+  [使用 Argo CD](working-with-argocd.md)：通过 GitOps 部署 ACK 资源
+  [kro 概念](kro-concepts.md)：将 ACK 资源组合成更高级别的抽象