**協助改進此頁面** 

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 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 資源與end-to-end GitOps 的應用程式資訊清單一起存放
+ 根據您的團隊結構，依環境、服務或資源類型進行組織
+ 使用 Argo CD 的自動同步進行持續調校
+ 啟用剔除以自動移除已刪除的資源
+ 考慮多叢集基礎設施管理的hub-and-spoke模式

GitOps 提供稽核追蹤、復原功能和宣告式基礎設施管理。如需 Argo CD 的詳細資訊，請參閱[使用 Argo CD](working-with-argocd.md)。

### kro 的資源合成
<a name="_resource_composition_with_kro"></a>

使用 kro 的 EKS 功能 (Kube Resource Orchestrator)，將多個 ACK 資源組成更高層級的抽象和自訂 APIs。

 **何時搭配 ACK 使用 kro**：
+ 為常見的基礎設施堆疊建立可重複使用的模式 （資料庫 \$1 備份 \$1 監控）
+ 為應用程式團隊建置具有簡化 APIs自助式平台
+ 管理資源相依性，並在資源之間傳遞值 (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 命名空間和資源標籤組織 ACK AWS 資源，以獲得更好的管理、存取控制和成本追蹤。

### 命名空間組織
<a name="_namespace_organization"></a>

使用 Kubernetes 命名空間，以邏輯方式依環境 （生產、預備、開發）、團隊 （平台、資料、ml) 或應用程式分隔 ACK 資源。

 **優點**：
+ 用於存取控制的命名空間範圍 RBAC
+ 使用註釋設定每個命名空間的預設區域
+ 更輕鬆地進行資源管理和清理
+ 符合組織結構的邏輯分隔

### 資源標記
<a name="_resource_tagging"></a>

EKS ACK 功能會自動將預設標籤套用至其建立的所有 AWS 資源。這些標籤與自我管理的 ACK 不同，並提供增強的可追蹤性。

 **功能套用的預設標籤**：


| 標籤索引鍵 | Description | 
| --- | --- | 
|   `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 功能保持一致。

 **其他建議標籤**：

為成本分配、所有權追蹤和組織用途新增自訂標籤：
+ 環境 （生產、預備、開發）
+ 團隊或部門擁有權
+ 帳單分配的成本中心
+ 應用程式或服務名稱

## 從其他Infrastructure-as-code工具遷移
<a name="_migration_from_other_infrastructure_as_code_tools"></a>

許多組織發現在 Kubernetes 上標準化工作負載協同運作之外的價值。將基礎設施 AWS 和資源管理遷移到 ACK 可讓您使用 Kubernetes APIs 和應用程式工作負載來標準化基礎設施管理。

 **在適用於基礎設施的 Kubernetes 上標準化的優勢**：
+  **單一事實來源**：在 Kubernetes 中管理應用程式和基礎設施，實現end-to-end GitOps 實務
+  **統一工具**：團隊使用 Kubernetes 資源和工具，而不是學習多個工具和架構
+  **一致的對帳**：ACK 會持續對 Kubernetes 對工作負載所做的 AWS 資源進行對帳，並與必要工具相比，偵測和修正偏離
+  **原生組成**：使用 kro 和 ACK， AWS 直接在應用程式和資源資訊清單中參考資源，在資源之間傳遞連線字串和 ARNs 
+  **簡化的操作**：在整個系統中部署、復原和可觀測性的單一控制平面

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 探索共用基礎設施 (VPCs、IAM 角色、KMS 金鑰），而不會有修改的風險。 APIs 

如需資源採用的詳細資訊，請參閱[ACK 概念](ack-concepts.md)。

## 刪除政策
<a name="_deletion_policies"></a>

當您刪除對應的 AWS Kubernetes 資源時，刪除政策會控制資源會發生的情況。根據資源生命週期和您的操作需求，選擇正確的政策。

### 刪除 （預設）
<a name="_delete_default"></a>

 AWS 刪除 Kubernetes 資源時會刪除資源。這可維持叢集與 之間的一致性 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 資源編寫為更高層級的抽象概念