このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
AWS CLI を使用して kro 機能を作成する
このトピックでは、AWS CLI を使用して kro (Kube Resource Orchestrator) 機能を作成する方法について説明します。
前提条件
-
AWS CLI バージョン
2.12.3以降。バージョンを確認するには、aws --versionを実行します。詳細についてはAWS コマンドラインインターフェイスユーザーガイドの「インストール」を参照してください。 -
kubectl- Kubernetes クラスターを操作するためのコマンドラインツール。詳細については、「kubectl および eksctl のセットアップ」を参照してください。
ステップ 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 \ --regionregion-code\ --cluster-namemy-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 \ --regionregion-code\ --cluster-namemy-cluster\ --capability-name my-kro \ --query 'capability.status' \ --output text
ステータスが ACTIVE と表示されたら、機能の準備は完了です。
機能の詳細全体を表示することもできます。
aws eks describe-capability \ --regionregion-code\ --cluster-namemy-cluster\ --capability-name my-kro
ステップ 4: Kubernetes リソースを管理するためのアクセス許可を付与する
kro 機能を作成すると、AmazonEKSKROPolicy を使用して EKS アクセスエントリが自動的に作成されます。これにより、kro で ResourceGraphDefinitions とそのインスタンスを管理できます。ただし、ResourceGraphDefinitions で定義されている基盤となる Kubernetes リソース (デプロイ、サービス、ConfigMaps など) を作成するアクセス許可はデフォルトでは付与されません。
この設計は、最小特権の原則に従った意図的なものです。異なる ResourceGraphDefinitions にはそれぞれ異なるアクセス許可が必要となります。例: *ConfigMaps と Secrets のみを作成する ResourceGraphDefinition には、デプロイとサービスを作成する ResourceGraphDefinition とは異なるアクセス許可が必要です。*ACK リソースを作成する ResourceGraphDefinition には、それらの特定のカスタムリソースに対するアクセス許可が必要です。*一部の ResourceGraphDefinitions は、新しいリソースを作成せずに既存のリソースのみを読み取る場合があります。
それぞれの ResourceGraphDefinitions が管理するリソースに基づいて、kro に必要なアクセス許可を明示的に設定する必要があります。
Quick Setup
迅速な開始、テスト、または開発環境については、AmazonEKSClusterAdminPolicy を使用します。
機能ロール ARN を取得します。
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \ --regionregion-code\ --cluster-namemy-cluster\ --capability-name my-kro \ --query 'capability.roleArn' \ --output text)
クラスター管理ポリシーを関連付けます。
aws eks associate-access-policy \ --regionregion-code\ --cluster-namemy-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 アクセス許可の設定」および「EKS 機能のセキュリティに関する考慮事項」を参照してください。
ステップ 5: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、kro カスタムリソースがクラスターで使用可能になっていることを確認します。
kubectl api-resources | grep kro.run
ResourceGraphDefinition リソースタイプがリストされます。