**協助改進此頁面** 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。 本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 資源合成與 kro (Kube Resource Orchestrator) **kro (Kube Resource Orchestrator)** 是一種開放原始碼的 Kubernetes 原生專案，可讓您使用簡單且直接的組態來定義自訂 Kubernetes APIs。使用 kro，您可以輕鬆設定新的自訂 APIs，以建立一組 Kubernetes 物件及其之間的邏輯操作。 透過 EKS 功能，kro 完全由 管理 AWS，無需在叢集上安裝、維護和擴展 kro 控制器。 ## kro 的運作方式 kro 推出稱為 (RGD) 的自訂資源定義 `ResourceGraphDefinition`(CRD)，可簡單且簡化地建立自訂 Kubernetes APIs。當您建立 時`ResourceGraphDefinition`，kro 會使用原生 Kubernetes 延伸模組來建立和管理叢集中的新 APIs。從這個單一資源規格中，kro 會根據您的規格為您建立新的 CRD 並註冊，並調整以管理新定義的自訂資源。 RGDs可以包含多個資源，而 kro 會判斷相互依存性和資源排序，因此您不需要。您可以使用簡單的語法，將組態從一個資源注入到另一個資源，大幅簡化合成並消除叢集中對「黏附」運算子的需求。透過 kro，您的自訂資源可以包含原生 Kubernetes 資源，以及叢集中安裝的任何自訂資源定義 (CRDs)。 kro 支援單一主要資源類型： + **ResourceGraphDefinition (RGD)**：定義 Kubernetes 自訂資源，封裝一或多個基礎原生或自訂 Kubernetes 資源 除了此資源之外，kro 還將建立和管理使用它建立的自訂資源的生命週期，以及其所有元件資源。 kro 與 AWS Controllers for Kubernetes (ACK) 無縫整合，可讓您使用 AWS 資源編寫工作負載資源，以建立更高階的抽象概念。這可讓您建立自己的雲端建置區塊，簡化資源管理，並根據組織標準，使用預設和不可變的組態設定啟用可重複使用的模式。 ## kro 的優點 kro 可讓平台團隊建立自訂 Kubernetes APIs，將多個資源組成更高階的抽象概念。這可讓開發人員使用簡單、標準化和版本控制的自訂資源來部署複雜的應用程式，進而簡化資源管理。您可以定義常用資源組合的可重複使用模式，讓整個組織建立一致的資源。 kro 在 [Kubernetes 中使用通用表達式語言 (CEL)](https://kubernetes.io/docs/reference/using-api/cel/)，在資源之間傳遞值並整合條件式邏輯，提供資源合成的彈性。您可以將 ACK 管理的 Kubernetes AWS 資源和資源組成為統一APIs，以啟用完整的應用程式和基礎設施定義。 kro 透過 Kubernetes 資訊清單支援宣告式組態，讓 GitOps 工作流程和基礎設施成為與現有開發程序無縫整合的程式碼實務。作為 EKS 受管功能的一部分，kro 由 完全管理 AWS，無需在叢集上安裝、設定和維護 kro 控制器。 **範例：建立 ResourceGraphDefinition** 下列範例顯示使用 部署和服務建立 Web 應用程式的簡單 `ResourceGraphDefinition` ： ``` apiVersion: kro.run/v1alpha1 kind: ResourceGraphDefinition metadata: name: web-application spec: schema: apiVersion: v1alpha1 kind: WebApplication spec: name: string replicas: integer | default=3 resources: - id: deployment template: apiVersion: apps/v1 kind: Deployment metadata: name: ${schema.spec.name} spec: replicas: ${schema.spec.replicas} - id: service template: apiVersion: v1 kind: Service metadata: name: ${schema.spec.name} ``` 當使用者建立`WebApplication`自訂資源的執行個體時，kro 會自動建立對應的部署和服務資源，並管理其生命週期與自訂資源。 ## 與其他 EKS 受管功能的整合 kro 與其他 EKS 受管功能整合。 + ** AWS Kubernetes (ACK) 的控制器**：使用 kro 將 ACK 資源編寫為更高層級的抽象，簡化 AWS 資源管理。 + **Argo CD**：使用 Argo CD 管理跨多個叢集的 kro 自訂資源部署，為您的平台建置區塊和應用程式堆疊啟用 GitOps 工作流程。 ## kro 入門 若要開始使用 kro 的 EKS 功能： 1. 透過 AWS 主控台、 AWS CLI 或您偏好的基礎設施做為程式碼工具，在您的 EKS 叢集上[建立 kro 功能資源](create-kro-capability.md)。 1. 建立 ResourceGraphDefinitions (RGDs)，以定義您的自訂 APIs和資源組成。 1. 套用自訂資源的執行個體，以佈建和管理基礎 Kubernetes AWS 和資源。 # 建立 kro 功能 本主題說明如何在 Amazon EKS 叢集上建立 kro 功能。 ## 先決條件 在建立 kro 功能之前，請確定您有： + 執行支援 Kubernetes 版本的現有 Amazon EKS 叢集 （支援標準和延伸支援中的所有版本） + 足夠的 IAM 許可，可在 EKS 叢集上建立功能資源 + （適用於 CLI/eksctl) 安裝和設定適當的 CLI 工具 **注意** 與 ACK 和 Argo CD 不同， kro 不需要超出信任政策的額外 IAM 許可。 kro 完全在您的叢集內運作，而且不會進行 AWS API 呼叫。不過，您仍然需要為 IAM 功能角色提供適當的信任政策。如需為 kro 設定 Kubernetes RBAC 許可的資訊，請參閱 [設定 kro 許可](kro-permissions.md)。 ## 選擇您的工具 您可以使用、 AWS 管理主控台 AWS CLI 或 eksctl 建立 kro 功能： + [使用主控台建立 kro 功能](kro-create-console.md) - 使用 主控台進行引導式體驗 + [使用 CLI 建立 kro AWS 功能](kro-create-cli.md) - 使用 AWS CLI 進行指令碼編寫和自動化 + [使用 eksctl 建立 kro 功能](kro-create-eksctl.md) - 使用 eksctl 獲得 Kubernetes 原生體驗 ## 當您建立 kro 功能時會發生什麼情況 當您建立 kro 功能時： 1. EKS 會建立 kro 功能服務，並將其設定為監控和管理叢集中的資源 1. 您的叢集中已安裝自訂資源定義 (CRDs) 1. 會自動為您的 IAM 功能角色建立存取項目`AmazonEKSKROPolicy`，其中 授予管理 ResourceGraphDefinitions 及其執行個體的許可 （請參閱 [EKS 功能的安全考量](capabilities-security.md)) 1. 該功能假設您提供的 IAM 功能角色 （僅用於信任關係） 1. kro 開始觀察`ResourceGraphDefinition`資源及其執行個體 1. 功能狀態從 變更為 `CREATING` `ACTIVE` 啟用後，您可以建立 ResourceGraphDefinitions 來定義自訂 APIs並建立這些 APIs的執行個體。 **注意** 自動建立的存取項目包含 `AmazonEKSKROPolicy`，授予 kro 許可來管理 ResourceGraphDefinitions 及其執行個體。若要允許 kro 建立 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源 （例如部署、服務或 ACK 資源），您必須設定其他存取項目政策。若要進一步了解存取項目以及如何設定其他許可，請參閱 [設定 kro 許可](kro-permissions.md)和 [EKS 功能的安全考量](capabilities-security.md)。 ## 後續步驟 建立 kro 功能之後： + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源合成 + [kro 概念](kro-concepts.md) - 了解 SimpleSchema、CEL 表達式和資源合成模式 # 使用主控台建立 kro 功能 本主題說明如何使用 建立 kro (Kube Resource Orchestrator) 功能 AWS 管理主控台。 ## 建立 kro 功能 1. 在以下網址開啟 Amazon EKS 主控台：https://console.aws.amazon.com/eks/home\$1/clusters。 1. 選取您的叢集名稱以開啟叢集詳細資訊頁面。 1. 選擇**功能**索引標籤。 1. 在左側導覽中，選擇 **kro (Kube Resource Orchestrator)**。 1. 選擇**建立 kro 功能**。 1. 對於 **IAM 功能角色**： + 如果您已經有 IAM 功能角色，請從下拉式清單中選取它 + 如果您需要建立角色，請選擇**建立 kro 角色** 這會在預先填入信任政策的新標籤中開啟 IAM 主控台。此角色不需要額外的 IAM 許可，因為 kro 完全在您的叢集中運作。 建立角色後，返回 EKS 主控台並自動選取角色。 **注意** 與 ACK 和 Argo CD 不同， kro 不需要信任政策以外的其他 IAM 許可。 kro 完全在您的叢集內運作，而且不會進行 AWS API 呼叫。 1. 選擇**建立**。 功能建立程序開始。 ## 確認功能處於作用中狀態 1. 在**功能**索引標籤上，檢視 kro 功能狀態。 1. 等待狀態從 變更為 `CREATING` `ACTIVE`。 1. 啟用後，此功能即可使用。 如需功能狀態和故障診斷的資訊，請參閱 [使用 功能資源](working-with-capabilities.md)。 ## 授予管理 Kubernetes 資源的許可 當您建立 kro 功能時，系統會自動使用 建立 EKS 存取項目`AmazonEKSKROPolicy`，允許 kro 管理 ResourceGraphDefinitions 及其執行個體。不過，預設不會授予許可來建立 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源 ConfigMaps 等）。 ResourceGraphDefinitions 此刻意設計遵循最低權限原則 - 不同的 ResourceGraphDefinitions 需要不同的許可。您必須根據 ResourceGraphDefinitions 將管理的資源，明確設定 kro 所需的許可。 若要快速入門、測試或開發環境，請使用 `AmazonEKSClusterAdminPolicy`： 1. 在 EKS 主控台中，導覽至叢集的**存取**索引標籤。 1. 在**存取項目**下，尋找 kro 功能角色的項目 （它將具有您先前建立的角色 ARN)。 1. 選擇存取項目以開啟其詳細資訊。 1. 在**存取政策**區段中，選擇**關聯存取政策**。 1. `AmazonEKSClusterAdminPolicy` 從政策清單中選取 。 1. 針對**存取範圍**，選取**叢集**。 1. 選擇**關聯**。 **重要** `AmazonEKSClusterAdminPolicy` 授予建立和管理所有 Kubernetes 資源的廣泛許可，包括跨所有命名空間建立任何資源類型的能力。這對於開發和 POCs 來說很方便，但不應用於生產環境。對於生產，請建立自訂 RBAC 政策，僅授予 ResourceGraphDefinitions 將管理之特定資源所需的許可。如需設定最低權限許可的指引，請參閱 [設定 kro 許可](kro-permissions.md)和 [EKS 功能的安全考量](capabilities-security.md)。 ## 確認可用的自訂資源 功能處於作用中狀態後，請確認叢集中是否有可用的 kro 自訂資源。 **使用主控台** 1. 在 Amazon EKS 主控台中導覽至您的叢集 1. 選擇**資源**索引標籤 1. 選擇**延伸模組** 1. 選擇 **CustomResourceDefinitions** 您應該會看到列出的`ResourceGraphDefinition`資源類型。 **使用 kubectl** ``` kubectl api-resources | grep kro.run ``` 您應該會看到列出的`ResourceGraphDefinition`資源類型。 ## 後續步驟 + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源合成 + [kro 概念](kro-concepts.md) - 了解 SimpleSchema、CEL 表達式和合成模式 + [使用 功能資源](working-with-capabilities.md) - 管理您的 kro 功能資源 # 使用 CLI 建立 kro AWS 功能 本主題說明如何使用 CLI 建立 kro (Kube Resource Orchestrator) AWS 功能。 ## 先決條件 + ** AWS CLI** – 版本 `2.12.3` 或更新版本。若要檢查您的版本，請執行 `aws --version`。如需詳細資訊，請參閱《 AWS 命令列界面使用者指南》中的[安裝](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。 + ** `kubectl` **：命令列工具，適用於使用 Kubernetes 叢集。如需詳細資訊，請參閱[設定 `kubectl` 和 `eksctl`](install-kubectl.md)。 ## 步驟 1：建立 IAM 功能角色 建立信任政策檔案： ``` cat > kro-trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "capabilities.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } EOF ``` 建立 IAM 角色： ``` aws iam create-role \ --role-name KROCapabilityRole \ --assume-role-policy-document file://kro-trust-policy.json ``` **注意** 與 ACK 和 Argo CD 不同，kro 不需要額外的 IAM 許可。 kro 完全在您的叢集內運作，而且不會進行 AWS API 呼叫。只有建立與 EKS 功能服務的信任關係時，才需要此角色。 ## 步驟 2：建立 kro 功能 在叢集上建立 kro 功能資源。將 *region-code* 取代為您的叢集所在的 AWS 區域 （例如 `us-west-2`)，並將 *my-cluster* 取代為您的叢集名稱。 ``` aws eks create-capability \ --region region-code \ --cluster-name my-cluster \ --capability-name my-kro \ --type KRO \ --role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \ --delete-propagation-policy RETAIN ``` 命令會立即傳回，但當 EKS 建立所需的功能基礎設施和元件時，功能需要一些時間才會變成作用中。EKS 會在建立叢集時，在叢集中安裝與此功能相關的 Kubernetes 自訂資源定義。 **注意** 如果您收到叢集不存在或您沒有許可的錯誤，請驗證： 叢集名稱正確 您的 AWS CLI 已設定為正確的區域 您擁有必要的 IAM 許可 ## 步驟 3：確認功能處於作用中狀態 等待功能變成作用中。將 *region-code* 取代為您的叢集所在的 AWS 區域，並將 *my-cluster* 取代為您的叢集名稱。 ``` aws eks describe-capability \ --region region-code \ --cluster-name my-cluster \ --capability-name my-kro \ --query 'capability.status' \ --output text ``` 當狀態顯示 時，此功能已就緒`ACTIVE`。 您也可以檢視完整的功能詳細資訊： ``` aws eks describe-capability \ --region region-code \ --cluster-name my-cluster \ --capability-name my-kro ``` ## 步驟 4：授予管理 Kubernetes 資源的許可 當您建立 kro 功能時，系統會自動使用 建立 EKS 存取項目`AmazonEKSKROPolicy`，允許 kro 管理 ResourceGraphDefinitions 及其執行個體。不過，預設不會授予許可來建立 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源 ConfigMaps 等）。 ResourceGraphDefinitions 此刻意設計遵循最低權限原則：不同的 ResourceGraphDefinitions 需要不同的許可。例如：\$1 僅建立 ConfigMaps 和 Secrets 的 ResourceGraphDefinition 需要與建立部署和服務者不同的許可 \$1 建立 ACK 資源的 ResourceGraphDefinition 需要這些特定自訂資源的許可 \$1 有些 ResourceGraphDefinitions 可能只讀取現有資源，而不建立新的資源 您必須根據 ResourceGraphDefinitions 將管理的資源，明確設定 kro 所需的許可。 ### 快速設定 若要快速入門、測試或開發環境，請使用 `AmazonEKSClusterAdminPolicy`： 取得功能角色 ARN： ``` CAPABILITY_ROLE_ARN=$(aws eks describe-capability \ --region region-code \ --cluster-name my-cluster \ --capability-name my-kro \ --query 'capability.roleArn' \ --output text) ``` 關聯叢集管理員政策： ``` aws eks associate-access-policy \ --region region-code \ --cluster-name my-cluster \ --principal-arn $CAPABILITY_ROLE_ARN \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster ``` **重要** `AmazonEKSClusterAdminPolicy` 授予建立和管理所有 Kubernetes 資源的廣泛許可，包括跨所有命名空間建立任何資源類型的能力。這對於開發和 POCs 來說很方便，但不應用於生產環境。對於生產，請建立自訂 RBAC 政策，僅授予 ResourceGraphDefinitions 將管理之特定資源所需的許可。如需設定最低權限許可的指引，請參閱 [設定 kro 許可](kro-permissions.md)和 [EKS 功能的安全考量](capabilities-security.md)。 ## 步驟 5：確認自訂資源可用 功能處於作用中狀態後，請確認叢集中是否有可用的 kro 自訂資源： ``` kubectl api-resources | grep kro.run ``` 您應該會看到列出的`ResourceGraphDefinition`資源類型。 ## 後續步驟 + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源合成 + [kro 概念](kro-concepts.md) - 了解 SimpleSchema、CEL 表達式和合成模式 + [使用 功能資源](working-with-capabilities.md) - 管理您的 kro 功能資源 # 使用 eksctl 建立 kro 功能 本主題說明如何使用 eksctl 建立 kro (Kube Resource Orchestrator) 功能。 **注意** 下列步驟需要 eksctl 版本 `0.220.0` 或更新版本。若要檢查您的版本，請執行 `eksctl version`。 ## 步驟 1：建立 IAM 功能角色 建立信任政策檔案： ``` cat > kro-trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "capabilities.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } EOF ``` 建立 IAM 角色： ``` aws iam create-role \ --role-name KROCapabilityRole \ --assume-role-policy-document file://kro-trust-policy.json ``` **注意** 與 ACK 和 Argo CD 不同， kro 不需要信任政策以外的其他 IAM 許可。 kro 完全在您的叢集內運作，而且不會進行 AWS API 呼叫。 ## 步驟 2：建立 kro 功能 使用 eksctl 建立 kro 功能。將 *region-code* 取代為您的叢集所在的 AWS 區域，並將 *my-cluster* 取代為您的叢集名稱。 ``` eksctl create capability \ --region region-code \ --cluster my-cluster \ --name my-kro \ --type KRO \ --role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole ``` 命令會立即傳回，但 功能需要一些時間才會變成作用中。 ## 步驟 3：確認功能處於作用中狀態 檢查功能狀態。將 *region-code* 取代為您的叢集所在的 AWS 區域，並將 *my-cluster* 取代為您的叢集名稱。 ``` eksctl get capability \ --region region-code \ --cluster my-cluster \ --name my-kro ``` 當狀態顯示 時，此功能已就緒`ACTIVE`。 ## 步驟 4：授予管理 Kubernetes 資源的許可 根據預設，kro 只能建立和管理 ResourceGraphDefinitions 及其執行個體。若要允許 kro 建立和管理 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源，請將`AmazonEKSClusterAdminPolicy`存取政策與功能的存取項目建立關聯。 取得功能角色 ARN： ``` CAPABILITY_ROLE_ARN=$(aws eks describe-capability \ --region region-code \ --cluster my-cluster \ --name my-kro \ --query 'capability.roleArn' \ --output text) ``` 關聯叢集管理員政策： ``` aws eks associate-access-policy \ --region region-code \ --cluster my-cluster \ --principal-arn $CAPABILITY_ROLE_ARN \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster ``` **重要** `AmazonEKSClusterAdminPolicy` 授予建立和管理所有 Kubernetes 資源的廣泛許可，旨在簡化入門。對於生產用途，請建立更嚴格的 RBAC 政策，僅授予 ResourceGraphDefinitions 將管理之特定資源所需的許可。如需設定最低權限許可的指引，請參閱 [設定 kro 許可](kro-permissions.md)和 [EKS 功能的安全考量](capabilities-security.md)。 ## 步驟 5：確認可用的自訂資源 功能處於作用中狀態後，請確認叢集中是否有可用的 kro 自訂資源： ``` kubectl api-resources | grep kro.run ``` 您應該會看到列出的`ResourceGraphDefinition`資源類型。 ## 後續步驟 + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源組成 + [kro 概念](kro-concepts.md) - 了解 SimpleSchema、CEL 表達式和合成模式 + [使用 功能資源](working-with-capabilities.md) - 管理您的 kro 功能資源 # kro 概念 kro 可讓平台團隊建立自訂 Kubernetes APIs，將多個資源組成更高階的抽象概念。本主題會逐步解說實際範例，然後說明使用 kro 的 EKS 功能時需要了解的核心概念。 ## kro 入門 建立 kro 功能後 （請參閱 [建立 kro 功能](create-kro-capability.md))，您可以在叢集中使用 ResourceGraphDefinitions 開始建立自訂 APIs。 以下是建立簡單 Web 應用程式抽象化的完整範例： ``` apiVersion: kro.run/v1alpha1 kind: ResourceGraphDefinition metadata: name: webapplication spec: schema: apiVersion: v1alpha1 kind: WebApplication group: kro.run spec: name: string | required=true image: string | default="nginx:latest" replicas: integer | default=3 resources: - id: deployment template: apiVersion: apps/v1 kind: Deployment metadata: name: ${schema.spec.name} spec: replicas: ${schema.spec.replicas} selector: matchLabels: app: ${schema.spec.name} template: metadata: labels: app: ${schema.spec.name} spec: containers: - name: app image: ${schema.spec.image} ports: - containerPort: 80 - id: service template: apiVersion: v1 kind: Service metadata: name: ${schema.spec.name} spec: selector: app: ${schema.spec.name} ports: - protocol: TCP port: 80 targetPort: 80 ``` 套用此 ResourceGraphDefinition 後，應用程式團隊可以使用簡化的 API 建立 Web 應用程式： ``` apiVersion: kro.run/v1alpha1 kind: WebApplication metadata: name: my-app spec: name: my-app replicas: 5 ``` kro 會自動使用適當的組態建立部署和服務。由於 `image` 未指定，因此會使用結構描述`nginx:latest`中的預設值。 ## 核心概念 **重要** kro 會在建立時間驗證 ResourceGraphDefinitions，而不是在執行時間。當您建立 RGD 時，kro 會驗證 CEL 語法、根據實際 Kubernetes 結構描述類型檢查表達式、驗證欄位是否存在，以及偵測循環相依性。這表示在部署任何執行個體之前，建立 RGD 時會立即發現錯誤。 ### ResourceGraphDefinition ResourceGraphDefinition (RGD) 透過指定下列項目來定義自訂 Kubernetes API： + **結構描述** - 使用 SimpleSchema 格式的 API 結構 （欄位名稱、類型、預設值、驗證） + **資源** - 要建立的基礎 Kubernetes 或 AWS 資源的範本 + **相依性** - 資源彼此的關係 （從欄位參考自動偵測） 當您套用 RGD 時，kro 會在叢集中註冊新的自訂資源定義 (CRD)。然後，應用程式團隊可以建立自訂 API 的執行個體，然後 kro 會處理建立和管理所有基礎資源。 如需詳細資訊，請參閱 kro 文件中的 [ResourceGraphDefinition 概觀](https://kro.run/docs/concepts/rgd/overview/)。 ### SimpleSchema 格式 SimpleSchema 提供簡單的方式來定義 API 結構描述，而不需要 OpenAPI 知識： ``` schema: apiVersion: v1alpha1 kind: Database spec: name: string | required=true description="Database name" size: string | default="small" enum=small,medium,large replicas: integer | default=1 minimum=1 maximum=5 ``` SimpleSchema `integer`支援 `string`、`boolean`、 和 `number`類型，具有 `required`、、`default``minimum`/`maximum`、 `enum`和 等限制`pattern`條件。 如需詳細資訊，請參閱 kro 文件中的 [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)。 ### CEL 表達式 kro 使用通用表達式語言 (CEL) 動態參考值，並新增條件式邏輯。CEL 表達式包裝在 `${`和 中，`}`可用兩種方式使用： **獨立表達式** - 整個欄位值是單一表達式： ``` spec: replicas: ${schema.spec.replicaCount} # Expression returns integer labels: ${schema.spec.labelMap} # Expression returns object ``` 表達式結果會取代整個欄位值，且必須符合欄位的預期類型。 **字串範本** - 內嵌在字串中的一或多個表達式： ``` metadata: name: "${schema.spec.prefix}-${schema.spec.name}" # Multiple expressions annotation: "Created by ${schema.spec.owner}" # Single expression in string ``` 字串範本中的所有表達式都必須傳回字串。使用 `string()`轉換其他類型：`"replicas-${string(schema.spec.count)}"`。 **欄位參考** - 使用 存取執行個體規格值`schema.spec`： ``` template: metadata: name: ${schema.spec.name}-deployment namespace: ${schema.metadata.namespace} # Can also reference metadata spec: replicas: ${schema.spec.replicas} ``` **選用欄位存取** - `?`用於可能不存在的欄位： ``` # For ConfigMaps or Secrets with unknown structure value: ${configmap.data.?DATABASE_URL} # For optional status fields ready: ${deployment.status.?readyReplicas > 0} ``` 如果 欄位不存在，則表達式會傳回 `null`而非失敗。 **條件式資源** - 只有在符合條件時才包含資源： ``` resources: - id: ingress includeWhen: - ${schema.spec.enableIngress == true} template: # ... ingress configuration ``` `includeWhen` 欄位接受布林表達式的清單。所有條件都必須為 true，才能建立資源。目前， `includeWhen` 只能參考 `schema.spec` 欄位。 **轉換** - 使用三元運算子和函數轉換值： ``` template: spec: resources: requests: memory: ${schema.spec.size == "small" ? "512Mi" : "2Gi"} # String concatenation image: ${schema.spec.registry + "/" + schema.spec.imageName} # Type conversion port: ${string(schema.spec.portNumber)} ``` **跨資源參考** - 來自其他資源的參考值： ``` resources: - id: bucket template: apiVersion: s3.services.k8s.aws/v1alpha1 kind: Bucket spec: name: ${schema.spec.name}-data - id: configmap template: apiVersion: v1 kind: ConfigMap data: BUCKET_NAME: ${bucket.spec.name} BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn} ``` 當您在 CEL 表達式中參考另一個資源時，它會自動建立相依性。 kro 會確保先建立參考的資源。 如需詳細資訊，請參閱 kro 文件中的 [CEL 表達式](https://kro.run/docs/concepts/rgd/cel-expressions/)。 ### 資源相依性 kro 會自動從 CEL 表達式推斷相依性 - 您不會指定順序，而是描述關係。當一個資源使用 CEL 表達式參考另一個資源時，kro 會建立相依性並決定正確的建立順序。 ``` resources: - id: bucket template: apiVersion: s3.services.k8s.aws/v1alpha1 kind: Bucket spec: name: ${schema.spec.name}-data - id: notification template: apiVersion: s3.services.k8s.aws/v1alpha1 kind: BucketNotification spec: bucket: ${bucket.spec.name} # Creates dependency: notification depends on bucket ``` 表達式`${bucket.spec.name}`會建立相依性。 kro 會建立所有資源及其相依性的定向無環圖 (DAG)，然後運算拓撲順序以進行建立。 **建立順序**：依拓撲順序建立資源 （依存性優先）。 **平行建立**：同時建立沒有相依性的資源。 **刪除順序**：以反向拓撲順序刪除資源 （先依存）。 **循環相依性**：不允許 - Kro 在驗證期間拒絕具有循環相依性的 ResourceGraphDefinitions。 您可以檢視計算的建立順序： ``` kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}' ``` 如需詳細資訊，請參閱 kro 文件中的[圖形推論](https://kro.run/docs/concepts/rgd/dependencies-ordering/)。 ## 使用 ACK 編寫 kro 與 ACK 的 EKS 功能無縫搭配運作，以使用 Kubernetes AWS 資源編寫資源： ``` resources: # Create {aws} S3 bucket with ACK - id: bucket template: apiVersion: s3.services.k8s.aws/v1alpha1 kind: Bucket spec: name: ${schema.spec.name}-files # Inject bucket details into Kubernetes ConfigMap - id: config template: apiVersion: v1 kind: ConfigMap data: BUCKET_NAME: ${bucket.spec.name} BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn} # Use ConfigMap in application deployment - id: deployment template: apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: app envFrom: - configMapRef: name: ${config.metadata.name} ``` 此模式可讓您建立 AWS 資源、擷取其詳細資訊 (ARNs、URLs、端點），並將它們插入您的應用程式組態，全都以單一單位管理。 如需更多合成模式和進階範例，請參閱 [EKS 的 kro 考量](kro-considerations.md)。 ## 後續步驟 + [EKS 的 kro 考量](kro-considerations.md) - 了解 EKS 特定的模式、RBAC 以及與 ACK 和 Argo CD 的整合 + [kro 文件](https://kro.run/docs/overview) - 完整的 kro 文件，包括進階 CEL 表達式、驗證模式和故障診斷 # 設定 kro 許可 與 ACK 和 Argo CD 不同，kro 不需要 IAM 許可。 kro 完全在您的 Kubernetes 叢集內運作，而且不會進行 AWS API 呼叫。使用標準 Kubernetes RBAC 控制對 kro 資源的存取。 ## 許可如何使用 kro kro 使用兩種具有不同範圍的 Kubernetes 資源類型： **ResourceGraphDefinitions**：定義自訂 APIs叢集範圍資源。通常由設計和維護組織標準的平台團隊管理。 **執行個體**：從 ResourceGraphDefinitions 建立的命名空間範圍自訂資源。可由具有適當 RBAC 許可的應用程式團隊建立。 根據預設，kro 功能具有透過`AmazonEKSKROPolicy`存取項目政策管理 ResourceGraphDefinitions 及其執行個體的許可。不過，kro 需要額外的許可，才能建立和管理 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源 （例如部署、服務或 ACK 資源）。您必須透過存取項目政策或 Kubernetes RBAC 授予這些許可。如需授予這些許可的詳細資訊，請參閱 [kro 任意資源許可](capabilities-security.md#kro-resource-permissions)。 ## 平台團隊許可 平台團隊需要許可才能建立和管理 ResourceGraphDefinitions。 **平台團隊的範例 ClusterRole**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kro-platform-admin rules: - apiGroups: ["kro.run"] resources: ["resourcegraphdefinitions"] verbs: ["*"] ``` **綁定平台團隊成員**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: platform-team-kro-admin subjects: - kind: Group name: platform-team apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: kro-platform-admin apiGroup: rbac.authorization.k8s.io ``` ## 應用程式團隊許可 應用程式團隊需要許可，才能在其命名空間中建立自訂資源的執行個體。 **應用程式團隊的角色範例**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kro-app-developer namespace: my-app rules: - apiGroups: ["kro.run"] resources: ["webapps", "databases"] verbs: ["create", "get", "list", "update", "delete", "patch"] ``` **繫結至應用程式團隊成員**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app-team-kro-developer namespace: my-app subjects: - kind: Group name: app-team apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: kro-app-developer apiGroup: rbac.authorization.k8s.io ``` **注意** 角色中的 API 群組 (`kro.run`在此範例中） 必須符合 ResourceGraphDefinition 結構描述中`apiVersion`定義的 。 ## 唯讀存取 授予唯讀存取權以檢視 ResourceGraphDefinitions 和執行個體，無需修改許可。 **唯讀 ClusterRole**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kro-viewer rules: - apiGroups: ["kro.run"] resources: ["resourcegraphdefinitions"] verbs: ["get", "list", "watch"] ``` **執行個體的唯讀角色**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kro-instance-viewer namespace: my-app rules: - apiGroups: ["kro.run"] resources: ["webapps", "databases"] verbs: ["get", "list", "watch"] ``` ## 多命名空間存取 授予應用程式團隊使用 ClusterRoles 搭配 RoleBindings 存取多個命名空間的權限。 **用於多命名空間存取的 ClusterRole**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kro-multi-namespace-developer rules: - apiGroups: ["kro.run"] resources: ["webapps"] verbs: ["create", "get", "list", "update", "delete"] ``` **繫結至特定命名空間**： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app-team-dev-access namespace: development subjects: - kind: Group name: app-team apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: kro-multi-namespace-developer apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app-team-staging-access namespace: staging subjects: - kind: Group name: app-team apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: kro-multi-namespace-developer apiGroup: rbac.authorization.k8s.io ``` ## 最佳實務 **最低權限原則**：僅授予每個團隊責任所需的最低許可。 **使用群組而非個別使用者**：將角色繫結至群組，而非個別使用者，以便於管理。 **個別的平台和應用程式考量**：平台團隊管理 ResourceGraphDefinitions、應用程式團隊管理執行個體。 **命名空間隔離**：使用命名空間隔離不同的團隊或環境，讓 RBAC 控制對每個命名空間的存取。 **稽核的唯讀存取權**：為安全與合規團隊提供稽核目的的唯讀存取權。 ## 後續步驟 + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源合成 + [kro 概念](kro-concepts.md) - 了解 SimpleSchema、CEL 表達式和合成模式 + [EKS 功能的安全考量](capabilities-security.md) - 檢閱 功能的安全最佳實務 # EKS 的 kro 考量 本主題涵蓋使用 kro 的 EKS 功能的重要考量，包括何時使用資源合成、RBAC 模式，以及與其他 EKS 功能的整合。 ## 何時使用 kro kro 旨在建立可重複使用的基礎設施模式和自訂 APIs，以簡化複雜的資源管理。 **當您需要下列項目時，請使用 kro**： + 使用簡化APIs 為應用程式團隊建立自助式平台 + 標準化跨團隊的基礎設施模式 （資料庫 \$1 備份 \$1 監控） + 管理資源相依性，並在資源之間傳遞值 + 建置可隱藏實作複雜性的自訂抽象概念 + 將多個 ACK 資源組成更高階的建置區塊 + 為複雜的基礎設施堆疊啟用 GitOps 工作流程 **以下情況請勿使用 kro**： + 管理簡單、獨立的資源 （直接使用 ACK 或 Kubernetes 資源） + 您需要動態執行時間邏輯 (kro 是宣告式而非必要） + 資源沒有相依性或共用組態 kro 擅長建立「鋪設路徑」 - 有意見且可重複使用的模式，可讓團隊輕鬆正確部署複雜的基礎設施。 ## RBAC 模式 kro 可讓建立 ResourceGraphDefinitions 的平台團隊和建立執行個體的應用程式團隊之間分離疑慮。 ### 平台團隊責任 平台團隊會建立和維護定義自訂 APIs ResourceGraphDefinitions (RGDs)。 **所需的許可**： + 建立、更新、刪除 ResourceGraphDefinitions + 管理基礎資源類型 （部署、服務、ACK 資源） + 存取將使用 RGDs的所有命名空間 **平台團隊的範例 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 許可](kro-permissions.md)。 ### 應用程式團隊的責任 應用程式團隊會建立 RGDs定義的自訂資源執行個體，而不需要了解基礎複雜性。 **所需的許可**： + 建立、更新、刪除自訂資源的執行個體 + 對其命名空間的讀取存取權 + 無法存取基礎資源或 RGDs **優點**： + 團隊使用簡單、高階 APIs + 平台團隊控制實作詳細資訊 + 降低組態錯誤的風險 + 加快新團隊成員的加入速度 ## 與其他 EKS 功能整合 ### 編寫 ACK 資源 與 ACK 結合以建立基礎設施模式時，kro 特別強大。 **常見模式**： + **具有儲存體的應用程式**：S3 儲存貯體 \$1 SQS 佇列 \$1 通知組態 + **資料庫堆疊**：RDS 執行個體 \$1 參數群組 \$1 安全群組 \$1 Secrets Manager 秘密 + **網路**：VPC \$1 子網路 \$1 路由表 \$1 安全群組 \$1 NAT 閘道 + **使用儲存體運算**：EC2 執行個體 \$1 EBS 磁碟區 \$1 IAM 執行個體描述檔 kro 會處理相依性排序、在資源之間傳遞值 （例如 ARNs 和連線字串），並以單一單位管理完整生命週期。 如需編寫 ACK 資源的範例，請參閱 [ACK 概念](ack-concepts.md)。 ### 使用 Argo CD 的 GitOps 使用適用於 Argo CD 的 EKS 功能，從 Git 儲存庫部署 RGDs 和執行個體。 **儲存庫組織**： + **平台儲存庫**：包含由平台團隊管理的 ResourceGraphDefinitions + **應用程式儲存庫**：包含應用程式團隊管理的自訂資源執行個體 + **共用儲存庫**：包含小型組織的 RGDs 和執行個體 **考量：** + 在執行個體之前部署 RGDs(Argo CD 同步波可協助您） + 為平台和應用程式團隊使用單獨的 Argo CD 專案 + 平台團隊控制 RGD 儲存庫存取 + 應用程式團隊具有 RGD 定義的唯讀存取權 如需 Argo CD 的詳細資訊，請參閱[使用 Argo CD](working-with-argocd.md)。 ## 組織 ResourceGraphDefinitions 依用途、複雜性和擁有權來組織 RGDs。 **依用途**： + **基礎設施**：資料庫堆疊、聯網、儲存 + **應用程式**：Web 應用程式、APIs、批次任務 + **平台**：共用服務、監控、記錄 **根據複雜性**： + **簡單**：2-3 個具有最少相依性的 資源 + **中等**：具有某些相依性的 5-10 個資源 + **複雜**：超過 10 個具有複雜相依性的資源 **命名慣例**： + 使用描述性名稱：`webapp-with-database`、 `s3-notification-queue` + 在名稱中包含版本以進行重大變更： `webapp-v2` + 對相關 RGDs 使用一致的字首：`platform- `、 `app-` **命名空間策略**： + RGDs是叢集範圍 （非命名空間） + 執行個體為命名空間 + 在 RGDs 中使用命名空間選擇器來控制可以建立執行個體的位置 ## 版本控制和更新 規劃 RGD 演變和執行個體遷移。 **RGD 更新**： + **非重大變更**：就地更新 RGD （新增選用欄位、使用 includeWhen 的新資源） + **重大變更**：使用不同名稱建立新的 RGD (webapp-v2) + **棄用**：使用註釋標記舊 RGDs、傳達遷移時間表 **執行個體遷移**： + 使用更新的 RGD 建立新的執行個體 + 驗證新執行個體是否正常運作 + 刪除舊執行個體 + kro 會自動處理基礎資源更新 **最佳實務**： + 先測試非生產環境中的 RGD 變更 + 在 RGD 名稱中使用語意版本控制進行主要變更 + 文件重大變更和遷移路徑 + 為應用程式團隊提供遷移範例 ## 驗證和測試 在部署到生產環境之前驗證 RGDs。 **驗證策略**： + **結構描述驗證**：kro 會自動驗證 RGD 結構 + **乾執行執行個體**：在開發命名空間中建立測試執行個體 + **整合測試**：確認編寫的資源可一起運作 + **政策強制執行**：使用許可控制器強制執行組織標準 **要測試的常見問題**： + 資源相依性和排序 + 在資源之間傳遞的值 (CEL 表達式） + 條件式資源包含 (includeWhen) + 基礎資源的狀態傳播 + 執行個體建立的 RBAC 許可 ## 上游文件 如需使用 kro 的詳細資訊： + [kro 入門](https://kro.run/docs/guides/getting-started) - 建立 ResourceGraphDefinitions + [CEL 表達式](https://kro.run/docs/concepts/cel) - 撰寫 CEL 表達式 + [kro Guides](https://kro.run/docs/guides/) - 進階合成模式 + [故障診斷](https://kro.run/docs/troubleshooting) - 故障診斷和偵錯 ## 後續步驟 + [設定 kro 許可](kro-permissions.md) - 為平台和應用程式團隊設定 RBAC + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源生命週期 + [對 kro 功能的問題進行故障診斷](kro-troubleshooting.md) - 對 kro 問題進行故障診斷 + [ACK 概念](ack-concepts.md) - 了解用於合成的 ACK 資源 + [使用 Argo CD](working-with-argocd.md) - 使用 GitOps 部署 RGDs 和執行個體 # 對 kro 功能的問題進行故障診斷 本主題提供 kro 的 EKS 功能疑難排解指引，包括功能運作狀態檢查、RBAC 許可、CEL 表達式錯誤和資源合成問題。 **注意** EKS 功能是完全受管的，並在叢集外部執行。您無法存取控制器日誌或`kro-system`命名空間。故障診斷著重於功能運作狀態、RBAC 組態和資源狀態。 ## 功能為 ACTIVE，但 ResourceGraphDefinitions 無法運作 如果您的 kro 功能顯示`ACTIVE`狀態，但 ResourceGraphDefinitions 未建立基礎資源，請檢查功能運作狀態、RBAC 許可和資源狀態。 **檢查功能運作狀態**： 您可以在 EKS 主控台或使用 AWS CLI 檢視功能運作狀態和狀態問題。 **主控台**： 1. 在以下網址開啟 Amazon EKS 主控台：https://console.aws.amazon.com/eks/home\$1/clusters。 1. 選取您的叢集名稱。 1. 選擇**可觀測性**索引標籤。 1. 選擇**監控叢集**。 1. 選擇**功能**索引標籤以檢視所有功能的運作狀態和狀態。 ** AWS CLI**： ``` # View capability status and health aws eks describe-capability \ --region region-code \ --cluster-name my-cluster \ --capability-name my-kro # Look for issues in the health section ``` **常見原因**： + **缺少 RBAC 許可**：kro 缺少建立基礎 Kubernetes 資源的許可 + **無效的 CEL 表達式**：ResourceGraphDefinition 中的語法錯誤 + **資源相依性**：相依資源未就緒 + **結構描述驗證**：執行個體不符合 RGD 結構描述要求 **驗證 RBAC 許可**： ``` # Check if capability has cluster admin policy kubectl get accessentry -A | grep kro ``` 如果功能沒有所需的許可，請將 `AmazonEKSClusterAdminPolicy`與 kro 功能的存取項目建立關聯，或建立更嚴格的 RBAC 政策以供生產使用。如需詳細資訊，請參閱 [設定 kro 許可](kro-permissions.md)。 **檢查 ResourceGraphDefinition 狀態**： ``` # List all RGDs kubectl get resourcegraphdefinition # Describe specific RGD kubectl describe resourcegraphdefinition my-rgd # Check for validation errors kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}' ``` ResourceGraphDefinitions 有三個金鑰狀態條件： + `ResourceGraphAccepted` - RGD 是否通過驗證 (CEL 語法、類型檢查、欄位存在） + `KindReady` - 是否產生並註冊自訂 API 的 CRD + `ControllerReady` - kro 是否正在主動監看自訂 API 的執行個體 如果 `ResourceGraphAccepted`是 `False`，請檢查條件訊息是否有驗證錯誤，例如未知欄位、類型不相符或循環相依性。 ## 已建立執行個體，但基礎資源未顯示 如果自訂資源執行個體存在，但未建立基礎 Kubernetes 資源 （部署、服務、ConfigMaps)，請確認 kro 具有許可並檢查合成錯誤。 **檢查執行個體狀態**： ``` # Describe the instance (replace with your custom resource kind and name) kubectl describe custom-kind my-instance # View instance events kubectl get events --field-selector involvedObject.name=my-instance # Check instance status conditions kubectl get custom-kind my-instance -o jsonpath='{.status.conditions}' # Check instance state kubectl get custom-kind my-instance -o jsonpath='{.status.state}' ``` 執行個體具有顯示高階狀態`state`的欄位： + `ACTIVE` - 執行個體已成功執行 + `IN_PROGRESS` - 正在處理或調校執行個體 + `FAILED` - 執行個體無法協調 + `DELETING` - 正在刪除執行個體 + `ERROR` - 處理期間發生錯誤 執行個體也有四個狀態條件： + `InstanceManaged` - 已正確設定定案者和標籤 + `GraphResolved` - 建立執行期圖表並解析資源 + `ResourcesReady` - 所有已建立並就緒的資源 + `Ready` - 整體執行個體運作狀態 （只有在所有子條件皆為 `True`時才會變成 `True`) 專注於 `Ready`條件，以判斷執行個體的運作狀態。如果 `Ready`是 `False`，請檢查子條件以識別哪個階段失敗。 **驗證 RBAC 許可**： kro 功能需要許可才能建立 ResourceGraphDefinitions 中定義的基礎 Kubernetes 資源。 ``` # Check if the capability has the AmazonEKSClusterAdminPolicy kubectl get accessentry -A | grep kro ``` 如果缺少許可，請將 `AmazonEKSClusterAdminPolicy`與 kro 功能的存取項目建立關聯，或建立更嚴格的 RBAC 政策以供生產使用。如需詳細資訊，請參閱 [設定 kro 許可](kro-permissions.md)。 ## CEL 表達式錯誤 CEL 表達式錯誤會在 ResourceGraphDefinition 建立時間發現，而不是在建立執行個體時。 kro 會驗證所有 CEL 語法、針對 Kubernetes 結構描述類型檢查表達式，並在建立 RGD 時驗證欄位是否存在。 **常見的 CEL 驗證錯誤**： + **未定義的欄位參考**：參考結構描述或資源中不存在的欄位 + **類型不符**：運算式傳回錯誤類型 （例如，預期整數的字串） + **無效的語法**：CEL 表達式中缺少括號、引號或運算子 + **未知資源類型**：參考叢集中不存在的 CRD **檢查 RGD 驗證狀態**： ``` # Check if RGD was accepted kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}' # View detailed validation errors kubectl describe resourcegraphdefinition my-rgd ``` 如果 `ResourceGraphAccepted`是 `False`，則條件訊息會包含驗證錯誤。 **有效的 CEL 表達式範例**： ``` # Reference schema field ${schema.spec.appName} # Conditional expression ${schema.spec.replicas > 1} # String template (expressions must return strings) name: "${schema.spec.appName}-service" # Standalone expression (can be any type) replicas: ${schema.spec.replicaCount} # Resource reference ${deployment.status.availableReplicas} # Optional field access (returns null if field doesn't exist) ${configmap.data.?DATABASE_URL} ``` ## 資源相依性無法解析 kro 會自動從 CEL 表達式推斷相依性，並以正確的順序建立資源。如果未如預期般建立資源，請檢查相依性順序和資源整備。 **檢視計算的建立順序**： ``` # See the order kro will create resources kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}' ``` 這會顯示資源之間根據 CEL 表達式參考計算的順序。 **檢查資源準備程度**： ``` # View instance status to see which resources are ready kubectl get custom-kind my-instance -o jsonpath='{.status}' # Check specific resource status kubectl get deployment my-deployment -o jsonpath='{.status.conditions}' ``` **確認readyWhen條件 （如果使用）**： 此 `readyWhen` 欄位為選用。如果未指定，資源會在建立後立即視為就緒。如果您已定義`readyWhen`條件，請確認它們是否正確檢查資源準備程度： ``` resources: - id: deployment readyWhen: - ${deployment.status.availableReplicas == deployment.spec.replicas} ``` **檢查資源事件**： ``` # View events for the underlying resources kubectl get events -n namespace --sort-by='.lastTimestamp' ``` ## 結構描述驗證失敗 如果執行個體因為結構描述驗證錯誤而無法建立，請確認執行個體符合 RGD 結構描述要求。 **檢查驗證錯誤**： ``` # Attempt to create instance and view error kubectl apply -f instance.yaml # View existing instance validation status kubectl describe custom-kind my-instance | grep -A 5 "Validation" ``` **常見的驗證問題**： + **缺少必要欄位**：執行個體不提供所有必要的結構描述欄位 + **類型不符**：提供預期整數的字串 + **列舉值無效**：使用不在允許清單中的值 + **模式不相符**：字串不符合 regex 模式 **檢閱 RGD 結構描述**： ``` # View the schema definition kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}' ``` 確保您的執行個體為所有必要欄位提供正確的類型。 ## 後續步驟 + [EKS 的 kro 考量](kro-considerations.md) - kro 考量事項和最佳實務 + [設定 kro 許可](kro-permissions.md) - 為平台和應用程式團隊設定 RBAC + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源生命週期 + [對 EKS 功能進行故障診斷](capabilities-troubleshooting.md) - 一般功能故障診斷指引 # 比較 kro 與自我管理 kro 的 EKS 功能 適用於 kro 的 EKS 功能提供與自我管理 kro 相同的功能，但具有顯著的操作優勢。如需 EKS 功能與自我管理解決方案的一般比較，請參閱 [EKS 功能考量事項](capabilities-considerations.md)。 kro 的 EKS 功能使用相同的上游 kro 控制器，並與上游 kro 完全相容。ResourceGraphDefinitions、CEL 表達式和資源合成的運作方式相同。如需完整的 kro 文件和範例，請參閱 [kro 文件](https://kro.run/docs/overview)。 ## 遷移路徑 您可以從自我管理的 kro 遷移到受管功能，無需停機。 **重要** 在遷移之前，請確保您的自我管理 kro 控制器執行的版本與 kro 的 EKS 功能相同。在 EKS 主控台或使用 檢查功能版本`aws eks describe-capability`，然後升級自我管理的安裝以符合。這可防止遷移期間的相容性問題。 1. 更新您的自我管理 kro 控制器以`kube-system`用於領導者選擇租用： ``` helm upgrade --install kro \ oci://ghcr.io/awslabs/kro/kro-chart \ --namespace kro \ --set leaderElection.namespace=kube-system ``` 這會將控制器的租用移至 `kube-system`，允許受管功能與其協調。 1. 在叢集上建立 kro 功能 （請參閱 [建立 kro 功能](create-kro-capability.md)) 1. 受管功能可識別現有的 ResourceGraphDefinitions 和執行個體，接管對帳 1. 逐漸縮減或移除自我管理的 kro 部署： ``` helm uninstall kro --namespace kro ``` 此方法可讓兩個控制器在遷移期間安全地共存。受管功能會自動採用 ResourceGraphDefinitions 和先前由自我管理的 kro 管理的執行個體，以確保持續對帳而不會發生衝突。 ## 後續步驟 + [建立 kro 功能](create-kro-capability.md) - 建立 kro 功能資源 + [kro 概念](kro-concepts.md) - 了解 kro 概念和資源合成