**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# kro (Kube Resource Orchestrator) を使用したリソース構成
**kro (Kube Resource Orchestrator)** はオープンソースの Kubernetes ネイティブプロジェクトで、シンプルで簡単な設定を使用してカスタム Kubernetes API を定義できます。kro を使用すると、Kubernetes オブジェクトのグループとその間の論理オペレーションを作成する新しいカスタム API を簡単に設定できます。
AWS では EKS の機能を使用して kro を完全に管理できるため、クラスターに kro コントローラーを導入して保守およびスケールする必要がありません。
## kro の仕組み
kro では、カスタム Kubernetes API を簡潔かつ効率的に作成できる `ResourceGraphDefinition` (RGD) というカスタムリソース定義 (CRD) が導入されています。`ResourceGraphDefinition` を作成すると、kro はネイティブの Kubernetes 拡張機能を使用して、クラスターに新しい API を作成および管理します。この単一のリソース仕様から、kro は仕様に基づいて新しい CRD を作成して登録し、新しく定義されたカスタムリソースを管理するように適応します。
RGD には複数のリソースを含めることができ、kro が相互依存関係とリソースの順序を決定するため、ユーザーがそれを行う必要はありません。シンプルな構文を使用して、あるリソースから別のリソースに設定を挿入できるため、構成が大幅に簡素化され、クラスター内の「グルー」演算子が不要になります。kro を使用すると、カスタムリソースには、ネイティブの Kubernetes リソースだけでなく、クラスターにインストールされている任意のカスタムリソース定義 (CRD) も含めることができます。
kro は、1 つの主要なリソースタイプをサポートしています。
+ **ResourceGraphDefinition (RGD)**: Kubernetes カスタムリソースを定義し、1 つ以上の基盤となるネイティブまたはカスタム Kubernetes リソースをカプセル化します。
このリソースに加えて、kro は、RGD を使用して作成されたカスタムリソースと、それらを構成するすべてのリソースのライフサイクルを作成および管理します。
kro は AWS Controllers for Kubernetes (ACK) とシームレスに統合されており、ワークロードリソースと AWS リソースを組み合わせて、より高いレベルの抽象化を作成できます。これにより、独自のクラウド構成要素を作成し、リソース管理を簡素化し、組織標準に基づくデフォルトおよびイミュータブルな構成設定で再利用可能なパターンを有効にすることができます。
## kro のメリット
kro を使用すると、プラットフォームチームは、複数のリソースを高レベルの抽象化に構成するカスタム Kubernetes API を作成できます。これにより、開発者は、シンプルで標準化され、バージョン管理されたカスタムリソースを使用して複雑なアプリケーションをデプロイできるため、リソース管理が簡素化されます。一般的なリソースの組み合わせに再利用可能なパターンを定義することで、組織全体で一貫したリソースの作成が可能になります。
kro は、[Kubernetes の Common Expression Language (CEL)](https://kubernetes.io/docs/reference/using-api/cel/) を使用してリソース間で値を渡し、条件付きロジックを組み込むことで、リソース構成に柔軟性を提供します。Kubernetes リソースと、ACK によって管理される AWS リソースの両方を統合したカスタム API に構成できるため、アプリケーションとインフラストラクチャの完全な定義が可能になります。
kro は、Kubernetes マニフェストによる宣言型設定をサポートしており、既存の開発プロセスとシームレスに統合される GitOps ワークフローや Infrastructure as Code のプラクティスを実現します。AWS では、EKS マネージド機能の一部として、kro を完全に管理できるため、クラスターに kro コントローラーを導入して設定および保守する必要がありません。
**例: ResourceGraphDefinition の作成**
次の例は、デプロイとサービスを使用してウェブアプリケーションを作成するシンプルな `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 マネージド機能と統合されています。
+ **Kubernetes 用 AWS コントローラー (ACK)**: kro を使用して ACK リソースを高レベルの抽象化に構成し、AWS リソース管理を簡素化します。
+ **Argo CD**: Argo CD を使用して、複数のクラスターにまたがる kro カスタムリソースのデプロイを管理し、プラットフォームの構成要素とアプリケーションスタックの GitOps ワークフローを有効にします。
## kro の開始方法
EKS Capability for kro の使用を開始するには:
1. AWS コンソール、AWS CLI、または任意の Infrastructure as Code ツールを使用して、EKS クラスターに [kro 機能リソースを作成](create-kro-capability.md)します。
1. カスタム API とリソース構成を定義する ResourceGraphDefinitions (RGDs) を作成します。
1. カスタムリソースのインスタンスを適用して、基盤となる Kubernetes リソースと AWS リソースをプロビジョニングおよび管理します。
# kro 機能の作成
このトピックでは、Amazon EKS クラスター上で kro 機能を作成する方法について説明します。
## 前提条件
kro 機能を作成する前に、以下があることを確認してください。
+ サポート対象の Kubernetes バージョン (標準サポートと延長サポートのすべてのバージョンがサポート対象) を実行している Amazon EKS クラスターが存在する
+ EKS クラスターに機能リソースを作成するための十分な IAM アクセス許可がある
+ (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) - 指示に従って操作する場合はコンソールを使用します。
+ [AWS CLI を使用して kro 機能を作成する](kro-create-cli.md) - スクリプトを作成して自動化を図る場合は AWS CLI を使用します。
+ [eksctl を使用して kro 機能を作成する](kro-create-eksctl.md) - Kubernetes ネイティブの操作をする場合は eksctl を使用します。
## kro 機能を作成した場合の動作
kro 機能を作成すると、次の処理が行われます。
1. EKS は kro 機能サービスを作成し、クラスター内のリソースを監視および管理するように設定する
1. カスタムリソース定義 (CRD) がクラスターにインストールされます。
1. ResourceGraphDefinitions とそのインスタンスを管理するアクセス許可を付与する `AmazonEKSKROPolicy` を使用して、IAM 機能ロールのアクセスエントリが自動的に作成されます (「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照)。
1. kro 機能が、指定した IAM 機能ロールを引き受ける (信頼関係にのみ使用される)
1. kro が `ResourceGraphDefinition` リソースとそのインスタンスの監視を開始する
1. 機能のステータスが `CREATING` から `ACTIVE` に変わります。
アクティブになったら、ResourceGraphDefinitions を作成してカスタム API を定義し、それらの API のインスタンスを作成できます。
**注記**
自動的に作成されたアクセスエントリには、ResourceGraphDefinitions とそのインスタンスを管理するための kro アクセス許可を付与する `AmazonEKSKROPolicy` が含まれます。ResourceGraphDefinitions で定義されている基盤となる Kubernetes リソース (デプロイ、サービス、ACK リソースなど) を kro で作成するには、追加のアクセスエントリポリシーを設定する必要があります。アクセスエントリの詳細と追加のアクセス許可の設定方法については、「[kro アクセス許可の設定](kro-permissions.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## 次のステップ
kro 機能を作成した後:
+ [kro の概念](kro-concepts.md) - kro の概念とリソース構成を理解する
+ [kro の概念](kro-concepts.md) - SimpleSchema、CEL 式、リソース構成パターンについて学ぶ
# コンソールを使用して kro 機能を作成する
このトピックでは、AWS マネジメントコンソール を使用して kro (Kube Resource Orchestrator) 機能を作成する方法について説明します。
## kro 機能を作成する
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. 左側のナビゲーションで、**[kro (Kube Resource Orchestrator)]** を選択します。
1. **[kro 機能の作成]** を選択します。
1. **IAM 機能ロール**に対して以下の操作を行います。
+ IAM 機能ロールが既に存在する場合は、ドロップダウンから選択します。
+ 新しいロールを作成する必要がある場合は、**[kro ロールを作成]** を選択します。
これにより、信頼ポリシーが事前に入力された新しいタブで IAM コンソールが開きます。kro はクラスター内で完全に動作するため、このロールには追加の IAM アクセス許可は必要ありません。
ロールを作成して EKS コンソールに戻ると、そのロールが自動的に選択されます。
**注記**
ACK や Argo CD とは異なり、kro は信頼ポリシー以外の追加の IAM アクセス許可を必要としません。kro はクラスター内で完全に動作し、AWS API コールを行いません。
1. **[作成]** を選択します。
機能作成プロセスが始まります。
## 機能がアクティブであることを確認する
1. **[機能]** タブで、kro 機能のステータスを表示します。
1. ステータスが `CREATING` から `ACTIVE` に変わるまで待ちます。
1. アクティブになったら、この機能を使用する準備は完了です。
機能のステータスとトラブルシューティングの詳細については、「[機能リソースの使用](working-with-capabilities.md)」を参照してください。
## Kubernetes リソースを管理するためのアクセス許可を付与する
kro 機能を作成すると、`AmazonEKSKROPolicy` を使用して EKS アクセスエントリが自動的に作成されます。これにより、kro で ResourceGraphDefinitions とそのインスタンスを管理できます。ただし、ResourceGraphDefinitions で定義されている基盤となる Kubernetes リソース (デプロイ、サービス、ConfigMaps など) を作成するアクセス許可はデフォルトでは付与されません。
この設計は、最小特権の原則に従った意図的なものです。異なる ResourceGraphDefinitions にはそれぞれ異なるアクセス許可が必要となります。それぞれの ResourceGraphDefinitions が管理するリソースに基づいて、kro に必要なアクセス許可を明示的に設定する必要があります。
迅速な開始、テスト、または開発環境については、`AmazonEKSClusterAdminPolicy` を使用します。
1. EKS コンソールで、クラスターの **[アクセス]** タブに移動します。
1. **[アクセスエントリ]** で、kro 機能ロールのエントリを見つけます (以前に作成したロール ARN が表示されます)。
1. アクセスエントリを選択して詳細を開きます。
1. **[アクセスポリシー]** セクションで、**[アクセスポリシーを関連付ける]** を選択します。
1. ポリシーリストから `AmazonEKSClusterAdminPolicy` を選択します。
1. **[アクセスの範囲]** で、**[クラスター]** を選択します。
1. **関連付ける** を選択してください。
**重要**
`AmazonEKSClusterAdminPolicy` は、すべての名前空間について任意のリソースタイプを作成する機能など、すべての Kubernetes リソースを作成および管理するための広範なアクセス許可を付与します。これは開発や POC には便利ですが、本番環境では使用しないでください。本番環境では、それぞれの ResourceGraphDefinitions が管理する特定のリソースに必要なアクセス許可のみを付与する、カスタム RBAC ポリシーを作成してください。最小特権のアクセス許可の設定に関するガイダンスについては、「[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 機能リソースを管理する
# AWS CLI を使用して kro 機能を作成する
このトピックでは、AWS CLI を使用して kro (Kube Resource Orchestrator) 機能を作成する方法について説明します。
## 前提条件
+ **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 機能を作成すると、`AmazonEKSKROPolicy` を使用して EKS アクセスエントリが自動的に作成されます。これにより、kro で ResourceGraphDefinitions とそのインスタンスを管理できます。ただし、ResourceGraphDefinitions で定義されている基盤となる Kubernetes リソース (デプロイ、サービス、ConfigMaps など) を作成するアクセス許可はデフォルトでは付与されません。
この設計は、最小特権の原則に従った意図的なものです。異なる ResourceGraphDefinitions にはそれぞれ異なるアクセス許可が必要となります。例: \$1ConfigMaps と Secrets のみを作成する ResourceGraphDefinition には、デプロイとサービスを作成する ResourceGraphDefinition とは異なるアクセス許可が必要です。\$1ACK リソースを作成する ResourceGraphDefinition には、それらの特定のカスタムリソースに対するアクセス許可が必要です。\$1一部の ResourceGraphDefinitions は、新しいリソースを作成せずに既存のリソースのみを読み取る場合があります。
それぞれの ResourceGraphDefinitions が管理するリソースに基づいて、kro に必要なアクセス許可を明示的に設定する必要があります。
### Quick Setup
迅速な開始、テスト、または開発環境については、`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 リソースを作成および管理するための広範なアクセス許可を付与します。これは開発や POC には便利ですが、本番環境では使用しないでください。本番環境では、それぞれの ResourceGraphDefinitions が管理する特定のリソースに必要なアクセス許可のみを付与する、カスタム RBAC ポリシーを作成してください。最小特権のアクセス許可の設定に関するガイダンスについては、「[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 リソースを作成および管理するための広範なアクセス許可を付与し、使用開始を効率化することを目的としています。本番稼働用には、ResourceGraphDefinitions が管理する特定のリソースに必要なアクセス許可のみを付与する、より制限の厳しい RBAC ポリシーを作成します。最小特権のアクセス許可の設定に関するガイダンスについては、「[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 API を作成できます。このトピックでは、実用的な例を取り上げ、EKS Capability for kro を使用する際に理解しておく必要がある重要な概念について説明します。
## kro の開始方法
kro 機能を作成した後 (「[kro 機能の作成](create-kro-capability.md)」を参照)、クラスターで ResourceGraphDefinitions を使用して、カスタム API の作成を開始できます。
シンプルなウェブアプリケーションの抽象化を作成する完全な例を次に示します。
```
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 を使用してウェブアプリケーションを作成できます。
```
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 Overview](https://kro.run/docs/concepts/rgd/overview/)」を参照してください。
### SimpleSchema 形式
SimpleSchema は、OpenAPI の知識を必要とせずに API スキーマを定義する簡単な方法を提供します。
```
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 は、`required`、`default`、`minimum`/`maximum`、`enum`、`pattern` などの制約がある、`string`、`integer`、`boolean`、`number` 型をサポートしています。
詳細については、kro ドキュメントの「[SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)」を参照してください。
### CEL 式
kro は、値を動的に参照し、条件付きロジックを追加するために、Common Expression Language (CEL) を使用します。CEL 式は `${` と `}` で囲まれ、次の 2 つの方法で使用できます。
**スタンドアロン式** - フィールド値全体が 1 つの式です。
```
spec:
replicas: ${schema.spec.replicaCount} # Expression returns integer
labels: ${schema.spec.labelMap} # Expression returns object
```
式の結果はフィールド値全体を置き換え、フィールドで想定されている型と一致する必要があります。
**文字列テンプレート** - 文字列に埋め込まれた 1 つ以上の式:
```
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 Expressions](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 ドキュメントの「[Graph inference](https://kro.run/docs/concepts/rgd/dependencies-ordering/)」を参照してください。
## ACK を使用した構成
kro は、EKS Capability for ACK とシームレスに連携し、AWS リソースを Kubernetes と組み合わせて構成します。
```
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 リソースを作成し、その詳細 (ARN、URL、エンドポイント) を抽出してアプリケーション設定に挿入できます。これらはすべて、1 つのユニットとして管理されます。
その他の構成パターンと詳細な例については、「[EKS を利用する場合の kro の考慮事項](kro-considerations.md)」を参照してください。
## 次のステップ
+ [EKS を利用する場合の kro の考慮事項](kro-considerations.md) - EKS 固有のパターン、RBAC、および ACK と Argo CD との統合について説明します。
+ [kro ドキュメント](https://kro.run/docs/overview) - 高度な CEL 式、検証パターン、トラブルシューティングを含む、kro の包括的なドキュメントです。
# kro アクセス許可の設定
ACK や Argo CD とは異なり、kro には IAM アクセス許可は必要ありません。kro は Kubernetes クラスター内で完全に動作し、AWS API コールを行いません。標準の Kubernetes RBAC を使用して kro リソースへのアクセスを制御します。
## kro でのアクセス許可の仕組み
kro は、異なるスコープを持つ 2 種類の Kubernetes リソースを使用します。
**ResourceGraphDefinitions**: カスタム API を定義するクラスタースコープのリソース。通常、組織の標準を設計および維持するプラットフォームチームによって管理されます。
**インスタンス**: 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"]
```
## マルチ名前空間アクセス
RoleBindings と ClusterRoles を使用して、アプリケーションチームに複数の名前空間へのアクセスを付与します。
**マルチ名前空間アクセス用の 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 の考慮事項
このトピックでは、リソース構成、RBAC パターン、他の EKS 機能との統合を使用するタイミングなど、EKS Capability for kro を使用する際の重要な考慮事項について説明します。
## kro を使用する場合
kro は、複雑なリソース管理を簡素化する、再利用可能なインフラストラクチャパターンとカスタム API を作成するように設計されています。
**次の場合に kro を使用します**。
+ アプリケーションチーム向けに、簡素化された API を備えたセルフサービスプラットフォームを作成する場合
+ チーム間でインフラストラクチャパターン (データベース \$1 バックアップ \$1 モニタリング) を標準化する場合
+ リソースの依存関係を管理し、リソース間で値を渡す場合
+ 実装の複雑さを隠すカスタム抽象化を構築する場合
+ 複数の ACK リソースを高レベルの構成要素に構成する場合
+ 複雑なインフラストラクチャスタックの GitOps ワークフローを有効にする場合
**次の場合は kro を使用しないでください**。
+ シンプルでスタンドアロンなリソースを管理する場合 (ACK または Kubernetes リソースを直接使用します)
+ 動的なランタイムロジックが必要な場合 (kro は命令型ではなく、宣言型です)
+ リソースに依存関係や共有設定がない場合
kro は、チームが複雑なインフラストラクチャを正しくデプロイしやすくする、意見が組み込まれた再利用可能なパターン (「paved paths」) の作成に優れています。
## RBAC パターン
kro を使用すると、ResourceGraphDefinitions を作成するプラットフォームチームと、インスタンスを作成するアプリケーションチームとの間で責務を分離できます。
### プラットフォームチームの責任
プラットフォームチームは、カスタム API を定義する 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 へのアクセス権は不要
**利点**:
+ チームはシンプルで高レベルの API を使用
+ プラットフォームチームが実装の詳細を制御
+ 設定ミスのリスクを低減
+ 新しいチームメンバーのオンボーディングを高速化
## 他の EKS 機能との統合
### ACK リソースの構成
kro は、ACK と組み合わせることで、インフラストラクチャパターンの作成において特に高い効果を発揮します。
**一般的なパターン**:
+ **ストレージを含むアプリケーション**: S3 バケット \$1 SQS キュー \$1 通知設定
+ **データベーススタック**: RDS インスタンス \$1 パラメータグループ \$1 セキュリティグループ \$1 Secrets Manager シークレット
+ **ネットワーク**: VPC \$1 サブネット \$1 ルートテーブル \$1 セキュリティグループ \$1 NAT ゲートウェイ
+ **ストレージを含むコンピューティング**: EC2 インスタンス \$1 EBS ボリューム \$1 IAM インスタンスプロファイル
kro は、依存関係の順序付けを処理し、リソース間で (ARN や接続文字列などの) 値を渡し、ライフサイクル全体を 1 つのユニットとして管理します。
ACK リソースを作成する例については、「[ACK の概念](ack-concepts.md)」を参照してください。
### GitOps と Argo CD
EKS Capability for Argo CD を使用して、Git リポジトリから RGDs とインスタンスの両方をデプロイします。
**リポジトリの整理**:
+ **プラットフォームリポジトリ**: プラットフォームチームが管理する ResourceGraphDefinitions を格納
+ **アプリケーションリポジトリ**: アプリケーションチームが管理するカスタムリソースのインスタンスを格納
+ **共有リポジトリ**: 小規模な組織向けに、RGDs とインスタンスの両方を格納
**考慮事項**:
+ インスタンスより先に RGDs をデプロイする (Argo CD の同期ウェーブが役立つ)
+ プラットフォームチームとアプリケーションチームに別々の Argo CD プロジェクトを使用する
+ プラットフォームチームが RGD リポジトリへのアクセスを制御する
+ アプリケーションチームには RGD 定義への読み取り専用アクセスを付与する
Argo CD の詳細については、「[Argo CD の使用](working-with-argocd.md)」を参照してください。
## ResourceGraphDefinitions の整理
目的、複雑さ、所有権別に RGDs を整理します。
**目的別**:
+ **インフラストラクチャ**: データベーススタック、ネットワーク、ストレージ
+ **アプリケーション**: ウェブアプリケーション、API、バッチジョブ
+ **プラットフォーム**: 共有サービス、モニタリング、ログ記録
**複雑さ別**:
+ **シンプル**: 依存関係が最小限の 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 ガイド](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 機能に関する問題をトラブルシューティングする
このトピックでは、機能ヘルスチェック、RBAC アクセス許可、CEL 式エラー、リソース構成の問題など、EKS Capability for kro をトラブルシューティングする際のガイダンスを提供します。
**注記**
EKS の機能は完全に管理され、クラスターの外部で実行されます。コントローラーログや `kro-system` 名前空間にアクセスすることはできません。トラブルシューティングでは、機能のヘルス、RBAC の設定、リソースのステータスに焦点を当てています。
## 機能は ACTIVE だが、ResourceGraphDefinitions が機能していない
kro 機能のステータスが `ACTIVE` なのに、ResourceGraphDefinitions が基盤となるリソースを作成していない場合は、機能ヘルス、RBAC アクセス許可、リソースステータスを確認してください。
**機能のヘルスを確認する**:
機能のヘルスとステータスの問題は、EKS コンソールまたは AWS CLI を使用して表示できます。
**コンソール:**
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
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 には 3 つの主要なステータス条件があります。
+ `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` - 処理中にエラーが発生しました。
インスタンスには、次の 4 つのステータス条件もあります。
+ `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 は、RGD の作成時に、すべての CEL 構文を検証し、Kubernetes スキーマに対して式の型チェックを行い、フィールドの存在を検証します。
**一般的な 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"
```
**一般的な検証の問題**:
+ **必須フィールドがない**: インスタンスがすべての必須スキーマフィールドを提供していません。
+ **型の不一致**: 整数が期待される箇所で文字列が指定されています。
+ **無効な列挙値**: 許可されているリストに含まれていない値が使用されています。
+ **パターンの不一致**: 文字列が正規表現パターンと一致していません。
**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) - 一般的な機能をトラブルシューティングする際のガイダンス
# EKS Capability for kro とセルフマネージド kro の比較
EKS Capability for kro は、セルフマネージド kro と同じ機能を提供しますが、運用上の大きな利点があります。EKS 機能とセルフマネージドソリューションの全般的な比較については、「[EKS 機能と考慮事項](capabilities-considerations.md)」を参照してください。
EKS Capability for kro は、同じアップストリームの kro コントローラーを使用し、アップストリームの kro と完全に互換性があります。ResourceGraphDefinitions、CEL 式、およびリソース構成は同じように機能します。完全な kro のドキュメントと例については、[kro ドキュメント](https://kro.run/docs/overview)を参照してください。
## 移行パス
セルフマネージド kro からマネージド機能にダウンタイムなしで移行できます。
**重要**
移行する前に、セルフマネージド kro コントローラーが EKS Capability for kro と同じバージョンで実行されていることを確認します。EKS コンソールまたは `aws eks describe-capability` を使用して機能バージョンを確認し、そのバージョンに一致するようにセルフマネージドのインストールをアップグレードします。これにより、移行中の互換性の問題を防ぐことができます。
1. リーダー選出リースに `kube-system` を使用するようにセルフマネージド kro コントローラーを更新します。
```
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
```
このアプローチにより、移行中、両方のコントローラーを安全に共存させることができます。マネージド機能がこれまでセルフマネージド kro で管理されていた ResourceGraphDefinitions とインスタンスを自動的に採用するので、引き続き競合なく調整を図ることができます。
## 次のステップ
+ [kro 機能の作成](create-kro-capability.md) - kro の機能リソースを作成する
+ [kro の概念](kro-concepts.md) - kro の概念とリソース構成を理解する