Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する

Nadeem Rahaman、Aditya Ambati、Aniket Dekate、Shrikant Patil、Amazon Web Services

概要

製品やサービスを提供する多くの企業は、社内のビジネス機能間のデータバリアを維持するためにデータ規制が必要とされる業界です。このパターンでは、Amazon Elastic Kubernetes Service (Amazon EKS) のマルチテナンシー機能を使用して、単一の Amazon EKS クラスターを共有するテナントまたはユーザー間で論理的および物理的な分離を実現するデータプラットフォームを構築する方法について説明します。このパターンは、以下のアプローチを通じて分離を実現します。

  • Kubernetes 名前空間の分離

  • ロールベースのアクセスコントロール (RBAC)

  • ネットワークポリシー

  • リソースクォータ

  • AWS Identity and Access Management サービスアカウント (IRSA) の (IAM) ロール

また、このソリューションは Flux を使用して、アプリケーションをデプロイするときにテナント設定をイミュータブルに保ちます。設定に Flux kustomization.yaml ファイルを含むテナントリポジトリを指定することにより、テナントアプリケーションをデプロイできます。

このパターンでは、以下を実装します。

  • AWS CodeCommit Terraform スクリプトを手動でデプロイすることで作成されるリポジトリ、 AWS CodeBuild プロジェクト、 AWS CodePipeline パイプライン。

  • テナントをホストするために必要なネットワークコンポーネントとコンピューティングコンポーネント。これらは、Terraform を使用して CodePipeline と CodeBuild を介して作成されます。

  • Helm チャートで設定されるテナント名前空間、ネットワークポリシー、リソースクォータ。

  • Flux を使用してデプロイされた、異なるテナントに属するアプリケーション。

固有の要件とセキュリティ上の考慮事項に基づいて、マルチテナンシー用に独自のアーキテクチャを慎重に計画および構築することをお勧めします。このパターンは、実装の開始点となります。

前提条件と制限事項

前提条件

制限事項

  • Terraform 手動デプロイの依存関係: CodeCommit リポジトリ、CodeBuild プロジェクト、CodePipeline パイプラインの作成を含むワークフローの初期セットアップは、Terraform の手動デプロイに依存します。インフラストラクチャの変更に手動で介入する必要があるため、自動化とスケーラビリティの面で潜在的な制限が生じます。

  • CodeCommit リポジトリの依存関係: ワークフローは、ソースコード管理ソリューションとして CodeCommit リポジトリに依存し、密接に結合されています AWS のサービス。

アーキテクチャ

ターゲットアーキテクチャ

このパターンでは、次の図に示すように、3 つのモジュールをデプロイして、データプラットフォームのパイプライン、ネットワーク、コンピューティングインフラストラクチャを構築します。

パイプラインアーキテクチャ:

Amazon EKS マルチテナントアーキテクチャのパイプラインインフラストラクチャ

ネットワークアーキテクチャ:

Amazon EKS マルチテナントアーキテクチャのネットワークインフラストラクチャ

コンピューティングアーキテクチャ:

Amazon EKS マルチテナントアーキテクチャのコンピューティングインフラストラクチャ

ツール

AWS のサービス

  • AWS CodeBuild は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。

  • AWS CodeCommit は、独自のソースコントロールシステムを管理することなく、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。

  • AWS CodePipeline は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。

  • Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。

  • AWS Transit Gateway は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを接続する中央ハブです。

  • Amazon Virtual Private Cloud (Amazon VPC) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。

その他のツール

  • Cilium ネットワークポリシーは、Kubernetes L3 および L4 ネットワークポリシーをサポートします。L7 ポリシーで拡張して、HTTP、Kafka、gRPC、その他の同様のプロトコルに API レベルのセキュリティを提供できます。

  • Flux は、Git ベースの継続的デリバリー (CD) ツールです。Kubernetes へのアプリケーションのデプロイを自動化します。

  • Helm は、Kubernetes 用のオープンソースのパッケージマネージャです。Kubernetes クラスター上でアプリケーションをインストールおよび管理できます。

  • Terraform」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

コードリポジトリ

このパターンのコードは、GitHub「EKS Multi-Tenancy Terraform Solution」のリポジトリで入手できます。

ベストプラクティス

この実装を使用するためのガイドラインとベストプラクティスについては、以下を参照してください。

エピック

タスク説明必要なスキル

プロジェクトリポジトリのクローンを作成する

ターミナルウィンドウで次のコマンドを実行して、GitHub EKS Multi-Tenancy Terraform Solution のリポジトリをクローンします。

git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
AWS DevOps

Terraform S3 バケットと Amazon DynamoDB をブートストラップします。

  1. bootstrap フォルダで bootstrap.sh ファイルを開き、S3 バケット名、DynamoDB テーブル名、 AWS リージョンの変数値を更新します。

    S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>"
  2. bootstrap.sh スクリプトを実行します。スクリプトには AWS CLI、前提条件の一部としてインストールした が必要です。

    cd bootstrap ./bootstrap.sh
AWS DevOps

run.sh および locals.tf ファイルを更新します。

  1. ブートストラッププロセスが正常に完了したら、bootstrap.sh スクリプトの variables セクションから S3 バケットと DynamoDB テーブル名をコピーします。

    # Variables S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME"
  2. これらの値をプロジェクトのルートディレクトリにある run.sh スクリプトに貼り付けます。

    BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>"
  3. プロジェクトコードを CodeCommit リポジトリにアップロードします。demo/pipeline/locals.tf ファイルの次の変数を true に設定することにより、Terraform からこのリポジトリを自動的に作成できます。

    create_new_repo = true
  4. 要件に従って locals.tf ファイルを更新し、パイプラインリソースを作成します。

AWS DevOps

パイプラインモジュールをデプロイします。

パイプラインリソースを作成するには、次の Terraform コマンドを手動で実行します。これらのコマンドを自動的に実行するためのオーケストレーションはありません。

./run.sh -m pipeline -e demo -r <AWS_REGION> -t init ./run.sh -m pipeline -e demo -r <AWS_REGION> -t plan ./run.sh -m pipeline -e demo -r <AWS_REGION> -t apply
AWS DevOps
タスク説明必要なスキル

パイプラインを開始します。

  1. templates フォルダで、buildspec ファイルの次の変数が network に設定されていることを確認します。

    TF_MODULE_TO_BUILD: "network"
  2. CodePipeline コンソールのパイプラインの詳細ページで、[変更のリリース] を選択してパイプラインを開始します。

初めて実行した後は、CodeCommit リポジトリのメインブランチに変更をコミットするたびに、パイプラインが自動的に開始されます。

パイプラインには次のステージが含まれます。

  • validate は Terraform を初期化し、checkov ツールと tfsec ツールを使用して Terraform セキュリティスキャンを実行し、スキャンレポートを S3 バケットにアップロードします。

  • plan は Terraform プランを表示し、そのプランを S3 バケットにアップロードします。

  • apply は S3 バケットから Terraform プラン出力を適用し、 AWS リソースを作成します。

  • destroy は、applyステージ中に作成された AWS リソースを削除します。このオプションのステージを有効にするには、demo/pipeline/locals.tf ファイルで次の変数を true に設定します。

    enable_destroy_stage = true
AWS DevOps

ネットワークモジュールを通じて作成されたリソースを検証します。

パイプラインが正常にデプロイされた後に、次の AWS リソースが作成されていることを確認します。

  • 3 つのパブリックサブネットと 3 つのプライベートサブネット、インターネットゲートウェイ、NAT ゲートウェイを備えた Egress VPC。

  • 3 つのプライベートサブネットを持つ Amazon EKS VPC。

  • それぞれ 3 つのプライベートサブネットを持つテナント 1 とテナント 2 VPC。

  • すべての VPC アタッチメントと各プライベートサブネットへのルートを持つトランジットゲートウェイ。

  • 送信先 CIDR ブロックが 0.0.0.0/0 の Amazon EKS Egress VPC の静的トランジットゲートウェイルート。これは、すべての VPC が Amazon EKS Egress VPC を介してアウトバウンドインターネットアクセスできるようにするために必要です。

AWS DevOps
タスク説明必要なスキル

locals.tf を更新して、CodeBuild プロジェクトの VPC へのアクセスを有効にします。

Amazon EKS プライベートクラスターのアドオンをデプロイするには、CodeBuild プロジェクトを Amazon EKS VPC にアタッチする必要があります。

  1. demo/pipeline フォルダで locals.tf ファイルを開き、vpc_enabled 変数を true に設定します。

  2. run.sh スクリプトを実行して、パイプラインモジュールに変更を適用します。

    demo/pipeline/locals.tf ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd init ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd plan ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd apply
AWS DevOps

buildspec ファイルを更新してコンピューティングモジュールを構築します。

templates フォルダのすべての buildspec YAML ファイルで、TF_MODULE_TO_BUILD 変数の値を network から compute に設定します。

TF_MODULE_TO_BUILD: "compute"
AWS DevOps

テナント管理 Helm チャートの values ファイルを更新します。

  1. 次の場所で values.yaml ファイルを開きます。

    cd cfg-terraform/demo/compute/cfg-tenant-mgmt

    ファイルは次のようになります。

    --- global: clusterRoles: operator: platform-tenant flux: flux-tenant-applier flux: tenantCloneBaseUrl: ${TEANT_BASE_URL} repoSecret: ${TENANT_REPO_SECRET} tenants: tenant-1: quotas: limits: cpu: 1 memory: 1Gi flux: path: overlays/tenant-1 tenant-2: quotas: limits: cpu: 1 memory: 2Gi flux: path: overlays/tenant-2
  2. global および tenants セクションで、要件に基づいて設定を更新します。

    • tenantCloneBaseUrl – すべてのテナントのコードをホストするリポジトリへのパス (すべてのテナントに同じ Git リポジトリを使用します)

    • repoSecret – グローバルテナント Git リポジトリに対して認証するための SSH キーと既知のホストを保持する Kubernetes シークレット

    • quotas – テナントごとに適用する Kubernetes リソースクォータ

    • flux path – グローバルテナントリポジトリ内のテナントアプリケーション YAML ファイルへのパス

AWS DevOps

コンピューティングリソースを検証します。

前のステップでファイルを更新すると、CodePipeline が自動的に起動します。コンピューティングインフラストラクチャ用に次の AWS リソースが作成されていることを確認します。

  • プライベートエンドポイントを持つ Amazon EKS クラスター

  • Amazon EKS ワーカーノード

  • Amazon EKS アドオン: 外部シークレット、aws-loadbalancer-controllermetrics-server

  • GitOps モジュール、Flux Helm チャート、Cilium Helm チャート、テナント管理 Helm チャート

AWS DevOps
タスク説明必要なスキル

Kubernetes のテナント管理リソースを検証します。

次のコマンドを実行し、Helm を使用してテナント管理リソースが正常に作成されたことを確認します。

  1. values.yaml で指定されているとおり、テナント名前空間が作成されました。

    kubectl get ns -A
  2. クォータは、values.yaml で指定されているとおり、各テナント名前空間に割り当てられます。

    kubectl get quota --namespace=<tenant_namespace>
  3. 各テナント名前空間のクォータの詳細は正確です。

    kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace>
  4. Cilium ネットワークポリシーが各テナント名前空間に適用されました。

    kubectl get CiliumNetworkPolicy -A
AWS DevOps

テナントアプリケーションのデプロイを確認します。

次のコマンドを実行して、テナントアプリケーションがデプロイされたことを確認します。

  1. Flux は、GitOps モジュールで指定された CodeCommit リポジトリに接続できます。

    kubectl get gitrepositories -A
  2. Flux kustomization Controller は、CodeCommit リポジトリに YAML ファイルをデプロイしました。

    kubectl get kustomizations -A
  3. すべてのアプリケーションリソースはテナント名前空間にデプロイされます。

    kubectl get all -n <tenant_namespace>
  4. イングレスはテナントごとに作成されています。

    kubectl get ingress -n <tenant_namespace>

トラブルシューティング

問題ソリューション

次のようなエラーメッセージが表示されます。

Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.

問題のトラブルシューティングを行うには、以下の手順を実行します。

  1. テナントアプリケーションリポジトリを確認する: リポジトリが空であるか、設定が間違っていると、エラーが発生する可能性があります。テナントアプリケーションリポジトリに必要なコードが含まれていることを確認してください。

  2. tenant_mgmt モジュールを再デプロイする: tenant_mgmt モジュール設定ファイルで、app ブロックを見つけ、deploy パラメータを 0 に設定します。

    deploy = 0

    Terraform apply コマンドを実行したら、deploy パラメータ値を 1 に戻します。

    deploy = 1
  3. ステータスを再確認する: 前のステップを実行した後、次のコマンドを使用して問題が解決したかどうかを確認します。

     kubectl get gitrepositories -A

    問題が解決しない場合は、Flux ログの詳細を確認するか、Flux の一般的なトラブルシューティングガイドを参照してください。

関連リソース

追加情報

テナントアプリケーションをデプロイするためのリポジトリ構造の例を次に示します。

applications sample_tenant_app ├── README.md ├── base │ ├── configmap.yaml │ ├── deployment.yaml │ ├── ingress.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── tenant-1 │ ├── configmap.yaml │ ├── deployment.yaml │ └── kustomization.yaml └── tenant-2 ├── configmap.yaml └── kustomization.yaml