翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # GitHub Actions を使用して EKS クラスター間で Amazon EKS Auto Mode を有効にする *Urbija Goswami と Anugrah Lakra、Amazon Web Services* ## 概要 [Amazon Elastic Kubernetes Service (EKS) ](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html)クラスターでは、従来、ノードグループを介したコンピューティングリソースの手動管理が必要です。これにより、以下の運用オーバーヘッドが発生します。 + キャパシティプランニングとスケーリングの決定 + ノードのプロビジョニングとライフサイクル管理 + さまざまなワークロードタイプのコスト最適化 + インフラストラクチャのメンテナンスと更新 Amazon EKS [Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) は、ワークロードの需要に基づいてノードを動的にプロビジョニングおよびスケーリングすることでコンピューティングリソース管理を自動化するため、手動ノードグループ管理が不要になります。 ただし、多くの組織は、既存のクラスターと新しいクラスター全体で Amazon EKS Auto Mode を一貫して有効化および管理することに苦労しています。一般的な課題は次のとおりです。 + 既存のノードグループからの複雑な移行プロセス + 移行中のサービス中断のリスク + 慎重なキャパシティプランニングとテストが必要 + 特定の [Amazon IAM](https://aws.amazon.com/iam/?trk=6a436c72-0178-4620-97ad-0220ccc59fd0&sc_channel=ps&ef_id=CjwKCAjw7vzOBhBxEiwAc7WNr57daOn9724PwXVGy7aBxG_uuEHktjCWJbcY1q1BrZBaApyi1sAb_BoCQj0QAvD_BwE:G:s&s_kwcid=AL!4422!3!795924581177!e!!g!!amazon%20iam!23523526050!193629723318&gad_campaignid=23523526050&gbraid=0AAAAADjHtp_aCwsziIR-n3ST_xwoCqAuc&gclid=CjwKCAjw7vzOBhBxEiwAc7WNr57daOn9724PwXVGy7aBxG_uuEHktjCWJbcY1q1BrZBaApyi1sAb_BoCQj0QAvD_BwE) アクセス許可と設定の要件 + 複数のチームや環境間の調整 このパターンは、特定の AWS リージョンの EKS クラスターで EKS Auto Mode を有効にする [GitHub Actions](https://docs.github.com/en/actions) ワークフローを実装します。自動モードを有効にする前に、ワークフローはクラスター状態 (クラスター設定、ノードグループ、Helm リリース、カスタムリソース) のタイムスタンプ付きバックアップを作成し、[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) バケットにアップロードします。 自動モードを有効にすると、ワークフローは古いノードグループをドレインおよび削除し、クラスターロールのアクセス許可を更新し、Karpenter や Cluster Autoscaler などの以前のスケーリングコンポーネントをクリーンアップします。ワークフローは、既存の継続的インテグレーションおよび継続的デリバリー/デプロイ (CI/CD) パイプラインと統合できます。 ## 前提条件と制限 **前提条件** **1. 必須 ** + ワークフローを実行する[ための GitHub アカウント](https://github.com/)と独自の GitHub リポジトリ + 管理権限を持つアクティブな [AWS アカウント](https://aws.amazon.com/account/) **2。ローカルツールのインストール** + [Terraform](https://developer.hashicorp.com/terraform/install) バージョン 1.13.0 以降 + 適切な認証情報で設定された [GitHub CLI](https://cli.github.com/) (gh) + クラスター管理用に設定された [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) と [eksctl](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html) **3. EKS クラスターの要件** + Kubernetes バージョン 1.29 以降 + エンドポイントアクセス設定: + パブリックエンドポイントとプライベートエンドポイントのいずれかに設定されている場合  + または、プライベートサブネットに NAT Gateway を持つプライベートエンドポイント + [EKS API](https://docs.aws.amazon.com/eks/latest/userguide/grant-k8s-access.html) と [ConfigMap](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html) クラスターアクセスが有効 (EKS が Auto Mode ノードを動的に管理し、移行中に適切なクラスター認証のために aws-auth ConfigMap を更新できるようにするために必要) + アクティブな[ノードグループまたはマネージド型ノードプール](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) **4. IAM OIDC 設定要件** + 以下を含む GitHub の IAM ロールと ID プロバイダー。 + GitHub OIDC の信頼ポリシー + 以下のアクセス許可: + EKS クラスター管理 + S3 バケットアクセス + IAM ロールの管理 + EC2 ネットワーク管理 + Terraform を使用した簡単なセットアップについては、[iam.tf](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/iam.tf) コードを参照してください。Terraform コードが適用されると、IAM ロール (GitHubActionsEKSRole) が作成されます。 **制限事項** + Kubernetes バージョン 1.29 以降の EKS クラスターのみをサポート + Karpenter バージョン 1.1.0 以降のみをサポート + リージョン固有の実装。一部の AWS サービスは、すべての AWS リージョンで利用できるわけではありません。リージョンの可用性については、[「リージョン別の AWS のサービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。 + クラスターエンドポイントのアクセシビリティが必要です + AWS マネージド型ノードグループに限定 ## アーキテクチャ **ターゲットテクノロジースタック** 1. [https://docs.github.com/en/actions](https://docs.github.com/en/actions) 1. [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 1. [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html) 1. [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) **ターゲット アーキテクチャ** ![](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e1fa4e49-96a5-42ae-9886-766298664db4/images/a2c46a84-3bf5-4f1e-8216-ab29b4ba894e.png) 1. GitHub Actions ワークフローは、ユーザーによって GitHub リポジトリからトリガーされます。 1. GitHub Actions ワークフローは、OIDC を使用して IAM ロールを引き受け、AWS アカウントに必要な変更を加えます。また、アカウント内に EKS Auto Node ロールが存在するかどうかもチェックし、存在しない場合はロールが作成され、必要なポリシーがアタッチされます。 1. Auto Mode が有効になっている EKS クラスターの現在の状態のバックアップが S3 バケットにアップロードされます。 1. Auto Mode を有効にする必要があるクラスターのクラスターロールが取得され、EKS Auto Mode に存在しない場合は追加のアクセス許可 (AmazonEKSComputePolicy、AmazonEKSBlockStoragePolicy、AmazonEKSLoadBalancingPolicy、AmazonEKSNetworkingPolicy、AmazonEKSClusterPolicy) が追加されます。さらに、移行前のステップとして、クラスターのサブネットは EKS Auto Mode を有効にするためのタグで更新されます。 1. ワークフローは、EKS クラスターで EKS Auto Mode を有効にします。 1. 古いノードグループは識別され、削除されます。これは、ユーザーが以下のオプションのセットアップステップで説明されている IAM ロールにアクセス許可を付与していない場合はスキップされます。 1. スケーリングコンポーネント (Karpenter と Cluster Autoscaler) も、以前に存在する場合は削除されます。 GitHub Actions ワークフローは、3 つの主要なジョブで構成されます。 1. `check-clusters`: Auto Mode が有効になっていないクラスターを識別し、IAM ポリシーとサブネットタグを更新します。 1. `backup-and-check`: 移行前にクラスターの状態をバックアップします。 1. `gradual-migration` : 既存のノードグループを徐々にドレインし、古いスケーリングコンポーネントをクリーンアップしながら、自動モードを有効にします。また、移行後にクラスターの状態の最終検証も行います。 **注記** ノード設定のバックアップが必要な場合、または EKS Auto Mode への移行中にノード/ノードグループを削除する予定がある場合は、Terraform コードを使用して作成された IAM ロールを aws-auth ConfigMap に追加できます。これがない場合でも、ノードグループ設定を表示できます。  ## ツール *AWS CLI:* [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができる、オープンソースのツールです。このソリューションでは、AWS サービスのコマンドラインインターフェイスを使用して、オートメーションプロセス全体で EKS クラスター設定の更新、IAM ロールの更新、クラスターステータスのクエリを実行します。 *Amazon EKS:* [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、 で Kubernetes を実行する際に役立ちます。独自の Kubernetes コントロールプレーンまたはノードをインストールおよび維持する必要はありません。このパターンでは、Amazon EKS は、Auto Mode を有効にして、特定のリージョンのクラスター間でコンピューティングプロビジョニングとノードスケーリングを自動化できるターゲットサービスです。 *IAM:* 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。当社のソリューションでは、これを使用してGitHub Actions が OIDC フェデレーションを介して EKS クラスター設定を変更するためのアクセス許可を管理します。このソリューションでは、クラスターロールのアクセス許可を変更し、ジョブを追加して EKS ノードロールを作成します。これにより、EKS Auto Mode はノードプールの一部としてスピンアップする新しいノードで保留中のポッドをスケジュールできます。 *Amazon S3***:** [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このソリューションでは、EKS Auto Mode が有効になる前に、S3 バケットを使用してクラスターのタイムスタンプ付きバックアップを保存します。これはディザスタリカバリに役立ちます。 **その他のツール:** *GitHub アクション:* [GitHub Actions](https://docs.github.com/en/actions) は、EKS Auto Mode の有効化ワークフローを自動化するソリューションで使用される CI/CD プラットフォームです。また、OIDC を介した安全な認証を提供し、複数のクラスターでのパイプライン実行を管理します。   *HashiCorp Terraform:* [Terraform](https://developer.hashicorp.com/terraform/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ infrastructure as code (IaC) ツールです。当社のソリューションは terraform を使用して IAM ロールとポリシーをプロビジョニングし、安全な GitHub Actions 統合のための OIDC プロバイダー設定を追加します。  **コードリポジトリ** このパターンのコードは、GitHub [Actions リポジトリを介して GitHub EKS Auto Mode Enablement ](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/tree/main)で使用できます。 ## ベストプラクティス + **のセキュリティ** + 最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、[IAM ドキュメントの「最小特権を付与する」と「セキュリティのベストプラクティス」を参照してください。](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege.)最低限必要な設定については、リポジトリの [iam.tf](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/iam.tf) ファイルを参照してください。  + IAM ロールの信頼ポリシーを特定の GitHub リポジトリとブランチにスコープして、不正なワークフロー実行がロールを引き受けるのを防ぎます。  + 移行を開始する前に EKS コントロールプレーンのログ記録 (API サーバー、監査、認証) を有効にすると、Auto Mode が有効になった後にスケジューリングまたは認証の問題を診断できます。  + [バックアップスクリプト](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/scripts/backup-cluster-state.sh)内のすべての aws s3 cp コマンドに --sse AES256 を追加して、クラスター状態のバックアップにサーバー側の暗号化を適用します。  + **信頼性**: + まず、非本番稼働用クラスターに対してワークフローをテストします。本番稼働用クラスターを移行する前に、ワークロードが Auto Mode ノードで正しく再スケジュールされていることを確認します。  + Auto Mode を有効にする前に、S3 バックアップが正常に完了し、有効なクラスター設定、ノードグループ、Helm リリース、カスタムリソースデータが含まれていることを確認します。  + 自動モードを有効にしたら、[Amazon CloudWatch Container Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)を使用してポッドスケジューリングイベントとノードプロビジョニングのレイテンシーをモニタリングし、問題を早期に検出します。  + **パフォーマンス**: + Auto Mode ノードプールのスケーリングパターンを定期的に確認し、ワークロードリソースのリクエストと制限を調整して、過剰なプロビジョニングやスケジュールの遅延を回避します。 + **料金:** + EKS クラスターおよび関連リソース (IAM ロール、S3 バックアップバケット、サブネット) に環境と所有権のメタデータをタグ付けして、コストの追跡と運用の可視性をサポートします。詳細については、[「AWS リソースドキュメントのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html.)」を参照してください。ワークフローファイルを編集して、移行プロセス中にカスタムタグを追加できます。  + Auto Mode はインスタンスタイプとスケーリング動作を変更する可能性があるため、Auto Mode を有効にした後のコンピューティングコストの変化をモニタリングするように AWS Cost Explorer アラートを設定します。詳細については、[「AWS Cost Explorer ドキュメント](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html.)によるコストの分析」を参照してください。   + **オペレーション**: + ワークフローファイルと Terraform 設定をバージョン管理に保持し、リージョン、ロール ARN、S3 バケット名などの環境固有のオーバーライドを文書化します。    ## エピック ### ツールSetUp | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub リポジトリを設定します。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | AWS DevOps、クラウドアーキテクト | ### (オプション) IAM ロールを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | バックアップとノードグループの削除用に IAM を設定する | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html)
eksctl create iamidentitymapping \ --cluster $CLUSTER_NAME\ --region us-east-1 \ --arn arn:aws:iam::$ACCOUNT_ID:role/GitHubActionsEKSRole \ --group system:masters \ --username github-actions
**$CLUSTER\_NAME** と **$ACCOUNT\_ID** を適切な値に置き換えます。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html)
CLUSTERS=$(aws eks list-clusters --region $AWS_REGION --query 'clusters[]' --output text)

CLUSTERS_NEEDING_AUTO_MODE=""

for cluster in $CLUSTERS; do
    
    
    AUTO_MODE=$(aws eks describe-cluster --name $cluster --region $AWS_REGION --query 'cluster.computeConfig.enabled' --output text 2>/dev/null || echo "false")
    
    if [ "$AUTO_MODE" != "True" ]; then
       
        CLUSTERS_NEEDING_AUTO_MODE="$CLUSTERS_NEEDING_AUTO_MODE $cluster"
        
        echo " Adding role access to cluster..."
        eksctl create iamidentitymapping \
          --cluster $cluster \
          --region $AWS_REGION \
          --arn $ROLE_ARN \
          --group system:masters\
          --username github-actions || echo "  ⚠️  Role mapping may already exist"
        
        echo "  ✅ Role access configured for $cluster"
done

**$AWS\_REGION** と **$ROLE\_ARN** をそれぞれ特定のリージョンと上記で作成した IAM ロールの arn に置き換えます。 | AWS DevOps、クラウドアーキテクト | ### 実行と検証 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | GitHub Actions ワークフローをトリガーします。 | ワークフローは、変更が機能、メイン、または開発ブランチにプッシュされると自動的にトリガーされます。GitHub UI を使用して手動でトリガーするには: 1。GitHub 2 のリポジトリに移動します。「アクション」タブ 3 をクリックします。ワークフロー (auto-mode-pipeline) を選択します 4。「ワークフローの実行」ボタン 5 をクリックします。ブランチを選択し、「ワークフローの実行」をクリックします。
ワークフローは、AWS CLI を使用して移行された各クラスターのコンピューティング設定をクエリすることで、移行後の[検証](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/22b546b05630c63e5637928ad8a4f5947ad8fb33/.github/workflows/enable-eks-auto-mode.yml#L283)を処理し、EKS Auto Mode が正常に有効になっていることを確認し、現在のコンピューティング設定をテーブル形式で表示します。 | AWS DevOps、クラウドアーキテクト | ### マルチ環境デプロイを設定する | タスク | 説明 | 必要なスキル | | --- | --- | --- | | マルチ環境デプロイの実装。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | | ### クリーンアップ | タスク | 説明 | 必要なスキル | | --- | --- | --- | | リソースをクリーンアップします。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | AWS 全般、クラウドアーキテクト | ## トラブルシューティング | 問題 | ソリューション | | --- | --- | | **認証の問題**

| • GitHub OIDC プロバイダーが AWS IAM で正しく設定されていることを確認します
• git シークレットの IAM ロール ARN が terraform (GitHubActionsEKSRole) で作成された実際のロールと一致することを確認します。
• GitHub リポジトリに必要なシークレット AWS\_REGION と AWS\_ROLE\_ARN が設定されていることを確認します。
• クラスターの場所と一致する AWS リージョン設定を検証する | | **アクセス許可の問題**

| • IAM ロールのアクセス許可をローカルでテストする: bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters
• ロールに eks:UpdateClusterConfig および eks:DescribeCluster アクセス許可があることを確認します | | **クラスターの互換性**

| • EKS クラスターが Kubernetes 1.29 以降を実行していることを確認します。bash aws eks describe-cluster --name --query 'cluster.version'
• 自動モードを有効にする前に、クラスターが ACTIVE 状態であることを確認します。 | | **ワークフローの失敗**
| • GitHub Actions ログで特定のエラーメッセージを確認する
• .github/workflows/auto-mode-pipeline.yml でワークフローファイルの構文を検証する
• ワークフローで環境変数が適切に設定されていることを確認します。 | ## 関連リソース 1. [開始するための EKS Auto Mode の公式ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) 1. [クラスター設定 CLI ドキュメントの更新](https://docs.aws.amazon.com/cli/latest/reference/eks/update-cluster-config.html) 1. [GitHub アクションの GitHub シークレット](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) 1. [GitHub Actions ドキュメント](https://docs.github.com/en/actions)  1. [OIDC フェデレーションドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)