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

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

# EKS を利用する場合の kro の考慮事項
<a name="kro-considerations"></a>

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

## kro を使用する場合
<a name="_when_to_use_kro"></a>

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

 **次の場合に kro を使用します**。
+ アプリケーションチーム向けに、簡素化された API を備えたセルフサービスプラットフォームを作成する場合
+ チーム間でインフラストラクチャパターン (データベース \$1 バックアップ \$1 モニタリング) を標準化する場合
+ リソースの依存関係を管理し、リソース間で値を渡す場合
+ 実装の複雑さを隠すカスタム抽象化を構築する場合
+ 複数の ACK リソースを高レベルの構成要素に構成する場合
+ 複雑なインフラストラクチャスタックの GitOps ワークフローを有効にする場合

 **次の場合は kro を使用しないでください**。
+ シンプルでスタンドアロンなリソースを管理する場合 (ACK または Kubernetes リソースを直接使用します)
+ 動的なランタイムロジックが必要な場合 (kro は命令型ではなく、宣言型です)
+ リソースに依存関係や共有設定がない場合

kro は、チームが複雑なインフラストラクチャを正しくデプロイしやすくする、意見が組み込まれた再利用可能なパターン (「paved paths」) の作成に優れています。

## RBAC パターン
<a name="_rbac_patterns"></a>

kro を使用すると、ResourceGraphDefinitions を作成するプラットフォームチームと、インスタンスを作成するアプリケーションチームとの間で責務を分離できます。

### プラットフォームチームの責任
<a name="_platform_team_responsibilities"></a>

プラットフォームチームは、カスタム 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)」を参照してください。

### アプリケーションチームの責任
<a name="_application_team_responsibilities"></a>

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

 **必要となる権限**:
+ カスタムリソースのインスタンスの作成、更新、削除
+ 自身の名前空間への読み取りアクセス
+ 基盤となるリソースまたは RGDs へのアクセス権は不要

 **利点**:
+ チームはシンプルで高レベルの API を使用
+ プラットフォームチームが実装の詳細を制御
+ 設定ミスのリスクを低減
+ 新しいチームメンバーのオンボーディングを高速化

## 他の EKS 機能との統合
<a name="_integration_with_other_eks_capabilities"></a>

### ACK リソースの構成
<a name="_composing_ack_resources"></a>

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
<a name="_gitops_with_argo_cd"></a>

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 の整理
<a name="_organizing_resourcegraphdefinitions"></a>

目的、複雑さ、所有権別に RGDs を整理します。

 **目的別**:
+  **インフラストラクチャ**: データベーススタック、ネットワーク、ストレージ
+  **アプリケーション**: ウェブアプリケーション、API、バッチジョブ
+  **プラットフォーム**: 共有サービス、モニタリング、ログ記録

 **複雑さ別**:
+  **シンプル**: 依存関係が最小限の 2～3 個のリソース
+  **中程度**: 一部に依存関係がある 5～10 個のリソース
+  **複雑**: 複雑な依存関係を持つ 10 個以上のリソース

 **命名規則**:
+ わかりやすい名前を使用する: `webapp-with-database`、`s3-notification-queue`
+ 重大な変更には、名前にバージョンを含める: `webapp-v2` 
+ 関連する RGDs には、一貫したプレフィックスを使用する: `platform- `、`app-`

 **名前空間戦略**:
+ RGDs はクラスタースコープである (名前空間なし)
+ インスタンスは名前空間に属する
+ RGDs で名前空間セレクタを使用して、インスタンスを作成できる場所を制御する

## バージョニングと更新
<a name="_versioning_and_updates"></a>

RGD の進化とインスタンスの移行を計画します。

 **RGD の更新**:
+  **重要な変更なし**: RGD をそのまま更新する (オプションフィールドを追加、includeWhen を使用した新しいリソースを追加)
+  **重大な変更**: 異なる名前の新しい RGD を作成する (webapp-v2)
+  **非推奨化**: 古い RGDs に注釈を付け、移行タイムラインを周知する

 **インスタンスの移行**:
+ 更新された RGD を使用して新しいインスタンスを作成する
+ 新しいインスタンスが正しく動作することを検証する
+ 古いインスタンスを削除する
+ kro は、基盤となるリソースの更新を自動的に処理します

 **ベストプラクティス**:
+ 最初に本番稼働用環境以外で RGD の変更をテストする
+ 主な変更には、RGD 名にセマンティックバージョニングを使用する
+ 重大な変更と移行パスを文書化する
+ アプリケーションチームに移行例を提供する

## 検証とテスト
<a name="_validation_and_testing"></a>

本番環境にデプロイする前に RGDs を検証します。

 **検証戦略**:
+  **スキーマ検証**: kro は RGD の構造を自動的に検証する
+  **ドライランインスタンス**: 開発用名前空間でテストインスタンスを作成する
+  **統合テスト**: 構成されたリソースが正しく連携することを確認する
+  **ポリシーの適用**: アドミッションコントローラーを使用して組織標準を適用する

 **テストする一般的な問題**:
+ リソースの依存関係と順序付け
+ リソース間で渡す値 (CEL 式)
+ 条件付きリソースの包含 (includeWhen)
+ 基盤となるリソースからのステータス伝播
+ インスタンス作成の RBAC アクセス許可

## アップストリームドキュメント
<a name="_upstream_documentation"></a>

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) - トラブルシューティングとデバッグ

## 次のステップ
<a name="_next_steps"></a>
+  [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 とインスタンスをデプロイする