EKS を利用する場合の ACK の考慮事項 - Amazon EKS
IAM 設定のパターン他の EKS 機能との統合リソースを整理する他の Infrastructure as Code ツールからの移行削除ポリシーアップストリームドキュメント次のステップ

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

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

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

このトピックでは、IAM 設定、マルチアカウントパターン、他の EKS 機能との統合など、EKS Capability for ACK を使用する際の重要な考慮事項について説明します。

IAM 設定のパターン

ACK 機能は、IAM 機能ロールを使用して AWS で認証します。要件に基づいて適切な IAM パターンを選択します。

シンプル: 単一の機能ロール

開発、テスト、またはシンプルなユースケースの場合、必要なすべてのアクセス許可を機能ロールに直接付与します。

を使用する場合

  • ACK の使用を開始する

  • シングルアカウントでデプロイする

  • 1 つのチームがすべてのリソースを管理する

  • 開発環境とテスト環境

例: リソースのタグ付け条件に従って、S3 と RDS のアクセス許可を機能ロールに追加します。

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": ["rds:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        },
      }
    }
  ]
}

この例では、S3 と RDS のオペレーションを特定のリージョンに制限し、RDS リソースに ManagedBy: ACK タグが必要です。

本番稼働: IAM ロールセレクター

本番稼働環境では、IAM ロールセレクターを使用して、最小特権のアクセスと名前空間レベルでの分離を実装します。

を使用する場合

  • 本番稼働環境

  • マルチチームクラスター

  • マルチアカウントリソース管理

  • 最小特権セキュリティ要件

  • サービスごとに異なるアクセス許可が必要

利点:

  • 名前空間ごとに必要なアクセス許可のみを取得できます。

  • チーム分離 - チーム A は、チーム B のアクセス許可を使用できません。

  • 監査とコンプライアンスが容易です。

  • クロスアカウントリソース管理に必須です。

IAM ロールセレクターの設定の詳細については、「ACK アクセス許可を設定する」を参照してください。

他の EKS 機能との統合

GitOps と Argo CD

EKS Capability for Argo CD を使用すると、Git リポジトリから ACK リソースをデプロイして、インフラストラクチャの管理に GitOps ワークフローを使用できます。

考慮事項:

  • エンドツーエンドの GitOps のアプリケーションマニフェストと共に保存する

  • チーム構造に基づいて環境、サービス、またはリソースタイプ別に整理する

  • Argo CD の自動同期を使用して継続的に調整を行う

  • プルーニングを有効にして削除済みのリソースを自動的に除去する

  • マルチクラスターのインフラストラクチャ管理にハブアンドスポークパターンを検討する

GitOps は、監査証跡、ロールバック機能、および宣言型のインフラストラクチャ管理を備えています。Argo CD の詳細については、「Argo CD の使用」を参照してください。

kro によるリソース構成

EKS Capability for kro (Kube Resource Orchestrator) を使用すると、複数の ACK リソースを高次の抽象化とカスタム API に構成できます。

どのような場合に ACK で kro を使用するか:

  • よく見られるインフラストラクチャスタック用に再利用可能なパターンを作成する場合 (データベース + バックアップ + モニタリング)

  • アプリケーションチーム向けに API をシンプルにしてセルフサービスプラットフォームを構築する場合

  • リソースの依存関係を管理し、リソース間で値を渡す (S3 バケット ARN を Lambda 関数に渡す) 場合

  • チーム間でインフラストラクチャ設定を標準化する場合

  • カスタムリソースの背後に実装の詳細を隠して複雑さを軽減する場合

パターンの例:

  • アプリケーションスタック: S3 バケット + SQS キュー + 通知設定

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

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

kro は、構成済みのリソースに対して依存関係の順序付け、ステータスの伝播、ライフサイクルの管理を行います。kro の詳細については、「kro の概念」を参照してください。

リソースを整理する

Kubernetes 名前空間と AWS リソースタグを使用して ACK リソースを整理すると、管理、アクセスコントロール、コスト追跡を改善できます。

名前空間の整理

Kubernetes 名前空間を使用すると、環境 (本番稼働、ステージング、開発)、チーム (プラットフォーム、データ、ml)、またはアプリケーション別に ACK リソースを論理的に分離できます。

利点:

  • アクセスコントロール用に RBAC を名前空間範囲で限定する

  • 注釈を使用して名前空間ごとにデフォルトリージョンを設定する

  • リソース管理とクリーンアップが容易になる

  • 組織構造に沿って論理的に分離できる

リソースのタグ付け

EKS は、機能リソース ARN など、ACK によって管理される AWS リソースにタグを自動的に適用します。この他にも、コスト配分、所有権追跡、および整理目的でタグを追加できます。

推奨されるタグ:

  • 環境 (本番稼働、ステージング、開発)

  • チームまたは部門の所有権

  • 請求を配分するためのコストセンター

  • アプリケーション名やサービス名

  • 管理元: ACK (ACK マネージドリソースを識別するため)

他の Infrastructure as Code ツールからの移行

多くの組織が、Kubernetes を土台にワークロードのオーケストレーションを超えた標準化を図ることに価値を見い出しています。インフラストラクチャと AWS リソースの管理を ACK に移行することで、アプリケーションワークロードと共に Kubernetes API を使用してインフラストラクチャ管理を標準化できます。

Kubernetes を土台にインフラストラクチャを標準化するメリット:

  • 信頼できる単一のソース: Kubernetes でアプリケーションとインフラストラクチャの両方を管理して、エンドツーエンドの GitOps プラクティスを実現する

  • 統一されたツール: チームは Kubernetes のリソースとツールを使用すればよく、いくつものツールやフレームワークを学習する必要がない

  • 一貫性のある調整: ACK は、Kubernetes がワークロードに対してそうであるように、AWS リソースを継続的に調整し、必須のツールと比較してドリフトを検出して修正する

  • ネイティブコンポジション: kro と ACK を一緒に使用して、アプリケーションとリソースのマニフェストで AWS リソースを直接参照し、リソース間で接続文字列と ARN を渡す

  • シンプルなオペレーション: 1 つのコントロールプレーンでシステム全体のデプロイ、ロールバック、オブザーバビリティを実現する

ACK は、AWS リソースを再作成せずに既存のものを採用するため、CloudFormation、Terraform、またはクラスター外のリソースからダウンタイムなしで移行できます。

既存のリソースを採用する:

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: existing-bucket
  annotations:
    services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
  name: my-existing-bucket-name

採用されたリソースは、ACK によって管理され、Kubernetes マニフェストを介して更新できます。段階的に移行できるため、必要に応じてリソースを採用しながら、他のリソースでは既存の IaC ツールを維持できます。

また、ACK は読み取り専用リソースもサポートしています。他のチームやツールで管理されるリソースを変更するのではなく参照するだけにする場合は、採用と retain 削除ポリシーとを組み合わせて、読み取り IAM アクセス許可のみを付与します。これにより、アプリケーションは変更のリスクを冒すことなく Kubernetes API を介して共有インフラストラクチャ (VPC、IAM ロール、KMS キー) を検出できます。

リソースの採用の詳細については、「ACK の概念」を参照してください。

削除ポリシー

削除ポリシーは、対応する Kubernetes AWS リソースを削除したときにリソースがどうなるかを制御します。リソースのライフサイクルと実際の運用要件に基づいて、適切なポリシーを選択します。

削除する (デフォルト)

Kubernetes リソースを削除すると、AWS リソースも削除されます。そのため、クラスターと AWS との一貫性が維持され、リソースの蓄積を防ぐことができます。

どのような場合に削除を使用するか:

  • 開発環境とテスト環境でクリーンアップが重要な場合

  • エフェメラルリソースがアプリケーションのライフサイクルに結びついている場合 (テストデータベースや一時バケット)

  • リソースがアプリケーションよりも長く存続してはいけない場合 (SQS キューや ElastiCache クラスター)

  • コスト最適化 - 未使用のリソースを自動的にクリーンアップする場合

  • GitOps で管理された環境で、Git からリソースが削除されたらインフラストラクチャも削除される場合

Kubernetes の宣言型モデルに合わせてデフォルトの削除ポリシーを調整します。クラスターの内容は AWS に存在するものと一致します。

Retain

Kubernetes リソースを削除しても、AWS リソースは保持されます。これにより、重要なデータが保護され、リソースは Kubernetes 表現よりも長く存続できます。

どのような場合に保持を使用するか:

  • 本番稼働用データベースにクラスターの変更後も存続する必要がある重要なデータが保存されている場合

  • 長期ストレージバケットにコンプライアンス要件や監査要件がある場合

  • 複数のアプリケーションやチームが共有リソースを使用している場合

  • さまざまな管理ツールにリソースを移行する場合

  • ディザスタリカバリでインフラストラクチャを維持する場合

  • 廃止に慎重を要する複雑な依存関係がリソースにある場合

apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: production-db
  annotations:
    services.k8s.aws/deletion-policy: "retain"
spec:
  dbInstanceIdentifier: prod-db
  # ... configuration
重要

保持したリソースは、引き続き AWS コストが発生するため、不要になったら AWS から手動で削除する必要があります。リソースのタグ付けを使用すると、保持したリソースの中にクリーンアップが必要なものがないかを追跡できます。

削除ポリシーの詳細については、「ACK の概念」を参照してください。

アップストリームドキュメント

ACK の使用の詳細については、以下を参照してください。

次のステップ