kroを使用したスタックの構成

ACKラボでは、cartsをAWSマネージド DynamoDB テーブルに移行するために、3つの別々のマニフェスト（Tableリソース、ConfigMapのオーバーライド、Pod Identityアソシエーション）を適用しました。これは一回限りの作業には適切ですが、多くのサービスでこれを実行するプラットフォームチームは、スタック全体をキャプチャする1つのユーザー向けリソースを必要とするでしょう。

このラボでは、EKS機能として提供されるkro (Kube Resource Orchestrator) を使用して、まさにそれを実現します。kroを使用すると、プラットフォームチームは多くのKubernetesリソースを1つのシンプルなカスタムリソースの背後にパッケージ化できます。2つの要素があります：

ResourceGraphDefinition (RGD) は設計図です。新しいカスタムリソースタイプ（ここではCartsStack）、それが受け入れるわずかな入力（テーブル名など）、および1つのインスタンスが展開される基盤となるリソースのグラフを定義します：Namespace、ACK Table、ConfigMap、ServiceAccount、Deployment、およびService。プラットフォームチームはこれを一度記述します。
インスタンスは、他のすべての人が適用するものです：入力のみが記入された短いCartsStackリソース。kroはそれを読み取り、正しい順序でグラフ全体を作成します。

他の機能と同様に、kroのコントローラーはクラスター外のAWS所有インフラストラクチャで実行され、AWSがその運用を処理します。クラスター内には、登録されたCustom Resource Definitions (CRD)のみが表示され、resourcegraphdefinitions.kro.runから始まります。

事前にセットアップされた内容

kro EKSマネージド機能がクラスターでACTIVEになっており、resourcegraphdefinitions.kro.run CRDが登録されています。
ACKラボのACK DynamoDB機能はまだACTIVEなので、kroはそのネイティブKubernetesオブジェクトと一緒にTableリソースを構成します。
事前にプロビジョニングされた${EKS_CLUSTER_AUTO_NAME}-carts-dynamo IAMロールは${EKS_CLUSTER_AUTO_NAME}-carts-*テーブルにワイルドカードスコープされているため、同じロールがACKラボの-carts-fastpathテーブルとkroラボの-carts-kroテーブルの両方を変更なしでカバーします。

このラボ全体を通じて、以下を行います：

kro機能がACTIVEであり、resourcegraphdefinitions.kro.run CRDが存在することを確認します。
Namespace + ACK Table + ConfigMap + ServiceAccount + Deployment + Serviceを構成するCartsStack ResourceGraphDefinitionを適用します。
CartsStackインスタンスを適用し、kroが子リソースを順序通りに調整することを観察し、その後Pod Identityアソシエーションをバインドして、carts Podが新しいテーブルを読み書きできるようにします。

1つのCartsStackの適用により、次のグラフが生成されます：

                適用するもの：
                CartsStack/carts-kro          (1つのCR、2つの必須フィールド)
                       │
                       ▼  kro reconcilerがRGDを展開
                       │
   ┌──────────┬────────┴──┬──────────┬─────────────┬──────────┐
   ▼          ▼           ▼          ▼             ▼          ▼
Namespace   Table     ConfigMap     SA        Deployment    Service
                        │                          │
                        ▼                          ▼
                   ACK DynamoDB                 Pod (carts-…)
                    controller                       │
                        │                            │ + aws eks create-pod-identity-association
                        ▼                            ▼
                AWS DynamoDB table          AWS_CONTAINER_CREDENTIALS
                (eks-workshop-…-carts-kro)   via Pod Identity Agent

備考

kroはKubernetesリソースのみを調整します。AWS APIを直接呼び出すことはありません。上のグラフにあるAWS DynamoDBテーブルは、ACKラボのACKコントローラーによって作成されます。kroはTableリソースを作成することでそれを駆動します。

機能の確認

機能がACTIVEであることを確認します：

~$aws eks describe-capability \

--cluster-name $EKS_CLUSTER_AUTO_NAME \

--capability-name $EKS_CAP_KRO_CAPABILITY \

--query 'capability.status' --output text

ACTIVE

次に、kroが登録したCRDを確認します。これは上記のRGD「設計図」タイプです：

~$kubectl api-resources --api-group=kro.run

NAME                       SHORTNAMES   APIVERSION         NAMESPACED   KIND

resourcegraphdefinitions   rgd          kro.run/v1alpha1   false        ResourceGraphDefinition

NAMESPACED: falseに注意してください：RGDはクラスタースコープです。なぜなら、設計図はクラスター全体で共有されるからです。それから作成するインスタンス（CartsStackリソース）は名前空間スコープです。なぜなら、各インスタンスは特定の名前空間内のリソースを所有するからです。機能がACTIVEでRGD CRDが配置されているので、最初のRGDを定義する準備が整いました。

機能の確認​

機能の確認