EKS を利用する場合の kro の考慮事項 - Amazon EKS
kro を使用する場合RBAC パターン他の EKS 機能との統合ResourceGraphDefinitions の整理バージョニングと更新検証とテストアップストリームドキュメント次のステップ

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS を利用する場合の kro の考慮事項

このトピックでは、リソース構成、RBAC パターン、他の EKS 機能との統合を使用するタイミングなど、EKS Capability for kro を使用する際の重要な考慮事項について説明します。

kro を使用する場合

kro は、複雑なリソース管理を簡素化する、再利用可能なインフラストラクチャパターンとカスタム API を作成するように設計されています。

次の場合に kro を使用します。

  • アプリケーションチーム向けに、簡素化された API を備えたセルフサービスプラットフォームを作成する場合

  • チーム間でインフラストラクチャパターン (データベース + バックアップ + モニタリング) を標準化する場合

  • リソースの依存関係を管理し、リソース間で値を渡す場合

  • 実装の複雑さを隠すカスタム抽象化を構築する場合

  • 複数の 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 アクセス許可の設定」を参照してください。

アプリケーションチームの責任

アプリケーションチームは、基盤となる複雑さを理解することなく、RGDs で定義されたカスタムリソースのインスタンスを作成します。

必要となる権限:

  • カスタムリソースのインスタンスの作成、更新、削除

  • 自身の名前空間への読み取りアクセス

  • 基盤となるリソースまたは RGDs へのアクセス権は不要

利点:

  • チームはシンプルで高レベルの API を使用

  • プラットフォームチームが実装の詳細を制御

  • 設定ミスのリスクを低減

  • 新しいチームメンバーのオンボーディングを高速化

他の EKS 機能との統合

ACK リソースの構成

kro は、ACK と組み合わせることで、インフラストラクチャパターンの作成において特に高い効果を発揮します。

一般的なパターン:

  • ストレージを含むアプリケーション: S3 バケット + SQS キュー + 通知設定

  • データベーススタック: RDS インスタンス + パラメータグループ + セキュリティグループ + Secrets Manager シークレット

  • ネットワーク: VPC + サブネット + ルートテーブル + セキュリティグループ + NAT ゲートウェイ

  • ストレージを含むコンピューティング: EC2 インスタンス + EBS ボリューム + IAM インスタンスプロファイル

kro は、依存関係の順序付けを処理し、リソース間で (ARN や接続文字列などの) 値を渡し、ライフサイクル全体を 1 つのユニットとして管理します。

ACK リソースを作成する例については、「ACK の概念」を参照してください。

GitOps と Argo CD

EKS Capability for Argo CD を使用して、Git リポジトリから RGDs とインスタンスの両方をデプロイします。

リポジトリの整理:

  • プラットフォームリポジトリ: プラットフォームチームが管理する ResourceGraphDefinitions を格納

  • アプリケーションリポジトリ: アプリケーションチームが管理するカスタムリソースのインスタンスを格納

  • 共有リポジトリ: 小規模な組織向けに、RGDs とインスタンスの両方を格納

考慮事項:

  • インスタンスより先に RGDs をデプロイする (Argo CD の同期ウェーブが役立つ)

  • プラットフォームチームとアプリケーションチームに別々の Argo CD プロジェクトを使用する

  • プラットフォームチームが RGD リポジトリへのアクセスを制御する

  • アプリケーションチームには RGD 定義への読み取り専用アクセスを付与する

Argo CD の詳細については、「Argo CD の使用」を参照してください。

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 の使用の詳細については、以下を参照してください。

次のステップ