**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する
**ヒント**
今後開催予定の Amazon EKS Auto Mode ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
EKS Auto Mode は、Kubernetes クラスターの AWS 管理をクラスター自体を超えて拡張し、ワークロードのスムーズな運用を可能にするインフラストラクチャのセットアップおよび管理も AWS でできるようにします。インフラストラクチャに関する重要な意思決定を委任し、AWS の専門知識を日常業務に活用できます。AWS によって管理されるクラスターインフラストラクチャには、コンピューティングの自動スケーリング、ポッドとサービスのネットワーキング、アプリケーションのロードバランシング、クラスター DNS、ブロックストレージ、GPU サポートなど、アドオンとは対照的に、コアコンポーネントとして多くの Kubernetes 機能が備わっています。
開始するには、新しい EKS Auto Mode クラスターをデプロイするか、既存のクラスターで EKS Auto Mode を有効にすることができます。eksctl、AWS CLI、AWS マネジメントコンソール、EKS API、または任意の Infrastructure as Code ツールを使用して、EKS Auto Mode クラスターをデプロイ、アップグレード、または変更できます。
EKS Auto Mode を使用すると、任意の Kubernetes 互換ツールを引き続き使用できます。EKS Auto Mode は、Amazon EC2、Amazon EBS、ELB などの AWS サービスと統合され、ベストプラクティスに従う AWS クラウドリソースを活用します。これらのリソースは自動的にスケールされ、コストが最適化され、定期的に更新されるため、運用コストおよびオーバーヘッドを最小限に抑えることができます。
## 機能
EKS Auto Mode には次の高度な機能があります。
**Kubernetes クラスター管理の合理化**: EKS Auto Mode は、運用オーバーヘッドを最小限に抑えながら本番環境に対応したクラスターを提供することで、EKS 管理を合理化します。EKS Auto Mode を使用すると、EKS の深い専門知識を必要とせずに、要求の厳しい動的なワークロードを自信を持って実行できます。
**アプリケーションの可用性**: EKS Auto Mode は、Kubernetes アプリケーションの需要に基づいて EKS クラスター内のノードを動的に追加または削除します。この結果、手動キャパシティープランニングの必要性が最小限に抑えられ、アプリケーションの可用性が確保されます。
**効率**: EKS Auto Mode は、NodePool とワークロードの要件で定義された柔軟性を維持しながら、計算コストを最適化するように設計されています。また、未使用のインスタンスを終了し、ワークロードを他のノードに統合して、コスト効率を向上させます。
**セキュリティ**: EKS オートモードは、ノードに対してイミュータブルとして扱われる AMI を使用します。これらの AMI は、ロックダウンされたソフトウェアを適用し、SELinux の必須アクセスコントロールを有効にして、読み取り専用のルートファイルシステムを提供します。さらに、EKS Auto Mode によって起動されたノードの最大存続期間は 21 日 (これは短縮可能) で、その後は自動的に新しいノードに置き換えられます。このアプローチは、多くのお客様が既に採用しているベストプラクティスに沿って、ノードを定期的にサイクルすることで、セキュリティ体制を強化します。
**自動アップグレード**: EKS Auto Mode は、設定されたポッド中断の予算 (PDB) や NodePool 中断の予算 (NDB) を維持しながら、Kubernetes クラスター、ノード、関連コンポーネントを最新のパッチにより最新版に保ちます。PDB やその他の設定をブロックすることで更新が妨げられる場合、最大 21 日間の最大存続期間まで介入が必要になる場合があります。
**マネージドコンポーネント**: EKS Auto Mode には、Kubernetes と AWS クラウドの機能がコアコンポーネントとして備わっていますが、それ以外の場合は、アドオンとして管理が必要になります。これには、ポッド IP アドレスの割り当て、ポッドネットワークポリシー、ローカル DNS サービス、GPU プラグイン、ヘルスチェッカー、EBS CSI ストレージのサポートが組み込まれています。
**カスタマイズ可能な NodePools と NodeClasses**: ワークロードでストレージ、コンピューティング、またはネットワーキングの設定を変更する必要がある場合は、EKS Auto Mode を使用してカスタム NodePools と NodeClasses を作成できます。ユーザーはデフォルトの NodePools と NodeClasses は編集できませんが、デフォルトの設定で新しいカスタムの NodePools または NodeClasses を追加して、特定の要件を満たすことができます。
## 自動コンポーネント
EKS Auto Mode は、主要なインフラストラクチャコンポーネントを自動化することで、Amazon EKS クラスターのオペレーションを合理化します。EKS Auto Mode を有効にすると、EKS クラスターを管理するタスクがさらに減ります。
以下は、自動化されているデータプレーンコンポーネントのリストです。
+ **コンピューティング**: 多くのワークロードでは、EKS Auto Mode を使用すると、EKS クラスターのコンピューティングの多くの側面を気にする必要がなくなります。具体的には次のとおりです。
+ **ノード**: EKS Auto Mode ノードは、アプライアンスのように扱われるように設計されています。EKS Auto Mode は以下を実行します。
+ ワークロードを介入なしで実行するのに必要な多くのサービスを備えて設定された適切な AMI を選択します。
+ SELinux 強制モードと読み取り専用のルートファイルシステムを使用して、AMI 上のファイルへのアクセスをロックダウンします。
+ SSH または SSM アクセスを禁止することで、ノードへの直接アクセスを防止します。
+ GPU サポートがあり、NVIDIA GPU および Neuron GPU 用のカーネルドライバーとプラグインが分離されているため、高性能ワークロードが実現されます。
+ [EC2 スポットインスタンスの中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)および EC2 インスタンスのヘルスイベントを自動的に処理します
+ **自動スケーリング**: EKS Auto Mode は [Karpenter](https://karpenter.sh/docs/) 自動スケーリングに依存して、スケジュール不可能なポッドをモニタリングし、新しいノードをデプロイしてそのポッドを実行できるようにします。ワークロードが終了すると、不要になったノードは EKS Auto Mode によって動的に中断および終了され、リソースの使用状況が最適化されます。
+ **アップグレード**: ノードを制御することで、EKS Auto Mode が必要に応じてセキュリティパッチやオペレーティングシステム、コンポーネントのアップグレードを提供する機能が効率化されます。これらのアップグレードは、ワークロードの中断を最小限に抑えるように設計されています。EKS Auto Mode は、ソフトウェアと API を最新にするために、ノードの最大存続期間を強制的に 21 日に設定します。
+ **ロードバランシング**: EKS Auto Mode は、Amazon の Elastic Load Balancing サービスと統合することでロードバランシングを合理化し、Kubernetes サービスおよびイングレスリソースに対するロードバランサーのプロビジョニングと設定を自動化します。また、Application Load Balancer と Network Load Balancer の両方の高度な機能をサポートし、それらのライフサイクルを管理し、それらをクラスターの需要に合わせてスケールします。この統合により、AWS ベストプラクティスに準拠した本番環境対応のロードバランシングソリューションが提供されるため、インフラストラクチャ管理ではなくアプリケーションに集中できます。
+ **ストレージ**: EKS Auto Mode は、ノード終了時にボリュームタイプ、ボリュームサイズ、暗号化ポリシー、削除ポリシーを設定することで、エフェメラルストレージを設定します。
+ **ネットワーキング**: EKS Auto Mode は、ポッドとサービスの接続に関する重要なネットワーキングタスクを自動化します。これには、IPv4/IPv6 サポートと、IP アドレススペースを拡張するためのセカンダリ CIDR ブロックの使用が含まれます。
+ **Identity and Access Management**: EKS Auto Mode クラスターに EKS Pod Identity Agent をインストールする必要はありません。
これらのコンポーネントの詳細については、「[EKS Auto Mode の仕組みの説明](auto-reference.md)」を参照してください。
## 設定
EKS Auto Mode は、ユーザーの介入なしにほとんどのデータプレーンサービスを効果的に管理しますが、これらのサービスの一部の動作を変更したい場合もあるでしょう。EKS Auto Mode クラスターの設定は、次の方法で変更できます。
+ **Kubernetes DaemonSets**: ノードにインストールされているサービスを変更する代わりに、Kubernetes DaemonSets を使用できます。DaemonSets は Kubernetes によって管理されるように設計されていますが、クラスター内のすべてのノードで実行されます。このようにして、ノードをモニタリングしたりその他の方法で監視したりするための特別なサービスを追加できます。
+ **カスタムの NodePools および NodeClasses**: デフォルトの NodePools と NodeClasses は EKS Auto Mode によって設定されており、ユーザーはこれを編集できません。ノードの動作をカスタマイズするには、次のようなユースケース用に追加の NodePools または NodeClasses を作成できます。
+ 特定のインスタンスタイプ (高速プロセッサや EC2 スポットインスタンスなど) の選択。
+ セキュリティまたはコスト追跡の目的でのワークロード分離。
+ IOPS、サイズ、スループットなどのエフェメラルストレージの設定。
+ **ロードバランシング**: EKS Auto Mode が Kubernetes オブジェクトとして実行するロードバランシングなどの一部のサービスは、EKS Auto Mode クラスターで直接設定できます。
EKS Auto Mode を設定するためのオプションの詳細については、「[EKS 自動モード設定を構成する](settings-auto.md)」を参照してください。
## 責任共有モデル
AWS 責任共有モデルは、AWS とお客様の間のセキュリティとコンプライアンスの責任を定義します。以下の画像とテキストは、EKS オートモードと EKS 標準モードの間でお客様と AWS の責任がどのように異なるかを比較および対照しています。
![\[EKS オートモードと EKS 標準モードによる責任共有モデル\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/eksautosrm.png)
EKS オートモードは、Kubernetes インフラストラクチャの共有責任の大部分をお客様から AWS に移行します。EKS オートモードでは、AWS がクラウドセキュリティに対してより多くの責任を負います。これは、以前はお客様の責任であり、現在は共有されています。お客様はアプリケーションに集中できるようになり、基盤となるインフラストラクチャを AWS が管理します。
**顧客の責任**
EKS オートモードでは、お客様は可用性、セキュリティ、モニタリングなど、アプリケーションコンテナに対する責任を引き続き維持します。また、VPC インフラストラクチャと EKS クラスター設定の制御も維持します。このモデルにより、お客様はクラスターインフラストラクチャ管理を AWS に委任し、アプリケーション固有の懸念事項に集中できます。オプションのノードごとの機能は、AWS アドオンを介してクラスターに含めることができます。
**AWS の責任**
EKS オートモードでは、AWS は、オートモードを使用しない EKS クラスターで既に管理されているものと比較して、いくつかの追加の重要なコンポーネントの管理を含む責任を拡張します。特に、EKS オートモードは、起動された EC2 インスタンスの設定、管理、セキュリティ、スケーリングに加えて、ロードバランシング、IP アドレス管理、ネットワークポリシー、ブロックストレージのクラスター機能も引き受けます。次のコンポーネントは、AWS によって EKS オートモードで管理されます。
+ **オートモード起動 EC2 インスタンス**: AWS は、Amazon EC2 マネージドインスタンスを活用してノードの完全なライフサイクルを処理します。EC2 マネージドインスタンスは、オペレーティングシステムの設定、パッチ適用、モニタリング、ヘルスメンテナンスを担当します。このモデルでは、インスタンス自体とそこで実行されているゲストオペレーティングシステムの両方の責任を AWS が担います。ノードは、コンテナを実行するように最適化された [Bottlerocket](https://aws.amazon.com/bottlerocket) AMI のバリアントを使用します。Bottlerocket AMI には、ロックダウンされたソフトウェア、イミュータブルなルートファイルシステム、安全なネットワークアクセス (SSH または SSM を介した直接通信を防ぐため) があります。
+ **クラスター機能**: AWS は、コンピューティングの自動スケーリング、ネットワークポリシーの適用による Pod ネットワーキング、Elastic Load Balancing の統合、ストレージドライバーの設定を管理します。
+ **クラスターコントロールプレーン**: AWS は、標準の EKS と同様に、Kubernetes API サーバー、クロスアカウント ENI、および etcd データベースを引き続き管理します。
+ **Foundation Services とグローバルインフラストラクチャ**: AWS は、基盤となるコンピューティング、ストレージ、ネットワーキング、およびモニタリングサービス、ならびにリージョン、ローカルゾーン、エッジロケーションのグローバルインフラストラクチャに対する責任を維持します。
# Amazon EKS 自動モードl クラスターを作成する
この章ではさまざまなツールとインターフェイスを使用して、自動モードl を有効にした Amazon EKS クラスターを作成する方法について説明します。自動モードl はクラスターのコンピューティング、ネットワーク、およびストレージインフラストラクチャを自動的に設定および管理することで、クラスターの作成を簡素化します。AWS CLI、AWS マネジメントコンソール、または eksctl コマンドラインツールを使用して、Auto Mode クラスターを作成する方法について説明します。
**注記**
EKS 自動モード にはKubernetes バージョン 1.29 以降が必要です。
ニーズに応じて任意のツールを選択する: AWS マネジメントコンソールには、EKS Auto Mode の機能について学習し、個々のクラスターを作成するのに最適なビジュアルインターフェイスが用意されています。AWS CLI は特にクラスター作成を既存のワークフローまたは CI/CD パイプラインに統合する場合、スクリプト作成および自動化タスクに最適です。eksctl CLI は Kubernetes ネイティブのエクスペリエンスを提供し、実用的なデフォルトにより簡素化されたコマンドラインオペレーションを求める、Kubernetes ツールに精通しているユーザーにお勧めです。
開始する前に、EKS クラスターを作成するための適切な IAM アクセス許可など、必要な前提条件がインストールおよび設定されている状態にします。`kubectl`、`aws`、`eksctl` などの CLI ツールをインストールする方法については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
AWS CLI、AWS マネジメントコンソール、または eksctl CLI を使用して、Amazon EKS Auto Mode でクラスターを作成できます。
**Topics**
+ [eksctl CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-eksctl.md)
+ [AWS CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-cli.md)
+ [AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する](automode-get-started-console.md)
# eksctl CLI を使用して EKS Auto Mode クラスターを作成する
このトピックでは、eksctl コマンドラインインターフェイス (CLI) を使用して Amazon EKS Auto Mode クラスターを作成する方法について説明します。Auto Mode クラスターは、単一の CLI コマンドを実行するか、YAML 設定ファイルを適用することで作成できます。どちらの方法でも同じ機能が得られ、YAML アプローチでクラスター設定をより細かく制御できます。
eksctl CLI は、基盤となる AWS リソースの作成と設定を処理することで、EKS Auto Mode クラスターの作成と管理のプロセスを簡素化します。先に進む前に、必要な AWS 認証情報とアクセス許可をローカルマシンに設定してください。このガイドでは、Amazon EKS の基本的な概念に精通しており、必要な CLI ツールが既にインストールされていることを前提としています。
**注記**
eksctl のバージョン `0.195.0` 以降をインストールする必要があります。詳細については、GitHub の「[eksctl releases](https://github.com/eksctl-io/eksctl/releases)」を参照してください。
## CLI コマンドを使用して EKS Auto Mode クラスターを作成する
`aws` および `eksctl` ツールがインストールされている必要があります。EC2 インスタンス、EC2 ネットワーキング、EKS クラスター、IAM ロールなどの AWS リソースを管理するには、十分なアクセス許可が付与された状態で AWS CLI にログインする必要があります。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
次のコマンドを実行して、新しい EKS Auto Mode クラスターを作成します
```
eksctl create cluster --name= --enable-auto-mode
```
## YAML ファイルを使用して EKS Auto Mode クラスターを作成する
`aws` および `eksctl` ツールがインストールされている必要があります。EC2 インスタンス、EC2 ネットワーキング、EKS クラスター、IAM ロールなどの AWS リソースを管理するには、十分なアクセス許可が付与された状態で AWS CLI にログインする必要があります。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
以下のサンプル ClusterConfig リソースの EKS Auto Mode 設定オプションを確認してください。ClusterConfig の完全な仕様については、「[eksctl ドキュメント](https://eksctl.io/usage/creating-and-managing-clusters/)」を参照してください。
AWS では、EKS Auto Mode を有効にすることをお勧めします。EKS Auto Mode クラスターを初めて作成する場合は、`nodeRoleARN` を指定せずに EKS Auto Mode のノード IAM ロールを作成します。AWS アカウントにノード IAM ロールが既にある場合は、AWS ではそのロールの再利用をお勧めします。
AWS では、`nodePools` には値を指定しないことをお勧めします。EKS Auto Mode では、デフォルトのノードプールが作成されます。Kubernetes API を使用して、追加のノードプールを作成できます。
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
`ClusterConfig` ファイルを `cluster.yaml` として保存し、次のコマンドを使用してクラスターを作成します。
```
eksctl create cluster -f cluster.yaml
```
# AWS CLI を使用して EKS Auto Mode クラスターを作成する
EKS Auto Mode クラスターは、コンピューティング、ストレージ、ネットワーキングのルーティン化されたクラスター管理タスクを自動化します。例えば、EKS Auto Mode クラスターは、追加のノードが必要なタイミングを自動的に検出し、ワークロードの需要に合わせて新しい EC2 インスタンスをプロビジョニングします。
このトピックでは、AWS CLI を使用して新しい EKS Auto Mode クラスターを作成し、必要に応じてサンプルワークロードをデプロイする方法について説明します。
## 前提条件
+ AWS コマンドラインインターフェイス (AWS CLI) の最新バージョンがデバイスにインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version`」を参照してください。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)」を参照してください。
+ 十分な IAM アクセス許可を使用して CLI にログインし、IAM ポリシー、IAM ロール、EKS クラスターなどの AWS リソースを作成します。
+ kubectl コマンドラインツールがデバイスにインストールされている。AWS では、EKS クラスターの Kubernetes バージョンと同じ kubectl バージョンを使用することをお勧めします。kubectl をインストールまたはアップグレードするには、「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
## VPC サブネットを指定する
Amazon EKS Auto Mode は、VPC サブネットにノードをデプロイします。EKS クラスターの作成時に、ノードをデプロイする VPC サブネットを指定する必要があります。AWS アカウントでデフォルトの VPC サブネットを使用するか、重要なワークロード専用の VPC を作成することができます。
+ AWS では、クラスター専用の VPC を作成することをお勧めします。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」ではその方法を説明しています。
+ EKS コンソールは、新しい VPC の作成に役立ちます。「[AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する](automode-get-started-console.md)」ではその方法を説明しています。
+ また、AWS アカウントのデフォルト VPC を使用することができます。サブネット ID を検出するには、以下の手順を使用します。
### デフォルト VPC のサブネット ID を検出するには
**AWS CLI の使用:**
1. 次のコマンドを実行して、デフォルト VPC とそのサブネットを一覧表示します。
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. 出力を保存し、**サブネット ID** をメモします。
サンプル出力:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## EKS Auto Mode クラスターの IAM ロール
### クラスター IAM ロール
EKS Auto Mode では、新しい EC2 インスタンスのプロビジョニングなど、AWS アカウントでアクションを実行するのにクラスター IAM ロールが必要です。必要なアクセス許可を EKS に付与するには、このロールを作成する必要があります。AWS では、クラスター IAM ロールに次の AWS マネージドポリシーをアタッチすることをお勧めします。
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSブロックストレージポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSロードバランシングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [Amazon EKSネットワーキングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### ノード IAM ロール
EKS Auto Mode クラスターを作成する際に、ノード IAM ロールを指定します。EKS Auto Mode が保留中のワークロードを処理するノードを作成すると、新しい EC2 インスタンスノードごとにノード IAM ロールが割り当てられます。このロールにより、ノードは EKS と通信できますが、通常、ノードで実行されているワークロードからはアクセスされません。
ノードで実行されているワークロードにアクセス許可を付与する場合は、EKS Pod Identity を使用します。詳細については、「[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)」を参照してください。
このロールを作成し、次の AWS マネージドポリシーをアタッチする必要があります。
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
EKS Auto Mode には、AWS によって自動的に作成および設定されるサービスリンクロールも必要です。詳細については、「[AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md)」 に関するページを参照してください。
## EKS Auto Mode クラスター IAM ロールを作成する
### ステップ 1: 信頼ポリシーを作成する
Amazon EKS サービスがロールを引き受けることを許可する信頼ポリシーを作成します。ポリシーを `trust-policy.json` として保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### ステップ 2: IAM ロールを作成する
信頼ポリシーを使用して、クラスター IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### ステップ 3: ロール ARN をメモする
以降のステップで使用する新しいロールの ARN を取得して保存します。
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### ステップ 4: 必要なポリシーをアタッチする
次の AWS マネージドポリシーをクラスター IAM ロールにアタッチして、必要なアクセス許可を付与します。
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSコンピュートポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSブロックストレージポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSロードバランシングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
## EKS Auto Mode ノード IAM ロールを作成する
### ステップ 1: 信頼ポリシーを作成する
Amazon EKS サービスがロールを引き受けることを許可する信頼ポリシーを作成します。ポリシーを `node-trust-policy.json` として保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### ステップ 2: ノード IAM ロールを作成する
前のステップの **node-trust-policy.json** ファイルを使用して、ロールを引き受けることができるエンティティを定義します。次のコマンドを実行してノード IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### ステップ 3: ロール ARN をメモする
ロールを作成したら、ノード IAM ロールの ARN を取得して保存します。以降のステップでこの ARN が必要になります。次のコマンドを使用して ARN を取得します。
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### ステップ 4: 必要なポリシーをアタッチする
次の AWS マネージドポリシーをノード IAM ロールにアタッチして、必要なアクセス許可を付与します。
**AmazonEKSWorkerNodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## EKS Auto Mode クラスターを作成する
### 概要:
AWS CLI を使用して EKS Auto Mode クラスターを作成するには、次のパラメータが必要になります。
+ `cluster-name`: クラスターの名前。
+ `k8s-version`: Kubernetes バージョン (1.31 など)。
+ `subnet-ids`: 前のステップで特定したサブネット ID。
+ `cluster-role-arn`: クラスター IAM ロールの ARN。
+ `node-role-arn`: ノード IAM ロールの ARN。
#### デフォルトのクラスター設定
クラスターを作成する前に、以下のデフォルト値および機能を確認してください。
+ `nodePools`: EKS Auto Mode には、汎用ノードプールとシステムデフォルトノードプールが含まれています。「[ノードプール](create-node-pool.md)」の詳細を確認してください。
**注:** EKS Auto Mode のノードプールは Amazon EKS マネージドノードグループとは異なりますが、同じクラスター内で共存できます。
+ `computeConfig.enabled`: EC2 インスタンスの作成や削除などのルーティン化されたコンピューティングタスクを自動化します。
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: Elastic Load Balancer の作成や削除などのロードバランシングタスクを自動化します。
+ `storageConfig.blockStorage.enabled`: Amazon EBS ボリュームの作成や削除などのストレージタスクを自動化します。
+ `accessConfig.authenticationMode`: EKS アクセスエントリを要求します。[EKS 認証モード](grant-k8s-access.md)の詳細を確認してください。
#### コマンドを実行する
次のコマンドを使用してクラスターを作成します。
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### クラスターのステータスを確認する
#### ステップ 1: クラスターの作成を確認する
次のコマンドを実行して、クラスターのステータスを確認します。通常、クラスターの作成には約 15 分かかります。
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### ステップ 2: kubeconfig を更新する
クラスターの準備ができたら、ローカルの kubeconfig ファイルを更新して、`kubectl` がクラスターと通信できるようにします。この設定では、認証に AWS CLI を使用します。
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### ステップ 3: ノードプールを検証する
次のコマンドを使用して、クラスター内のノードプールを一覧表示します。
```
kubectl get nodepools
```
## 次のステップ
+ 新しい EKS Auto Mode クラスターに[サンプルワークロードをデプロイ](automode-workload.md)する方法について説明します。
# AWS マネジメントコンソール を使用して EKS Auto Mode クラスターを作成する
AWS マネジメントコンソールで EKS Auto Mode クラスターを作成すると、他のオプションよりも必要な設定が少なくなります。EKS は AWS IAM および VPC ネットワーキングと統合されて、EKS クラスターに関連付けられたリソースの作成に役立ちます。
コンソールでクラスターを作成するオプションは 2 つあります。
+ クイック設定 (EKS Auto Mode を使用)
+ カスタム設定
このトピックでは、クイック設定オプションを使用して EKS Auto Mode クラスターを作成する方法について説明します。
## クイック設定オプションを使用して EKS Auto Mode を作成する
EC2 インスタンス、EC2 ネットワーキング、EKS クラスター、IAM ロールなどの AWS リソースを管理するには、十分なアクセス許可が付与された状態で AWS マネジメントコンソールにログインする必要があります。
1. EKS コンソールに移動します
1. **[クラスターを作成]** をクリックします
1. **[クイック設定]** オプションが選択されていることを確認します
1. 次の値を決定するか、テストクラスター用のデフォルトを使用します。
+ クラスター**名**
+ Kubernetes バージョン
1. クラスター IAM ロールを選択します。EKS Auto Mode クラスターを初めて作成する場合は、**[推奨ロールを作成]** オプションを使用します。
+ 必要に応じて、すべての EKS Auto Mode クラスターに対して、AWS アカウントで 1 つのクラスター IAM ロールを再利用できます。
+ クラスター IAM ロールには、EC2 インスタンス、EBS ボリューム、EC2 ロードバランサーなどのリソースを管理するのに必要な EKS Auto Mode のアクセス許可が含まれています。
+ **[推奨ロールを作成]** オプションでは、すべてのフィールドに推奨値が事前入力されています。**[次へ]**、**[作成]** の順に選択します。ロールは推奨される `AmazonEKSAutoClusterRole` という名前を使用します。
+ 最近新しいロールを作成した場合は、**[更新]** アイコンを使用してロール選択ドロップダウンを再ロードします。
1. ノード IAM ロールを選択します。EKS Auto Mode クラスターを初めて作成する場合は、**[推奨ロールを作成]** オプションを使用します。
+ 必要に応じて、すべての EKS Auto Mode クラスターに対して、AWS アカウントで 1 つのノード IAM ロールを再利用できます。
+ ノード IAM ロールには、Auto Mode ノードがクラスターに接続するのに必要なアクセス許可が含まれています。ノード IAM ロールには、コンテナの ECR イメージを取得するためのアクセス許可が付与されている必要があります。
+ **[推奨ロールを作成]** オプションでは、すべてのフィールドに推奨値が事前入力されています。**[次へ]**、**[作成]** の順に選択します。ロールは推奨される `AmazonEKSAutoNodeRole` という名前を使用します。
+ 最近新しいロールを作成した場合は、**[更新]** アイコンを使用してロール選択ドロップダウンを再ロードします。
1. EKS Auto Mode クラスターの VPC を選択します。**[VPC を作成]** を選択して EKS 用の新しい VPC を作成するか、以前に EKS 用に作成した VPC を選択します。
+ VPC コンソールを使用して新しい VPC を作成する場合は、AWS ではアベイラビリティーゾーンごとに少なくとも 1 つの NAT ゲートウェイを作成することをお勧めします。それ以外の場合は、他のすべてのデフォルトを使用できます。
+ さらなる情報と IPv6 クラスターの要件の詳細については、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。
1. (任意) EKS Auto Mode は、選択した VPC のプライベートサブネットを自動的に入力します。不要なサブネットは削除できます。
+ EKS では、ベストプラクティスに従って VPC からプライベートサブネットが自動的に選択されます。必要に応じて、パブリックサブネットなど、VPC から追加のサブネットを選択できます。
1. (任意) **[クイック設定のデフォルトを表示]** を選択して、新しいクラスターのすべての設定値を確認します。この表は、クラスターの作成後には一部の値を編集できないことを示しています。
1. [**Create cluster (クラスターの作成)**] を選択します。クラスターの作成が完了するまでに 15 分かかる場合があります。
## 次のステップ
+ [サンプルワークロードを EKS Auto Mode クラスターにデプロイする](sample-storage-workload.md)方法について説明します。
# 既存の EKS クラスターで EKS 自動モードを有効にする
既存の EKS クラスターで EKS 自動モード を有効にできます。
** AWS では次の移行がサポートされています。**
+ Karpenter から EKS 自動モードノードへの移行。詳細については、「[kubectl を使用して Karpenter から EKS 自動モードl に移行する](auto-migrate-karpenter.md)」を参照してください。
+ EKS マネージドノードグループから EKS 自動モードノードへの移行。詳細については、「[EKS マネージドノードグループから EKS Auto Mode に移行する](auto-migrate-mng.md)」を参照してください。
+ EKS Fargate から EKS 自動モードへの移行。詳細については、「[EKS Fargate から EKS Auto Mode に移行する](auto-migrate-fargate.md)」を参照してください。
** AWS では以下の移行はサポートされていません。**
+ EBS CSI コントローラー (Amazon EKS アドオンを使用) から EKS 自動モード EBS CSI コントローラー (EKS 自動モードで管理) へのボリュームの移行。これらは 2 つの異なる Kubernetes ボリュームプロビジョナーを使用するため、一方で作成された PVC をもう一方でマウントすることはできません。
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (AWS Labs プロジェクト) により、標準の EBS CSI StorageClass (`ebs.csi.aws.com`) と EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`) 間の移行が可能になります。移行では、既存の PersistentVolumeClaim/PersistentVolume リソースを削除して再作成する必要があるため、実装前に非本番環境での検証が不可欠です。
+ AWS ロードバランサー コントローラー から EKS 自動モード へのロードバランサーの移行
Amazon EKS 自動モード クラスターに AWS ロードバランサー コントローラー をインストールできます。`IngressClass` または `loadBalancerClass` のオプションを使用して、サービスリソースとイングレスリソースを ロードバランサー コントローラー または EKS 自動モード のいずれかに関連付けます。
+ 代替 CNI またはその他のサポートされていないネットワーク設定を使用した EKS クラスターの移行
## 移行のリファレンス
次の移行のリファレンスを使用して、Kubernetes リソースをセルフマネージドコントローラーまたは EKS 自動モードが所有するように設定します。
| 機能 | [リソース] | フィールド | セルフマネージド型 | EKS 自動モード |
| --- | --- | --- | --- | --- |
| ブロックストレージ | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| 負荷分散 | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| 負荷分散 | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| 負荷分散 | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| 負荷分散 | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| コンピューティング | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## EBS ボリュームの移行
ワークロードを EKS 自動モードに移行する場合、CSI ドライバープロビジョナーが異なるため、EBS ボリュームの移行を処理する必要があります。
+ EKS 自動モードのプロビジョナー: `ebs.csi.eks.amazonaws.com`
+ オープンソース EBS CSI のプロビジョナー: `ebs.csi.aws.com`
永続ボリュームを移行するには、次の手順を実行します。
1. **ボリューム保持ポリシーの変更**: 既存のプラットフォームバージョン (PV) の `persistentVolumeReclaimPolicy` を `Retain` に変更して、基盤となる EBS ボリュームが削除されないようにします。
1. **Kubernetes からの PV の削除**: 実際の EBS ボリュームはそのまま保持しながら、古い PV リソースを削除します。
1. **静的プロビジョニングを使用した新規 PV の作成**: 同じ EBS ボリュームを参照するが、ターゲット CSI ドライバーで動作する新しい PV を作成します。
1. **新規 PVC へのバインド**: `volumeName` フィールドを使用して、特定の PV を明示的に参照する新しい PVC を作成します。
### 考慮事項
+ この移行を開始する前に、アプリケーションが停止していることを確認します。
+ 移行プロセスを開始する前に、データをバックアップします。
+ このプロセスは、永続ボリュームごとに実行する必要があります。
+ 新しい PVC を使用するようにワークロードを更新する必要があります。
## ロードバランサーの移行
AWS セルフマネージドロードバランサーコントローラーから EKS 自動モード に既存のロードバランサーを直接転送することはできません。代わりに、ブルー/グリーンデプロイ戦略を実装する必要があります。これはマネージドコントローラーで新しいロードバランサーを作成しながら、既存のロードバランサー設定を維持することになります。
サービスの中断を最小限に抑えるにはDNS ベースのトラフィックシフトアプローチをお勧めします。まず、既存の設定を稼働させたまま、EKS 自動モードを使用して新しいロードバランサーを作成します。次に、DNS ルーティング (Route 53 など) を使用して、古いロードバランサーから新しいロードバランサーにトラフィックを徐々に移行します。トラフィックが正常に移行され、新しい設定を確認したら、古いロードバランサーとセルフマネージドコントローラーを廃止できます。
# 既存のクラスターで EKS Auto Mode を有効にする
このトピックでは、既存の Amazon EKS クラスターで Amazon EKS Auto Mode を有効にする方法について説明します。既存のクラスターで Auto Mode を有効にするには、IAM アクセス許可を更新し、コア EKS Auto Mode 設定を構成する必要があります。有効にすると、既存のコンピューティングワークロードの移行を開始して、Auto Mode のシンプルなオペレーションと自動化されたインフラストラクチャ管理を活用できます。
**重要**
EKS Auto Mode を有効にする前に、特定の Amazon EKS アドオンの求められるバージョン以降がインストールされていることを確認します。詳細については、「[必要なアドオンバージョン](#auto-addons-required)」を参照してください。
開始する前に、Amazon EKS クラスターへの管理者アクセスと、IAM ロールを変更するアクセス許可があることを確認してください。このトピックのステップでは、AWS マネジメントコンソールまたは AWS CLI を使用して Auto Mode を有効にする方法について説明します。
## AWS マネジメントコンソール
IAM、EKS、および EC2 リソースを管理するアクセス許可が付与された状態で AWS コンソールにログインする必要があります。
**注記**
EKS クラスターのクラスター IAM ロールは、クラスターの作成後に変更することはできません。EKS Auto Mode には、このロールに対する追加のアクセス許可が必要です。追加のポリシーを現在のロールにアタッチする必要があります。
### クラスター IAM ロールを更新する
1. AWS マネジメントコンソールでクラスターの概要ページを開きます。
1. **[クラスター IAM ロール ARN]** で、**[IAM で表示]** を選択します。
1. **[アクセス許可を追加]** ドロップダウンから **[ポリシーをアタッチ]** を選択します。
1. **[検索]** ボックスより、次のポリシーを検索して選択します。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. **[アクセス許可を追加]** を選択します。
1. **[信頼関係]** タブで、**[信頼ポリシーを編集]** を選択します。
1. 次のクラスター IAM ロール信頼ポリシーを挿入し、**[ポリシーを更新]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### EKS Auto Mode を有効にする
1. AWS マネジメントコンソールでクラスターの概要ページを開きます。
1. **[EKS Auto Mode]** で **[管理]** を選択します
1. **EKS Auto Mode** をオンに切り替えます。
1. **[EKS ノードプール]** ドロップダウンから、作成するデフォルトのノードプールを選択します。
+ EKS Auto Mode のノードプールの詳細を確認してください。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
1. この AWS アカウントで EKS Auto Mode Node IAM ロールを以前に作成している場合は、**[ノード IAM ロール]** ドロップダウンでそのロールを選択します。以前にこのロールを作成したことがない場合は、**[推奨ロールを作成]** を選択し、手順に従います。
## AWS CLI
### 前提条件
+ 既存の EKS クラスターのクラスター IAM ロールには、以下のポリシーなど、EKS Auto Mode に対する十分なアクセス許可が付与されている必要があります。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ クラスター IAM ロールには、`sts:TagSession` アクションを含む更新された信頼ポリシーが必要です。クラスター IAM ロール作成の詳細については、「[AWS CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-cli.md)」を参照してください。
+ `aws` CLI がインストール済み、ログイン済み、および十分なバージョンがある。IAM、EKS、および EC2 リソースを管理するためのアクセス許可が必要です。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
### 手順
次のコマンドを使用して、既存のクラスターで EKS Auto Mode を有効にします。
**注記**
コンピューティング、ブロックストレージ、およびロードバランシング機能はすべて、同じリクエストで有効または無効にする必要があります。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## 必要なアドオンバージョン
既存のクラスターで EKS Auto Mode を有効にする場合は、特定のアドオンを更新することが必要になる場合があります。次のことにご注意ください。
+ これは、既存のクラスターを EKS Auto Mode に移行する場合にのみ該当します。
+ EKS Auto Mode を有効にして作成された新しいクラスターでは、この更新は必要ありません。
次のいずれかのアドオンがインストールされている場合は、指定された最小バージョン以上であることを確認してください。
| アドオン名 | 求められる最小バージョン |
| --- | --- |
| Amazon VPC CNI Kubernetes用プラグイン | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/auto-enable-existing.html) |
| Amazon EBS CSI ドライバー | v1.37.0-eksbuild.1 |
| CSI スナップショットコントローラー | v8.1.0-eksbuild.2 |
| EKS Pod Identity エージェント | v1.3.4-eksbuild.1 |
詳細については、「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。
## 次のステップ
+ ノードグループワークロードの管理を移行するには、「[EKS マネージドノードグループから EKS Auto Mode に移行する](auto-migrate-mng.md)」を参照してください。
+ セルフマネージド Karpenter から移行するには、「[kubectl を使用して Karpenter から EKS 自動モードl に移行する](auto-migrate-karpenter.md)」を参照してください。
# kubectl を使用して Karpenter から EKS 自動モードl に移行する
このトピックではkubectl を使用してワークロードを Karpenter から Amazon EKS 自動モードl に移行するプロセスについて説明します。移行は段階的に実行できるため、移行を通じてクラスターの安定性とアプリケーションの可用性を維持しながら、ワークロードを自分のペースで移動できます。
以下に説明するステップバイステップのアプローチにより、移行期間中に Karpenter と EKS 自動モードl をサイドバイサイドで実行できます。このデュアルオペレーション戦略により、Karpenter を完全に廃止する前に EKS 自動モードl でワークロードの動作を検証できるため、スムーズな移行が可能になります。アプリケーションは個別またはグループで移行できるため、特定の運用要件とリスク許容度に柔軟に対応できます。
## 前提条件
移行を開始する前に、以下のことを確認してください：
+ Karpenter v1.1 以降がクラスターにインストールされている。詳細についてはKarpenter ドキュメントの「[Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110)」を参照してください。
+ `kubectl` がインストールされ、クラスターに接続されている。詳細については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
このトピックではKarpenter と ノードプールs に精通していることを前提としています。詳細については[Karpenter ドキュメント](https://karpenter.sh/)を参照してください。
## ステップ 1: クラスターで EKS 自動モードl を有効にする
AWS CLI またはマネジメントコンソールを使用して、既存のクラスターで EKS 自動モードl を有効にします。詳細については「[既存のクラスターで EKS Auto Mode を有効にする](auto-enable-existing.md)」を参照してください。
**注記**
EKS 自動モードl を有効にする際には移行中のこの段階で `general purpose` ノードプールを有効にしないでください。このノードプールは選択的ではありません。
詳細については「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
## ステップ 2: テイントが適用された EKS 自動モードl ノードプール を作成する
テイントを使用して、EKS 自動モードl 用の新しい ノードプール を作成します。これを行うことで、既存のポッドが新しい EKS 自動モードl ノードで自動的にスケジュールされることはありません。このノードプールはEKS 自動モードl に組み込まれた `default` `NodeClass` を使用します。詳細については「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
テイントが適用されたノードプールの例:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
移行元の Karpenter 構成と一致するように、ノード プールの要件を更新します。少なくとも 1 つの要件が必要です。
## ステップ 3: 移行するワークロードを更新する
EKS 自動モードl に移行するワークロードを特定して更新します。これらのワークロードに許容範囲とノードセレクターの両方を追加します：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
この変更により、新しい EKS 自動モードl ノードでワークロードをスケジュールできます。
EKS 自動モードl は Karpenter とは異なるラベルを使用します。EC2 マネージドインスタンスに関連するラベルは`eks.amazonaws.com` で始まります。詳細については「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## ステップ 4: ワークロードを段階的に移行する
移行するワークロードごとにステップ 3 を繰り返します。この結果、要件とリスク許容度に基づいて、ワークロードを個別またはグループで移動できます。
## ステップ 5: 元の Karpenter ノードプール を削除する
すべてのワークロードを移行したら、元の Karpenter ノードプール を削除できます：
```
kubectl delete nodepool
```
## ステップ 6: EKS 自動モードl ノードプール からテイントを削除する (任意)
EKS 自動モードl を新しいワークロードのデフォルトにする場合はEKS 自動モードl ノードプール からテイントを削除できます：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## ステップ 7: ワークロードからノードセレクターを削除する (任意)
EKS 自動モードl ノードプール からテイントを削除した場合はEKS 自動モードl がデフォルトになったため、必要に応じてワークロードからノードセレクターを削除できます：
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## ステップ 8: クラスターから Karpenter をアンインストールする
Karpenter を削除するステップはインストール方法によって異なります。詳細については「[Karpenter install instructions](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter)」を参照してください。
# EKS マネージドノードグループから EKS Auto Mode に移行する
EKS Auto Mode を使用するように Amazon EKS クラスターを移行する場合、eksctl CLI ツールを使用してマネージドノードグループ (MNG) から既存のワークロードをスムーズに移行できます。このプロセスにより、EKS Auto Mode がコンピューティングリソースを最適化しながら、アプリケーションの継続的な可用性が確保されます。移行は、実行中のアプリケーションの中断を最小限に抑えて実行できます。
このトピックでは、既存のマネージドノードグループからポッドを安全にドレインし、EKS Auto Mode が新しくプロビジョニングされたインスタンスでポッドを再スケジュールできるようにする手順について説明します。この手順に従うことで、移行を通じてアプリケーションの可用性を維持しながら、EKS Auto Mode のインテリジェントなワークロード統合を活用できます。
## 前提条件
+ EKS Auto Mode が有効になっているクラスター
+ `eksctl` CLI がインストールされ、クラスターに接続されている。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
+ Karpenter がクラスターにインストールされていない。
## 手順
次の `eksctl` CLI コマンドを使用して、既存のマネージドノードグループインスタンスからポッドのドレインを開始します。EKS Auto Mode は、置き換えられたポッドをバックアップする新しいノードを作成します。
```
eksctl delete nodegroup --cluster= --name=
```
クラスター内のマネージドノードグループごとに、このコマンドを実行する必要があります。
このコマンドの詳細については、eksctl のドキュメントの「[Deleting and draining nodegroups](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)」を参照してください。
# EKS Fargate から EKS Auto Mode に移行する
このトピックでは、`kubectl` を使用してワークロードを EKS Fargate から Amazon EKS Auto Mode に移行するプロセスについて説明します。移行は段階的に実行できるため、移行を通じてクラスターの安定性とアプリケーションの可用性を維持しながら、ワークロードを自分のペースで移動できます。
以下に説明するステップバイステップのアプローチを取ると、移行期間中に EKS Fargate と EKS Auto Mode を並行して実行できます。このデュアルオペレーション戦略では、EKS Fargate を完全に廃止する前に EKS Auto Mode でワークロードの動作を検証できるため、スムーズな移行が可能です。アプリケーションは個別またはグループで移行できるため、特定の運用要件とリスク許容度に柔軟に対応できます。
## Amazon EKS Auto Mode と、AWS Fargate を使用した EKS の比較
AWS Fargate を使用する Amazon EKS は、EKS を実行するお客様に引き続きオプションとしてご利用いただけますが、今後のアプローチとしては Amazon EKS Auto Mode がお勧めです。EKS Auto Mode は、Kubernetes に完全に準拠しており、Fargate では対応していない Istio などのアップストリーム Kubernetes プリミティブとプラットフォームツールをすべてサポートしています。EKS Auto Mode は、GPU インスタンスやスポットインスタンスを含め、すべての EC2 ランタイム購入オプションにも完全に対応しているため、EC2 の割引の交渉といった仕組みを活用して節約を行えます。Fargate で EKS を使用する場合は、そのような機能が用意されていません。
さらに、EKS Auto Mode なら、Fargate と同じ分離モデルを実現できます。これを行うには、標準の Kubernetes スケジューリング機能を使用して、各 EC2 インスタンスで 1 つのアプリケーションコンテナを実行します。Amazon EKS Auto Mode を導入すると、Kubernetes を AWS で実行するメリットを最大限に活用できます。これはKubernetes に完全準拠したプラットフォームであり、EC2 と購入の広範なオプションをすべて利用できます。また、Fargate が実現するインフラストラクチャ管理の利便性や抽象化も維持されています。
### EKS Auto Mode で Fargate のような分離を実現する
各ポッドがそれぞれの専用インスタンスで実行される Fargate のポッド分離モデルをレプリケートするには、Kubernetes トポロジの分散制約を使用できます。これは、ノード間でポッド分散を制御するための推奨アプローチです。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
この設定では、次のようになります。
+ `maxSkew: 1` は、任意の 2 つのノード間のポッド数の差が最大 1 であることを保証し、ノードごとに 1 つのポッドを効果的に分散する
+ `topologyKey: kubernetes.io/hostname` はノードをトポロジドメインとして定義する
+ `whenUnsatisfiable: DoNotSchedule` は、制約が満たされない場合、スケジューリングを禁止する
+ `minDomains: 1` は、スケジュールする前に、少なくとも 1 つのドメイン (ノード) が存在することを確認する
EKS Auto Mode は、この制約を満たすために必要に応じて新しい EC2 インスタンスを自動的にプロビジョニングし、Fargate と同じ分離モデルを提供しながら、すべての EC2 インスタンスタイプと購入オプションへのアクセス権を付与します。
または、ポッドアンチアフィニティルールを使用して、より厳密な分離を行うこともできます。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
`requiredDuringSchedulingIgnoredDuringExecution` を含む `podAntiAffinity` ルールにより、ラベル `app: isolated-app` を持つ 2 つのポッドを同じノードでスケジュールすることを禁止します。このアプローチにより、Fargate と同様の強固な分離を保証します。
## 前提条件
移行を開始する前に、以下を確認します。
+ Fargate を使用してクラスターをセットアップします。詳細については、「[クラスターの AWS Fargate の使用を開始する](fargate-getting-started.md)」を参照してください。
+ `kubectl` がインストールされ、クラスターに接続されている。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## ステップ 1: Fargate クラスターを確認する
1. Fargate を使用する EKS クラスターが実行中かどうかを確認します。
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. 実行中のポッドを確認します。
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. `deployment_fargate.yaml` という名前のファイルにデプロイを記述します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. デプロイを適用します：
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. ポッドとデプロイを確認します。
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. ノードを確認します。
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## ステップ 2: クラスターで EKS Auto Mode を有効にする
1. AWS CLI またはマネジメントコンソールを使用して、既存のクラスターで EKS 自動モードl を有効にします。詳細については、「[既存のクラスターで EKS Auto Mode を有効にする](auto-enable-existing.md)」を参照してください。
1. ノードプールを確認します。
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## ステップ 3: 移行するワークロードを更新する
EKS 自動モードl に移行するワークロードを特定して更新します。
Fargate から EKS Auto Mode にワークロードを移行するには、注釈 `eks.amazonaws.com/compute-type: ec2` を適用します。こうすることで、Fargate プロファイルに関係なく、Fargate によるワークロードスケジュールは行われず、その役割は EKS Auto Mode NodePool に引き継がれます。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
1. デプロイ (`deployment_fargate.yaml` ファイルなど) を変更して、コンピューティングタイプを `ec2` に変更します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. デプロイを適用します。この変更により、新しい EKS Auto Mode ノードでワークロードをスケジュールできます。
```
kubectl apply -f deployment_fargate.yaml
```
1. デプロイが EKS Auto Mode クラスターで実行されていることを確認します。
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Fargate ノードが実行されておらず、デプロイが EKS Auto Mode のマネージドノードで実行中であることを確認します。
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## ステップ 4: ワークロードを段階的に移行する
移行するワークロードごとにステップ 3 を繰り返します。この結果、要件とリスク許容度に基づいて、ワークロードを個別またはグループで移動できます。
## ステップ 5: 元の fargate プロファイルを削除する
すべてのワークロードを移行したら、元の `fargate` プロファイルを削除できます。** を Fargate プロファイルの名前に置き換えます。
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## ステップ 6: CoreDNS をスケールダウンする
EKS Auto Mode では CoreDNS が処理されるため、`coredns` デプロイを 0 にスケールダウンします。
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# EKS 自動モードl クラスターでワークロードを実行する
この章では自動モードl で実行されている アマゾン EKS クラスターにさまざまなタイプのワークロードをデプロイする方法の例を示します。この例ではサンプルアプリケーション、ロードバランシングされたウェブアプリケーション、永続的ストレージを使用するステートフルワークロード、特定のノード配置要件があるワークロードなどの主要なワークロードパターンを示しています。各例には独自のアプリケーションのテンプレートとして使用できる、完全なマニフェストとステップバイステップのデプロイステップが含まれています。
例に進む前に、EKS クラスターが 自動モードl で実行され、AWS CLI と kubectl がインストールされた状態にしてください。詳細については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。この例ではKubernetes の概念と kubectl コマンドに関する基本的な知識があることを前提としています。
これらのユースケースベースのサンプルを使用して、EKS 自動モードl クラスターでワークロードを実行できます。
[Amazon EKS Auto Mode クラスターにサンプルの拡張ワークロードをデプロイする](automode-workload.md)
`kubectl` コマンドを使用してサンプルワークロードを EKS 自動モードl クラスターにデプロイする方法を示しています。
[サンプルロードバランサーワークロードを EKS 自動モードl にデプロイする](auto-elb-example.md)
アマゾン EKS で 2048 ゲームのコンテナ化されたバージョンをデプロイする方法を示しています。
[ステートフルワークロードのサンプルを EKS Auto Mode にデプロイする](sample-storage-workload.md)
サンプルステートフルアプリケーションを EKS 自動モードl クラスターにデプロイする方法を示しています。
[加速ワークロードをデプロイする](auto-accelerated.md)
EKS 自動モードで管理されるノードにハードウェアアクセラレーションワークロードをデプロイする方法を示します。
[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)
注釈を使用して、EKS 自動モードl によって管理されるノードにワークロードがデプロイされるかどうかを制御する方法を示しています。
# Amazon EKS Auto Mode クラスターにサンプルの拡張ワークロードをデプロイする
このチュートリアルでは、サンプルワークロードを EKS Auto Mode クラスターにデプロイする方法と、必要なコンピューティングリソースがどのように自動的にプロビジョニングされるか説明します。`kubectl` コマンドを使用してクラスターの動作を監視し、Auto Mode により AWS での Kubernetes オペレーションがどのように簡素化されるかを直接確認します。このチュートリアルを終了すると、基盤となるコンピューティングリソースを自動的に管理することで、ノードグループを手動で設定する必要なく、EKS Auto Mode がワークロードのデプロイにどのように対応するかがわかります。
## 前提条件
+ Amazon EKS Auto Mode クラスター。クラスターの名前と AWS リージョンをメモします。
+ ネットワーキング、コンピューティング、および EKS リソースを管理するのに十分なアクセス許可を持つ、ユーザーやロールなどの IAM プリンシパル。
+ 詳細については、「IAM ユーザーガイド」の「[Creating roles and attaching policies in the IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)」を参照してください。
+ IAM ID で `aws` CLI がインストールおよび設定されている。
+ `kubectl` CLI がインストールされ、クラスターに接続されている。
+ 詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## ステップ 1: 既存のコンピューティングリソースを確認する (任意)
まず、`kubectl` を使用してクラスターのノードプールを一覧表示します。
```
kubectl get nodepools
```
サンプル出力:
```
general-purpose
```
このチュートリアルでは、`general-purpose` ノードプールを使用するように設定されたワークロードをデプロイします。このノードプールは EKS Auto Mode に組み込まれ、マイクロサービスやウェブアプリケーションなどの一般的なワークロードに適したデフォルトが含まれます。独自のノードプールを作成できます。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
次に、`kubectl` を使用してクラスターに接続されているノードを一覧表示します。
```
kubectl get nodes
```
EKS Auto Mode クラスターを作成したばかりの場合は、ノードはありません。
このチュートリアルでは、サンプルワークロードをデプロイします。ノードがない場合、またはワークロードが既存のノードに収まらない場合、EKS Auto Mode は新しいノードをプロビジョニングします。
## ステップ 2: サンプルアプリケーションをクラスターにデプロイする
次の Kubernetes デプロイを確認し、`inflate.yaml` として保存します
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
`eks.amazonaws.com/compute-type: auto` セレクターでは、ワークロードを Amazon EKS Auto Mode ノードにデプロイする必要があることに注意してください。
デプロイをクラスターに適用します。
```
kubectl apply -f inflate.yaml
```
## ステップ 3: Kubernetes イベントを監視する
次のコマンドを使用して、新しいノードの作成などの Kubernetes イベントを監視します。`ctrl+c` を使用してイベントの監視を停止します。
```
kubectl get events -w --sort-by '.lastTimestamp'
```
`kubectl` を使用して、クラスターに接続されているノードを再度一覧表示します。新しく作成されたノードをメモします。
```
kubectl get nodes
```
## ステップ 4: AWS コンソールでノードとインスタンスを表示する
EKS Auto Mode ノードは EKS コンソールで表示でき、関連付けられた EC2 インスタンスは EC2 コンソールで表示できます。
EKS Auto Mode によってデプロイされた EC2 インスタンスは制限されています。EKS Auto Mode ノードで任意のコマンドを実行することはできません。
## ステップ 5: デプロイを削除する
`kubectl` を使用してサンプルデプロイを削除します
```
kubectl delete -f inflate.yaml
```
クラスターに他のワークロードがデプロイされていない場合、EKS Auto Mode によって作成されたノードは空になります。
デフォルト設定では、EKS Auto Mode は空のノードを 30 秒間検出し、そのノードを終了します。
`kubectl` または EC2 コンソールを使用して、関連付けられたインスタンスが削除されたことを確認します。
# サンプルロードバランサーワークロードを EKS 自動モードl にデプロイする
このガイドではロードバランシングとインターネットアクセシビリティを備えて、コンテナ化されたバージョンの 2048 ゲームを Amazon EKS にデプロイする方法について説明します。
## 前提条件
+ EKS 自動モードl クラスター
+ クラスターとやり取りするように設定された `kubectl`
+ ALB リソースを作成するための適切な IAM アクセス許可
## ステップ 1: 名前空間を作成する
まず、2048 ゲームアプリケーション専用の名前空間を作成します。
`01-namespace.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
この名前空間設定を適用します：
```
kubectl apply -f 01-namespace.yaml
```
## ステップ 2: アプリケーションをデプロイする
アプリケーションは 2048 ゲームコンテナの複数のレプリカを実行してください。
`02-deployment.yaml` という名前のファイルを作成します：
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**注記**
イメージ `public.ecr.aws/l6m2t8p7/docker-2048:latest` のロード中にエラーが表示された場合は、ノード IAM ロールに ECR からイメージをプルするための十分なアクセス許可があることを確認します。詳細については、「[ノード の IAM ロール](auto-learn-iam.md#auto-learn-node-iam-role)」を参照してください。また、この例の `docker-2048` イメージは `x86_64` イメージであり、他のアーキテクチャでは実行できません。
**主要コンポーネント:**
+ アプリケーションのレプリカ 5 つをデプロイ
+ パブリック ECR イメージを使用
+ ポッドあたり 0.5 CPU コアをリクエスト
+ HTTP トラフィック用にポート 80 を公開
デプロイを適用します：
```
kubectl apply -f 02-deployment.yaml
```
## ステップ 3: サービスを作成する
サービスによりデプロイがクラスターネットワークに公開されます。
`03-service.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**主要コンポーネント:**
+ NodePort サービスを作成
+ ポート 80 をコンテナのポート 80 にマップ
+ ラベルセレクターを使用してポッドを検索
サービスを適用します：
```
kubectl apply -f 03-service.yaml
```
## ステップ 4: ロードバランシングを設定する
アプリケーションがインターネットに公開されるようにイングレスを設定します。
まず `IngressClass` を作成します。`04-ingressclass.yaml` という名前のファイルを作成します：
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
次に、イングレスリソースを作成します。`05-ingress.yaml` という名前のファイルを作成します：
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**主要コンポーネント:**
+ インターネット向け ALB を作成
+ 直接ポッドルーティングに IP ターゲットタイプを使用
+ すべてのトラフィックをルーティングまたはゲームサービスにルーティング
イングレス設定を適用します：
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## ステップ 5: デプロイを検証する
1. すべてのポッドが実行されていることを確認します：
```
kubectl get pods -n game-2048
```
1. サービスが作成されていることを確認します：
```
kubectl get svc -n game-2048
```
1. ALB エンドポイントを取得します：
```
kubectl get ingress -n game-2048
```
イングレス出力の ADDRESS フィールドに ALB エンドポイントが表示されます。ALB がすべてのターゲットをプロビジョニングして登録するまで 2～3 分待ちます。
## ステップ 6: ゲームにアクセスする
ウェブブラウザを開き、前のステップの ALB エンドポイント URL にアクセスします。2048 ゲームインターフェイスが表示されるはずです。
## ステップ 7: クリーンアップ
このチュートリアルで作成したリソースをすべて削除するには:
```
kubectl delete namespace game-2048
```
これにより、デプロイ、サービス、イングレスリソースなど、名前空間内のすべてのリソースが削除されます。
## シーンの背後で起こっていること
1. デプロイでは2048 ゲームを実行するポッドが 5 つ作成されます
1. このサービスではこれらのポッドに安定したネットワークアクセスを提供します
1. EKS 自動モードl:
+ AWS で Application Load Balancer を作成します
+ ポッドのターゲットグループを設定します
+ サービスにトラフィックを誘導するルーティングルールを設定します
## トラブルシューティング
ゲームがロードされない場合:
+ すべてのポッドが実行されていることを確認: `kubectl get pods -n game-2048`
+ イングレスステータスの確認: `kubectl describe ingress -n game-2048`
+ ALB ヘルスチェックの検証: AWS コンソールでターゲットグループのヘルスを確認します
# ステートフルワークロードのサンプルを EKS Auto Mode にデプロイする
このチュートリアルでは、EKS Auto Mode クラスターにステートフルアプリケーションのサンプルをデプロイする方法について説明します。このアプリケーションは永続ボリュームにタイムスタンプを書き込み、EBS Auto Mode の自動 EBS ボリュームプロビジョニングと永続化機能を示します。
## 前提条件
+ EKS Auto Mode クラスター
+ 適切なアクセス許可で設定された AWS CLI
+ インストールおよび設定済みの `kubectl`
+ 詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## ステップ 1: 環境を設定する
1. 環境変数を設定する:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. kubeconfig を更新します:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## ステップ 2: ストレージクラスを作成する
`StorageClass`は、EBS ボリュームを EKS Auto Mode でプロビジョニングする方法を定義します。
EKS Auto Mode では、お客様用の `StorageClass` は作成されません。EKS Auto Mode のストレージ機能を使用するには、`ebs.csi.eks.amazonaws.com` を参照する `StorageClass` を作成する必要があります。
1. `storage-class.yaml` という名前のファイルを作成します：
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. `StorageClass` を適用します。
```
kubectl apply -f storage-class.yaml
```
**主要コンポーネント:**
+ `provisioner: ebs.csi.eks.amazonaws.com` - EKS Auto Mode を使用する
+ `volumeBindingMode: WaitForFirstConsumer` - ポッドが必要とするまでボリュームの作成を遅らせる
+ `type: gp3` - EBS ボリュームタイプを指定する
+ `encrypted: "true"` - EBS はデフォルトの `aws/ebs` キーを使用して、このクラスで作成されたボリュームを暗号化します。これはオプションですが推奨されます。
+ `storageclass.kubernetes.io/is-default-class: "true"` - 永続ボリュームのクレームで別のボリュームクラスを指定しない限り、Kubernetes はデフォルトでこのストレージクラスを使用します。別のストレージコントローラーから移行する場合は、この値を設定するときに注意してください 。(オプション)
## ステップ3: 永続的なボリューム要求を作成する
PVC は`StorageClass`からのストレージをリクエストします。
1. `pvc.yaml` という名前のファイルを作成します：
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. SCP を適用します:
```
kubectl apply -f pvc.yaml
```
**主要コンポーネント:**
+ `accessModes: ReadWriteOnce` - ボリュームは一度に 1 つのノードからマウントすることができます
+ `storage: 8Gi` - 8 GiB ボリュームをリクエストします
+ `storageClassName: auto-ebs-sc` - 作成した`StorageClass`を参照します
## ステップ 4: アプリケーションのデプロイ
Deployment は、永続的ボリュームにタイムスタンプを書き込むコンテナを実行します。
1. `deployment.yaml` という名前のファイルを作成します：
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. デプロイを適用します。
```
kubectl apply -f deployment.yaml
```
**主要コンポーネント:**
+ ファイルにタイムスタンプを書き込むシンプルな bash コンテナ
+ PVC を `/data` にマウントします
+ 1 CPU コアをリクエストします
+ EKS マネージドノードのノードセレクタを使用します
## ステップ 5: セットアップを検証する
1. ポッドが稼働していることを確認します:
```
kubectl get pods -l app=inflate-stateful
```
1. PVC がバインドされていることを確認します:
```
kubectl get pvc auto-ebs-claim
```
1. EBS ボリュームを確認します:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. データが書き込まれていることを確認します:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## ステップ 6: クリーンアップ
次のコマンドを実行して、このチュートリアルで作成したすべてのリソースを削除します。
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## シーンの背後で起こっていること
1. PVC は`StorageClass`からのストレージをリクエストします
1. ポッドがスケジュールされている場合:
1. EKS Auto Mode が EBS ボリュームをプロビジョニングします
1. PersistentVolume を作成します
1. ボリュームをノードにアタッチします。
1. ポッドはボリュームをマウントし、タイムスタンプの書き込みを開始します
## Snapshot Controller
EKS Auto Mode は、スナップショットコントローラーとも呼ばれる Kubernetes CSI Snapshotter と互換性があります。ただし、EKS Auto Mode にはスナップショットコントローラーがありません。スナップショットコントローラーのインストールと設定はお客様の責任となります。詳細については、「[CSI ボリュームのためにスナップショット機能を有効にする](csi-snapshot-controller.md)」を参照してください。
EKS Auto Mode のストレージ機能を参照する以下の `VolumeSnapshotClass` を確認してください。
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Kubernetes CSI Snapshotter の詳細をご覧ください。](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# 加速ワークロードをデプロイする
このチュートリアルでは、Amazon EKS 自動モードがハードウェアアクセラレーションワークロードの開始をどのようにシンプルにしているかを説明します。Amazon EKS Auto Mode は、コンピューティング、ネットワーキング、ロードバランシング、ストレージ、Identity Access and Management の各機能を追加の設定なしで実現する主要なインフラストラクチャコンポーネントを自動化することで、クラスター自体にとどまらずさまざまな運用を簡素化します。
Amazon EKS Auto Mode には、NVIDIA ドライバーや AWS Neuron ドライバーなど、特定のインスタンスタイプに必要なドライバーとデバイスプラグインが含まれています。これらのコンポーネントをお客様側でインストールおよび更新する必要はありません。
EKS Auto Mode が次のアクセラレーター用のドライバーを自動的に管理します。
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [NVIDIA GPUs on Amazon EC2 加速インスタンス](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**注記**
EKS Auto Mode には、Kubernetes 用の NVIDIA デバイスプラグインが含まれています。このプラグインは、自動的に動作し、クラスターにデーモンセットとして表示されません。
ネットワーキングに関するその他のサポート:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS Auto Mode により、アクセラレーター用のドライバーとデバイスプラグインを管理するという手間が不要になります。
また、クラスターがゼロにスケーリングされるので、コスト削減というメリットも得られます。実行中のワークロードがなくなったらインスタンスを終了するように、EKS Auto Mode を設定できます。これはバッチベースの推論ワークロードに便利です。
以下に、Amazon EKS Auto Mode で加速ワークロードを開始する方法の例を示します。
## 前提条件
+ Amazon EKS Auto Mode で Kubernetes クラスターが設定されていること。
+ `general-purpose` または `system` のいずれかのマネージドノードプールが有効であれば、`default` EKS ノードクラスが作成されること。
## ステップ 1: GPU ワークロードをデプロイする
この例では、45 GB の GPU メモリを必要とする NVIDIA ベースのワークロード用に NodePool を作成します。EKS Auto Mode では、Kubernetes スケジュール制約を使用して、インスタンス要件を定義します。
Amazon EKS Auto Mode `NodePool` とサンプルの `workload` をデプロイするには、NodePool とポッドに関する以下の定義を確認し、`nodepool-gpu.yaml` および `pod.yaml` として保存します。
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
`eks.amazonaws.com/compute-type: auto` セレクターでは、ワークロードを Amazon EKS Auto Mode ノードにデプロイする必要があることに注意してください。また、NodePool は Nvidia GPU に対する許容範囲が設定されたポッドに限りスケジュールできるというテイントを設定します。
NodePool とワークロードをクラスターに適用します。
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
以下の出力が表示されます。
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
数秒待ってからクラスター内のノードを確認します。これで、新しいノードが Amazon EKS Auto Mode クラスターにプロビジョニングされるはずです。
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## ステップ 2: 検証する
Amazon EKS Auto Mode が以下の Kubernetes スケジュール制約に従って、l40s `GPU` 搭載のインスタンスを必要とするワークロードとして `g6.2xlarge` ではなく `g6e.2xlarge` を開始したことを確認できます。
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
次のコマンドを実行して、コンテナのログを参照します。
```
kubectl logs nvidia-smi
```
サンプル出力:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
出力を見ると、コンテナは `NVIDIA` GPU 搭載のインスタンスで実行されていること、デバイスドライバーは Amazon EKS Auto Mode によって管理されるためインストールする必要がなかったことを確認できます。
## ステップ 3: クリーンアップする
作成されたすべてのオブジェクトを削除するには、`kubectl` を使用してサンプルのデプロイと NodePool を削除します。これでノードが終了します。
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePool 参照の例
### NVIDIA NodePool を作成する
NodePool で定義する内容は次のとおりです。
+ `g6e` と `g6` ファミリーのインスタンスを開始するのみ
+ 1 時間が過ぎても空のままであればノードを統合する
+ `consolodateAfter` が 1 時間というのは、ワークロードの急増に対応し、ノードのチャーンを抑制するのに十分な値です。`consolidateAfter` はワークロード要件に基づいて調整できます。
**NodePool を GPU インスタンスファミリーおよび統合で使用する例**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
`eks.amazonaws.com/instance-gpu-name` を設定するのではなく、`eks.amazonaws.com/instance-family` を使用してインスタンスファミリーを指定することもできます。この他にスケジュールのレビューに影響を与えるラベルとしてよく知られたものについては、「[EKS Auto Mode でサポートされているラベル](create-node-pool.md#auto-supported-labels)」を参照してください。
固有のストレージ要件がある場合は、NodePool で参照する [NodeClass](create-node-class.md) を独自に作成することで、ノードのエフェメラルストレージの `iops`、`size`、`throughput` を調整できます。[設定可能な NodeClass オプション](create-node-class.md)について確認してください。
**NodeClass 用にストレージを設定する例**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### AWS Trainium と AWS Inferentia の NodePool を定義する
以下の NodePool では、Inferentia と Trainium ファミリーのインスタンスを開始するだけという `eks.amazonaws.com/instance-category` 設定を定義しています。
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# EKS 自動モード設定を構成する
この章ではAmazon エラスティックKubernetesサービス (EKS) 自動モード クラスターの特定の特徴を設定する方法について説明します。EKS 自動モード はほとんどのインフラストラクチャコンポーネントを自動的に管理しますが、ワークロードの要件を満たすように特定の機能をカスタマイズできます。
このトピックで説明されている設定オプションを使用して、自動インフラストラクチャ管理の利点を維持しながら、ネットワーク設定、コンピューティングリソース、ロードバランシングの動作を変更できます。設定を変更する前に、以下のセクションで使用可能なオプションを確認して、ニーズに最適なアプローチを決定してください。
| どの機能を設定したいですか? | 設定オプション |
| --- | --- |
| **ノードネットワークとストレージ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [Amazon EKS のノードクラスを作成する](create-node-class.md) |
| **ノードコンピューティングリソース** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS 自動モードl 用のノードプールを作成する](create-node-pool.md) |
| **静的キャパシティノードプール** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode での静的キャパシティノードプール](auto-static-capacity.md) |
| **Application Load Balancer の設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [IngressClass を作成して Application Load Balancer を設定する](auto-configure-alb.md) |
| **Network Load Balancer の設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [サービス注釈を使用して Network Load Balancer を設定する](auto-configure-nlb.md) |
| **ストレージクラスの設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [ストレージクラスを作成する](create-storage-class.md) |
| **ODCR 使用の制御** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md) |
| **ノードの高度なセキュリティ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [ノードの高度なセキュリティ設定を構成する](auto-advanced-security.md) |
# Amazon EKS のノードクラスを作成する
Amazon EKS ノードクラスは、EKS Auto Mode マネージドノードの設定をきめ細かく制御できるテンプレートです。ノードクラスは、ネットワーク設定、ストレージ設定、リソースタグ付けなど、EKS クラスター内のノードのグループに適用されるインフラストラクチャレベルの設定を定義します。このトピックでは、特定の運用要件を満たすようにノードクラスを作成および設定する方法について説明します。
EKS Auto Mode がデフォルト設定を超えて EC2 インスタンスをプロビジョニングおよび設定する方法をカスタマイズする必要がある場合は、ノードクラスを作成すると、重要なインフラストラクチャパラメータを正確に制御できます。例えば、セキュリティを強化するためにプライベートサブネットの配置を指定したり、パフォーマンス重視のワークロード用にインスタンスエフェメラルストレージを設定したり、コスト配分のためにカスタムタグ付けを適用したりできます。
## ノードクラスを作成する
`NodeClass` を作成するには、次の手順に従います。
1. 自分のノードクラス設定で YAML ファイル (`nodeclass.yaml` など) を作成します
1. `kubectl` を使用してこの設定をクラスターに適用します
1. ノードプール設定でノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
`kubectl` がインストールおよび設定されている必要があります。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
### 基本的なノードクラスの例
ノードクラスの例を次に示します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
この NodeClass により、ノード上のエフェメラルストレージの量が増加します。
次を使用してこの設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
次に、ノードプール設定でノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## ノードクラスのアクセスエントリを作成する
カスタムノードクラスを作成する場合は、ノードがクラスターに参加できるように EKS アクセスエントリを作成する必要があります。組み込みのノードクラスとノードプールを使用すると、EKS によってアクセスエントリが自動的に作成されます。
アクセスエントリがどのように機能するかについては、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
EKS Auto Mode ノードクラスのアクセスエントリを作成するときは、`EC2` のアクセスエントリタイプを使用する必要があります。
### CLI でアクセスエントリを作成する
**EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:**
次の CLI コマンドを、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### CloudFormation でアクセスエントリを作成する
**EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:**
次の CloudFormation を、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
CloudFormation スタックのデプロイの詳細については、「[Getting started with CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)」を参照してください
## ノードクラスの指定
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 考慮事項
+ インスタンスのローカルストレージの容量を確認したい場合は、ノードを記述してエフェメラルストレージリソースを表示できます。
+ **ボリュームの暗号化** – インスタンスの読み取り専用ルートボリュームおよび読み取り/書き込みデータボリュームを暗号化するため、EKS は設定されたカスタム KMS キーを使用します。
+ **ノード IAM ロールの置換** - `NodeClass` に関連付けられているノード IAM ロールを変更する場合は、新しいアクセスエントリを作成する必要があります。EKS は、クラスターの作成時にノード IAM ロールのアクセスエントリを自動的に作成します。ノード IAM ロールには `AmazonEKSAutoNodePolicy` EKS アクセスポリシーが必要です。詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ **最大 Pod 密度** - EKS では、ノード上の Pod の最大数が 110 に制限されています。この制限は、既存の最大 Pod を計算した後に適用されます。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
+ **タグ** - Kubernetes から EC2 にタグを伝播させる場合は、追加の IAM アクセス許可を設定する必要があります。詳細については、「[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)」を参照してください。
+ **デフォルトのノードクラス** - カスタムノードクラスに `default` という名前を付けないでください。これは、EKS Auto Mode には、少なくとも 1 つの組み込み `NodePool` を有効にすると自動的にプロビジョニングされる `default` と呼ばれる `NodeClass` が含まれるためです。組み込み `NodePools` を有効にする方法については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ **複数のサブネットを使用した `subnetSelectorTerms` 動作** - `subnetSelectorTerms` 条件に一致するサブネットまたは ID で指定したサブネットが複数ある場合、EKS Auto Mode はサブネット全体に分散されたノードを作成します。
+ サブネットが異なるアベイラビリティーゾーン (AZ) にある場合、[Pod トポロジスプレッド制約](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints)や [Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) といった Kubernetes 機能を使用して、Pod とトラフィックをそれぞれゾーン間に分散できます。
+ *同じ AZ 内に* `subnetSelectorTerms` に一致するサブネットが複数ある場合、EKS Auto Mode はその AZ のサブネット全体に分散した各ノードに Pod を作成します。EKS Auto Mode は、同じ AZ 内の他のサブネットの各ノードにセカンダリネットワークインターフェイスを作成します。各サブネットで使用可能な IP アドレスの数に基づいて選択し、サブネットをより効率的に使用します。ただし、EKS Auto Mode が各 Pod に使用するサブネットを指定することはできません。特定のサブネットで Pod を実行する必要がある場合は、代わりに [ポッドのサブネットとセキュリティグループを分離する](#pod-subnet-selector) を使用してください。
## ポッドのサブネットとセキュリティグループを分離する
`podSubnetSelectorTerms` と `podSecurityGroupSelectorTerms` フィールドにより、ポッドがノードとは異なるサブネットとセキュリティグループを使用できるようになるため、高度なネットワーク設定が可能になります。両方のフィールドを一緒に指定する必要があります。この分離により、ネットワークトラフィックのルーティングとセキュリティポリシーの制御が強化されます。
**注記**
この機能は、EKS Auto Mode 以外のコンピューティング用の AWS VPC CNI で使用される[ポッドのセキュリティグループ](security-groups-for-pods.md) (SGPP) 機能とは異なります。SGPP は EKS Auto Mode ではサポートされていません。代わりに、`NodeClass` で `podSecurityGroupSelectorTerms` を使用して、ポッドトラフィックに個別のセキュリティグループを適用します。セキュリティグループは `NodeClass` レベルで適用されます。つまり、その `NodeClass` を使用するノード上のすべてのポッドは、同じのポッドセキュリティグループを共有します。
### 仕組み
`podSubnetSelectorTerms` と `podSecurityGroupSelectorTerms` を設定する場合:
1. ノードのプライマリ ENI は、`subnetSelectorTerms` および `securityGroupSelectorTerms` のサブネットとセキュリティグループを使用します。このインターフェイスには、ノード自身の IP アドレスのみが割り当てられます。
1. EKS Auto Mode では、`podSubnetSelectorTerms` に一致するサブネット内にセカンダリ ENI が作成され、`podSecurityGroupSelectorTerms` のセキュリティグループがそれらにアタッチされます。ポッド IP アドレスは、デフォルトで /28 プレフィックスを使用してこれらのセカンダリ ENI から割り当てられます。連続するプレフィックスブロックが使用できない場合、セカンダリ IP (/32) への自動フォールバックが行われます。`advancedNetworking` で `ipv4PrefixSize` が `"32"` に設定されている場合、セカンダリ IP のみが使用されます。
1. `podSecurityGroupSelectorTerms` で指定されたセキュリティグループは、VPC 内のポッドトラフィックに適用されます。VPC 外を送信先とするトラフィックの場合、ソースネットワークアドレス変換 (SNAT) はポッド IP をノード IP に変換するため、ポッドはノードのプライマリ ENI (およびそのセキュリティグループ) を使用します。この動作は、`NodeClass` の `snatPolicy` フィールドで変更できます。
### ユースケース
以下の場合に `podSubnetSelectorTerms` および `podSecurityGroupSelectorTerms` を使用します。
+ 異なるセキュリティグループを適用して、ノードとポッドのトラフィックを個別に制御する必要がある場合。
+ インフラストラクチャトラフィック (ノード間の通信) とアプリケーショントラフィック (ポッド間の通信) を分離する必要がある場合。
+ Pod サブネットとは異なるネットワーク設定をノードサブネットに適用する。
+ Pod トラフィックに影響を与えずに、ノードトラフィック専用のリバースプロキシまたはネットワークフィルタリングを設定する。`advancedNetworking` と `certificateBundles` を使用して、リバースプロキシと、プロキシの自己署名証明書またはプライベート証明書を定義する。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 個別のポッドサブネットとセキュリティグループに関する考慮事項
+ **セキュリティグループの範囲**: `podSecurityGroupSelectorTerms` のセキュリティグループはセカンダリ ENI にアタッチされ、VPC 内のポッドトラフィックに適用されます。SNAT が有効になっている場合 (デフォルトの `snatPolicy: Random`)、VPC から出るトラフィックはノードのプライマリ ENI IP アドレスに変換されるため、`securityGroupSelectorTerms` からのノードのセキュリティグループは代わりにそのトラフィックに適用されます。`snatPolicy: Disabled` を設定すると、ポッドはすべてのトラフィックに独自の IP アドレスを使用するため、ルーティンググループとセキュリティグループが適切に設定されていることを確認する必要があります。
+ **NodeClass レベルの粒度**: ポッドセキュリティグループは、`NodeClass` を使用してノードでスケジュールされたすべてのポッドに適用されます。異なるセキュリティグループを異なるワークロードに適用するには、個別の `NodeClass` リソースと `NodePool` リソースを作成し、テイント、許容範囲、またはノードセレクターを使用してワークロードを適切なノードにスケジュールします。
+ **ポッド密度の低下**: ノードのプライマリネットワークインターフェイスはノード IP 用に予約されており、ポッドに使用できないため、各ノードで実行できるポッドの数が少なくなります。
+ **サブネットセレクターの制限**: 標準 `subnetSelectorTerms` および `securityGroupSelectorTerms` 設定は、ポッドサブネットまたはセキュリティグループの選択には適用されません。
+ **ネットワーク計画**: ワークロード要件をサポートするために、ノードサブネットと Pod サブネットの両方に十分な IP アドレススペースを確保します。
+ **ルーティング設定**: Pod サブネットのルートテーブルとネットワークアクセスコントロールリスト (ACL) が、ノードと Pod サブネット間の通信用に正しく設定されていることを確認します。
+ **アベイラビリティーゾーン**: 複数の AZ にわたって Pod サブネットを作成したことを確認します。特定のポッドサブネットを使用している場合、そのサブネットはノードサブネット AZ と同じ AZ に存在している必要があります。
## ポッドのセカンダリ IP モード
`ipv4PrefixSize` フィールドは、ノードへのセカンダリ IP アドレスのみを割り当てることで、高度なネットワーク設定を有効にします。この機能はノードにプレフィックス (/28) を割り当てず、1 つのセカンダリ IP のみを MinimalIPTarget として維持します。
### ユースケース
次の場合に `ipv4PrefixSize` を使用します:
+ **IP 使用率を抑えたい**: 各ノードでウォームアップされる IP アドレスが 1 つだけになります。
+ **ポッドの解約率を低下させたい**: ポッドの作成速度がそれほど重要ではない場合に適しています。
+ **プレフィックスのフラグメント化を回避したい**: プレフィックスによるフラグメント化が大きな懸念事項、または Auto Mode 使用の阻害要因となっている場合に適しています。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### セカンダリ IP モードに関する考慮事項
+ **ポッド作成速度の低下**: 1 つのセカンダリ IP のみがウォームアップされるため、より多くのポッドが作成された場合、IPAM サービスによる IP のプロビジョニングにより多くの時間がかかります。
## IPv6 クラスター内の IPv6 ポッドからの IPv4 egress を無効にする。
デフォルトでは、`enableV4Egress` フィールドは `true` です。Auto Mode IPv6 クラスターの場合、この機能を無効にすることで、Auto Mode が IPv6 ポッドに対して egress 専用 IPv4 インターフェイスを作成しないようにすることができます。IPv4 egress インターフェイスはネットワークポリシーの適用対象外であるため、これは重要です。ネットワークポリシーは、ポッドのプライマリインターフェイス (eth0) にのみ適用されます。
### ユースケース
次の場合に `enableV4Egress` を使用します:
+ **IPv6 クラスターを使用する**: IPv4 egress トラフィックはデフォルトで許可されています。
+ **ネットワークポリシーを使用する**: 現在、EKS ネットワークポリシーはデュアルスタックをサポートしていません。`enableV4Egress` を無効にすると、ポッドトラフィックが IPv4 経由で予期せず出力されるのを防ぐことができます。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### enableV4Egress を無効にする際の考慮事項
+ **IPv6 クラスターのネットワークポリシー**: IPv6 クラスターでは、デフォルトで IPv4 トラフィックが許可されています。`enableV4Egress: false` に設定すると、IPv4 egress トラフィックがブロックされ、特にネットワークポリシーで使用する場合にセキュリティが強化されます。
# EKS 自動モードl 用のノードプールを作成する
Amazon EKS ノードプールにより、Kubernetes クラスター内のコンピューティングリソースを柔軟に管理できます。このトピックでは、クラスターのスケーリングとリソース使用率を最適化するノードプロビジョニングツールである Karpenter を使用してノードプールを作成および設定する方法を示します。Karpenter の ノードプール リソースを使用すると、インスタンスタイプ、アベイラビリティーゾーン、アーキテクチャ、キャパシティータイプなど、コンピューティングリソースの特定の要件を定義できます。
組み込みの `system` および `general-purpose` ノードプールは変更できません。これらは、有効または無効にすることのみができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
ノードプール の指定により、サポートされているさまざまなラベルと要件を通じて、EKS クラスターのコンピューティングリソースをきめ細かく制御できます。これには EC2 インスタンスカテゴリ、CPU 設定、アベイラビリティーゾーン、アーキテクチャ (ARM64/AMD64)、キャパシティタイプ (スポットまたはオンデマンド) を指定するためのオプションが含まれます。CPU とメモリの使用量のリソース制限を設定して、クラスターが必要な運用境界内に収まるようにすることもできます。
EKS 自動モードl は広く知られている Kubernetes ラベルを活用して、ノードの特性を識別する一貫性のある標準化された方法を提供します。アベイラビリティーゾーンの `topology.kubernetes.io/zone` や CPU アーキテクチャの `kubernetes.io/arch` といったこのラベルは確立された Kubernetes 規則に従います。さらに、EKS 固有のラベル (プレフィックスが `eks.amazonaws.com/`) により、インスタンスタイプ、CPU メーカー、GPU 機能、ネットワーク仕様などの AWS 固有の属性でこの機能が拡張されます。この標準化されたラベル付けシステムにより、既存の Kubernetes ツールとシームレスに統合できると同時に、緊密な AWS インフラストラクチャ統合が提供されます。
## ノードプール を作成する
Amazon EKS クラスターの ノードプール を作成するには次のステップに従います：
1. 必要な NodePool 設定で `nodepool.yaml` という名前の YAML ファイルを作成します。以下のサンプル設定を使用できます。
1. ノードプール をクラスターに適用します：
```
kubectl apply -f nodepool.yaml
```
1. ノードプール が正常に作成されたことを確認します：
```
kubectl get nodepools
```
1. (任意 ノードプール のステータスをモニタリングします：
```
kubectl describe nodepool default
```
ノードプール がクラスターに存在する有効な ノードクラス を参照していることを確認します。ノードクラス はコンピューティングリソースの AWS 固有の設定を定義します。詳細については「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## サンプル ノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## EKS Auto Mode でサポートされているラベル
EKS 自動モードl は以下の広く知られてるラベルをサポートしています。
**注記**
EKS 自動モードl は Karpenter とは異なるラベルを使用します。EC2 マネージドインスタンスに関連するラベルは`eks.amazonaws.com` で始まります。
| ラベル | 例 | 説明 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS リージョン |
| node.kubernetes.io/インスタンス型 | g4dn.8xlarge | AWS インスタンスタイプ |
| kubernetes.io/arch | amd64 | アーキテクチャはインスタンスの [GOARCH 値](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)によって定義されます |
| karpenter.sh/capacity-type | spot | キャパシティータイプには `spot`、`on-demand` などがあります |
| eks.amazonaws.com/instance-hypervisor | nitro | 特定のハイパーバイザーを使用するインスタンスタイプ |
| eks.amazonaws.com/compute-type | 自動 | EKS 自動モードl マネージドノードを識別します |
| eks.amazonaws.com/instance-encryption-in-transit-supported | 真 | 転送中の暗号化をサポートする (またはサポートしない) インスタンスタイプ |
| eks.amazonaws.com/instance-category | g | 同じカテゴリのインスタンスタイプ、通常は生成番号の前の文字列 |
| eks.amazonaws.com/instance-generation | 4 | インスタンスカテゴリ内のインスタンスタイプ生成番号 |
| eks.amazonaws.com/instance-family | g4dn | プロパティが類似していてリソース量が異なるインスタンスタイプ |
| eks.amazonaws.com/instance-size | 8xlarge | リソース量が類似していてプロパティが異なるインスタンスタイプ |
| eks.amazonaws.com/instance-cpu | 32 | インスタンスにおける CPU の数 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU メーカーの名前 |
| eks.amazonaws.com/instance-memory | 131072 | インスタンスのメモリのメビバイト数 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | インスタンスで使用できる EBS の[最大メガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)数 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | インスタンスで使用可能な[ベースラインメガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)数 |
| eks.amazonaws.com/instance-gpu-name | t4 | インスタンス上の GPU の名前 (使用可能な場合) |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU メーカーの名前 |
| eks.amazonaws.com/instance-gpu-count | 1 | インスタンスにおける GPU の数 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU のメモリのメビバイト数 |
| eks.amazonaws.com/instance-local-nvme | 900 | インスタンス上のローカル nvme ストレージのギビバイト数 |
**注記**
EKS Auto Mode は特定のインスタンスのみをサポートし、最小サイズ要件があります。詳細については、「[EKS Auto Mode でサポートされているインスタンスリファレンス](automode-learn-instances.md#auto-supported-instances)」を参照してください。
## EKS Auto Mode でサポートされていないラベル
EKS 自動モードl は次のラベルをサポートしていません。
+ EKS 自動モードは Linux のみをサポートしています
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 組み込みノードプールを無効にする
カスタムノードプールを作成する場合は、組み込みノードプールを無効にすることができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
## 組み込みノードプールがないクラスター
組み込みノードプールがないクラスターを作成できます。これは、組織がカスタマイズしたノードプールを作成している場合に役立ちます。
**注記**
組み込みノードプールなしでクラスターを作成すると、`default` NodeClass は自動的にプロビジョニングされません。カスタム NodeClass を作成する必要があります。詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
**概要：**
1. `nodePools` と `nodeRoleArn` の両方の値を空にして、EKS クラスターを作成します。
+ eksctl `autoModeConfig` の例:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
詳細については、[eksctl CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-eksctl.md)を参照してください。
1. ノードロール ARN を使用してカスタムノードクラスを作成します
+ 詳細については、[Amazon EKS のノードクラスを作成する](create-node-class.md)を参照してください。
1. カスタムノードクラスのアクセスエントリを作成します
+ 詳細については、[ノードクラスのアクセスエントリを作成する](create-node-class.md#auto-node-access-entry)を参照してください。
1. 前述のように、カスタムノードプールを作成します。
## 中断
NodePool を介してノードを中断するように、EKS Auto Mode を複数の方法で設定できます。`spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter`、または `spec.template.spec.expireAfter` を使用できます。NodePool の `spec.disruption.budgets` を使用して、EKS Auto Mode の中断をレート制限することもできます。中断される時間枠と同時ノード数を制御することもできます。この動作を設定する手順については、Karpenter ドキュメントの「[Disruption](https://karpenter.sh/docs/concepts/disruption/)」を参照してください。
ノードプールの中断は、次の目的で設定できます。
+ インスタンスの使用率が低いタイミングを特定し、ワークロードを統合する。
+ ノードプールの中断予算を作成して、ドリフト、空、統合が理由でのノードの終了をレート制限する。
デフォルトでは、EKS Auto Mode では以下が行われます。
+ 使用率が低いインスタンスを統合します。
+ 336 時間後にインスタンスを終了します。
+ ノードの 10% の単一の中断予算を設定します。
+ 新しい Auto Mode AMI がリリースされたときに、ドリフトを理由にノードを置き換えることを許可します。これは、およそ週に 1 回行われます。
## 終了猶予期間
EKS Auto NodePool で `terminationGracePeriod` を明示的に定義していない場合、関連付けた NodeClaim に 24 時間 (デフォルト) の終了猶予期間が自動的に適用されます。EKS Auto のカスタム NodePool 設定では `terminationGracePeriod` がデフォルトであることを確認できませんが、NodeClaim には、このデフォルト値が表示されます。猶予期間を NodePool で明示的に設定済みか、NodeClaim でデフォルト設定を行ったかに関係なく、この機能には一貫性があり、予測可能なノード終了動作がクラスター全体で維持されます。
# EKS Auto Mode での静的キャパシティノードプール
Amazon EKS Auto Mode は、静的キャパシティノードプールをサポートしており、ポッドの需要に関係なく決まった数のノードを維持します。静的キャパシティノードプールは、予測可能なキャパシティ、リザーブドインスタンス、または一貫したインフラストラクチャフットプリントの維持が求められる特定のコンプライアンス要件を必要とするワークロードに有用です。
ポッドスケジューリングの需要に基づいてスケールする動的ノードプールとは異なり、静的キャパシティノードプールでは設定したノードの数が維持されます。
## 静的キャパシティノードプールを設定する
静的キャパシティノードプールを作成するには、NodePool 仕様に `replicas` フィールドを設定します。`replicas` フィールドでは、ノードプールが維持するノードの正確な数を定義します。`replicas` の設定方法については、「[例](#static-capacity-examples)」を参照してください。
## 静的キャパシティノードプールに関する考慮事項
静的キャパシティノードプールには、重要な制約と動作がいくつかあります。
**設定に関する制約:**
+ **モードを切り替えることができない**: ノードプールで `replicas` を設定したら、以後削除することはできません。ノードプールでは、静的モードと動的モードとを切り替えることができません。
+ **リソースが制限されている**: 制限セクションでは、`limits.nodes` フィールドのみがサポートされています。CPU とメモリに関する制限は適用されません。
+ **重みフィールドがない**: ノードの選択が優先度に基づいていないため、静的キャパシティノードプールに `weight` フィールドを設定することができません。
**オペレーション動作:**
+ **統合対象外**: 静的キャパシティプールのノードは、統合対象と見なされません。
+ **スケールオペレーション**: スケールオペレーションでは、ノード中断の予算はバイパスされますが、PodDisruptionBudgets は引き続き考慮されます。
+ **ノードの置き換え**: 設定に基づいてドリフト (AMI アップデートなど) と有効期限が発生した場合は、ノードが置き換えられます。
## ベストプラクティス
**容量プランニング:**
+ `limits.nodes` を `replicas` よりも高い値に設定すると、ノードの置き換えオペレーション中に一時的にスケールできるようになります。
+ 制限を設定するときは、ノードドリフトや AMI アップデートに必要な最大キャパシティを考慮してください。
**インスタンス選択:**
+ リザーブドインスタンスがある場合や特定のハードウェア要件がある場合は、特定のインスタンスタイプを使用します。
+ 制限を過度に厳しくしてスケール中にインスタンスの可用性が制限されるような要件は避けてください。
**中断の管理:**
+ 可用性とメンテナンスオペレーションとのバランスが取れるように、適切な中断の予算を設定します。
+ 予算の割合を設定するときは、アプリケーションでノードの置き換えをどの程度許容するかを考慮してください。
**モニタリング:**
+ `status.nodes` フィールドを定期的にモニタリングして、必要なキャパシティが維持されていることを確認します。
+ 実際のノード数が目的のレプリカから逸脱した場合に備えてアラートを設定します。
**ゾーンの分散:**
+ 高可用性を実現するには、静的キャパシティをいくつかのアベイラビリティーゾーンに分散させます。
+ 複数のアベイラビリティーゾーンにまたがる静的キャパシティノードプールを作成すると、EKS Auto Mode により、指定されたゾーンにノードが分散しますが、その分散が均等であるとは限りません。
+ アベイラビリティーゾーン間に想定の範囲内で均等に分散させるには、静的キャパシティノードプールを個別にいくつか作成し、`topology.kubernetes.io/zone` 要件を使用してそれぞれを特定のアベイラビリティーゾーンに固定します。
+ 3 つのゾーンに 12 個のノードを均等に分散させる必要がある場合は、1 つのノードプールを作成して 3 つのゾーンに 12 個のレプリカを分散させるのではなく、3 つのノードプールを作成してそれぞれに 4 個のレプリカを分散させます。
## 静的キャパシティノードプールをスケールする
`kubectl scale` コマンドを使用すると、静的キャパシティノードプール内のレプリカの数を変更できます。
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
スケールダウンすると、EKS 自動モードはノードを適切に終了し、PodDisruptionBudgets を考慮のうえ、実行中のポッドを残りのノードに再スケジュールできるようにします。
## 静的キャパシティノードプールをモニタリングする
以下のコマンドを使用すると、静的キャパシティノードプールをモニタリングできます。
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` フィールドは、ノードプールで管理されているノードの現在の数を示し、通常の条件下で必要になる `replicas` の数と一致する必要があります。
## トラブルシューティング
**ノードが目的のレプリカに到達しない:**
+ `limits.nodes` の値が十分かどうかを確認します。
+ 要件がインスタンス選択を過度に制限していないことを確認します。
+ 使用しているインスタンスタイプとリージョンの AWS サービスクォータを確認します。
**ノードの置き換えに時間がかかりすぎる:**
+ 同時により多くの置き換えができるように中断予算を調整します。
+ PodDisruptionBudgets がノードの終了を妨げていないかどうかを確認します。
**ノードが予期せずに終了する:**
+ `expireAfter` と `terminationGracePeriod` の設定を確認します。
+ 手動によるノードの終了や AWS メンテナンスイベントを確認します。
## 例
### 基本的な静的キャパシティノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 特定のインスタンスタイプの静的キャパシティ
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### マルチゾーンの静的キャパシティノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### キャパシティ予約による静的キャパシティ
以下の例は、EC2 キャパシティ予約で静的キャパシティノードプールを使用する方法を示しています。EKS Auto Mode での EC2 キャパシティ予約の使用の詳細については、「[EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md)」を参照してください。
`capacityReservationSelectorTerms` を定義する `NodeClass`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
上記の `NodeClass` を参照し、`karpenter.sh/capacity-type: reserved` を使用する `NodePool`
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# IngressClass を作成して Application Load Balancer を設定する
EKS Auto Mode は、インターネットへのクラスターアプリケーションの公開など、ロードバランシングのルーチンタスクを自動化します。
AWS では、Application Load Balancer (ALB) を使用して HTTP および HTTPS トラフィックを処理することを推奨しています。Application Load Balancer は、リクエストの内容に基づいてリクエストをルーティングできます。Application Load Balancer の詳細については、「[What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)」を参照してください。
EKS Auto Mode は、Application Load Balancer (ALB) の作成と設定を行います。例えば、`Ingress` Kubernetes オブジェクトを作成すると EKS Auto Mode によってロードバランサーが作成され、クラスターワークロードにトラフィックをルーティングするように設定されます。
**概要**:
1. インターネットに公開するワークロードを作成します。
1. SSL/TLS や VPC サブネットに使用する証明書などの AWS 固有の設定値を指定して、`IngressClassParams` リソースを作成します。
1. `IngressClass` リソースを作成し、EKS Auto Mode がリソースのコントローラーになるように指定します。
1. HTTP パスおよびポートをクラスターワークロードに関連付ける `Ingress` リソースを作成します。
EKS Auto Mode は、`IngressClassParams` リソースで指定されたロードバランサー設定を使用して、`Ingress` リソースで指定されたワークロードをポイントする Application Load Balancer を作成します。
## 前提条件
+ EKS Auto Mode が Amazon EKS クラスターで有効になっている
+ kubectl がクラスターに接続するように設定されている
+ `kubectl apply -f ` を使用して、以下のサンプル設定 YAML ファイルをクラスターに適用できます。
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
## ステップ 1: ワークロードを作成する
まず、インターネットに公開するワークロードを作成します。これは、デプロイやサービスなど、HTTP トラフィックを処理する任意の Kubernetes リソースです。
この例では、`service-2048` というシンプルな HTTP サービスを使用して、ポート `80` をリッスンします。次の `2048-deployment-service.yaml` というマニフェストを適用して、このサービスとそのデプロイを作成します。
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
設定をクラスターに適用します。
```
kubectl apply -f 2048-deployment-service.yaml
```
前記のリソースは、デフォルトの名前空間に作成されます。次のコマンドを実行して、これを検証できます。
```
kubectl get all -n default
```
## ステップ 2: IngressClassParams を作成する
`IngressClassParams` オブジェクトを作成して、Application Load Balancer に対する AWS 固有の設定オプションを指定します。この例では、`alb` という名前の `IngressClassParams` リソース (次のステップで使用する) を作成し、ロードバランサースキームを `internet-facing` として `alb-ingressclassparams.yaml` というファイルで指定します。
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
設定をクラスターに適用します。
```
kubectl apply -f alb-ingressclassparams.yaml
```
## ステップ 3: IngressClass を作成する
`alb-ingressclass.yaml` という名前のファイル内に、`IngressClassParams` リソースで設定された AWS 固有の設定値を参照する `IngressClass` を作成します。`IngressClass` の名前をメモしてください。この例では、`IngressClass` と `IngressClassParams` の両方が `alb` という名前になっています。
`is-default-class` 注釈を使用して、`Ingress` リソースがこのクラスをデフォルトで使用するかどうかを制御します。
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
設定オプションの詳細については、「[IngressClassParams リファレンス](#ingress-reference)」を参照してください。
設定をクラスターに適用します。
```
kubectl apply -f alb-ingressclass.yaml
```
## ステップ 4: Ingress を作成する
`alb-ingress.yaml` という名前のファイルに `Ingress` リソースを作成します。このリソースの目的は、Application Load Balancer のパスとポートをクラスター内のワークロードに関連付けることです。この例では、ポート 80 で `service-2048` という名前のサービスにトラフィックをルーティングする `2048-ingress` という名前の `Ingress` リソースを作成します。
このリソースの構成方法の詳細については、Kubernetes ドキュメントの「[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)」を参照してください。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
設定をクラスターに適用します。
```
kubectl apply -f alb-ingress.yaml
```
## ステップ 5: ステータスを確認する
`kubectl` を使用して、`Ingress` のステータスを取得します。ロードバランサーが利用できるようになるまで数分かかる場合があります。
前のステップで設定した `Ingress` リソースの名前を使用します。例えば、次のようになります。
```
kubectl get ingress 2048-ingress
```
リソースの準備ができたら、ロードバランサーのドメイン名を取得します。
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
ウェブブラウザでサービスを表示するには、`Ingress` レスキューで指定したポートとパスを確認します。
## ステップ 6: クリーンアップ
ロードバランサーをクリーンアップするには、次のコマンドを使用します。
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode が、AWS アカウント内の関連するロードバランサーを自動的に削除します。
## IngressClassParams リファレンス
次の表は、一般的に使用される設定オプションのクイックリファレンスです。
| フィールド | 説明 | 値の例 |
| --- | --- | --- |
| `scheme` | ALB が内部向けかインターネット向けかを定義します | `internet-facing` |
| `namespaceSelector` | この IngressClass を使用できる名前空間を制限します | `environment: prod` |
| `group.name` | 1 つの ALB を共有する複数の Ingress をグループ化します | `retail-apps` |
| `ipAddressType` | ALB の IP アドレスタイプを設定します | `dualstack` |
| `subnets.ids` | ALB デプロイにおけるサブネット ID のリスト | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | ALB のサブネットを選択するタグフィルター | `Environment: prod` |
| `certificateARNs` | 使用する SSL 証明書の ARN | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | AWS リソースのカスタムタグ | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | ロードバランサー固有の属性 | `idle_timeout.timeout_seconds: 60` |
## 考慮事項
+ EKS Auto Mode でロードバランサーを設定するのに、IngressClass で注釈を使用することはできません。IngressClass の設定は、IngressClassParams を介して行う必要があります。ただし、個々の Ingress リソースで注釈を使用すると、ロードバランサーの動作を設定できます (`alb.ingress.kubernetes.io/security-group-prefix-lists`や `alb.ingress.kubernetes.io/conditions.*` など)。
+ EKS Auto Mode では、[ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html) を設定できません。
+ クラスター IAM ロールを更新して、Kubernetes から AWS ロードバランサーリソースへのタグの伝播を有効にする必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ リソースを EKS Auto Mode またはセルフマネージド AWS Load Balancer Controller に関連付ける方法については、「[移行のリファレンス](migrate-auto.md#migration-reference)」を参照してください。
+ ロードバランサーの問題の修正方法については、「[EKS 自動モードl のトラブルシューティング](auto-troubleshoot.md)」を参照してください。
+ EKS Auto Mode のロードバランシング機能の使用に関する考慮事項については、「[負荷分散](auto-networking.md#auto-lb-consider)」を参照してください。
次の表は、EKS Auto Mode の IngressClassParams、Ingress 注釈、および TargetGroupBinding 設定の変更の詳細な比較を示しています。これらの表は、API バージョンの変更、廃止された機能、更新されたパラメータ名など、EKS Auto Mode のロードバランシング機能とオープンソースのロードバランサーコントローラーの主な違いを強調しています。
### IngressClassParams
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.certificateArn` | `spec.certificateARNs` | 複数の証明書 ARN のサポート |
| `spec.subnets.tags` | `spec.subnets.matchTags` | サブネット一致スキーマの変更 |
| `spec.listeners.listenerAttributes` | サポートされていません | EKS Auto Mode で未サポート |
### Ingress 注釈
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | サポートされていません | Ingress オブジェクトで `spec.ingressClassName` を使用 |
| `alb.ingress.kubernetes.io/group.name` | サポートされていません | IngressClass でのみグループを指定 |
| `alb.ingress.kubernetes.io/waf-acl-id` | サポートされていません | 代わりに WAF v2 を使用 |
| `alb.ingress.kubernetes.io/web-acl-id` | サポートされていません | 代わりに WAF v2 を使用 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | サポートされていません | Shield 統合が無効 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | サポートされていません | 現時点で OIDC 認証タイプはサポートされていません |
### TargetGroupBinding
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.targetType` が任意 | `spec.targetType` が必須 | 明示的なターゲットタイプの指定 |
| `spec.networking.ingress.from` | サポートされていません | セキュリティグループなしでは NLB がサポートされなくなりました |
カスタム TargetGroupBinding 機能を使用するには、ターゲットグループにクラスター名と共に eks:eks-cluster-name タグを付けて、必要な IAM アクセス許可をコントローラーに付与する必要があります。TargetGroupBinding リソースまたはクラスターを削除すると、コントローラーがターゲットグループを削除することに注意してください。
# サービス注釈を使用して Network Load Balancer を設定する
Kubernetes サービス注釈を使用して Amazon EKS で Network Load Balancer (NLB) を設定する方法について説明します。このトピックでは、インターネットアクセシビリティ、ヘルスチェック、SSL/TLS ターミネーション、IP ターゲティングモードなど、NLB の動作をカスタマイズするための EKS Auto Mode でサポートされている注釈について説明します。
EKS Auto Mode でタイプ `LoadBalancer` の Kubernetes サービスを作成すると、EKS は指定した注釈に基づいて AWS Network Load Balancer を自動的にプロビジョニングして設定します。この宣言型アプローチにより、Kubernetes マニフェストを通じてロードバランサーの設定を直接管理し、Infrastructure as Code プラクティスを維持できます。
EKS Auto Mode は、デフォルトでタイプ LoadBalancer のサービスすべてに対する Network Load Balancer プロビジョニングを処理します。追加のコントローラーのインストールや設定は必要ありません。`loadBalancerClass: eks.amazonaws.com/nlb` の仕様は、クラスターのデフォルトとして自動的に設定され、既存の Kubernetes ワークロードとの互換性を維持しながらデプロイプロセスが合理化されます。
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
## サンプルサービス
Kubernetes `Service` リソースの詳細については、「[Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/services-networking/service/)」を参照してください。
以下のサンプル `Service` リソースを確認してください。
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 一般的に使用される注釈
次の表に、EKS Auto Mode でサポートされている、一般的に使用される注釈を示します。EKS Auto Mode は、すべての注釈をサポートしているわけではないことに注意してください。
**ヒント**
以下の注釈はすべて、`service.beta.kubernetes.io/` というプレフィックスを付ける必要があります
| フィールド | 説明 | 例 |
| --- | --- | --- |
| `aws-load-balancer-type` | ロードバランサーのタイプを指定します。新しいデプロイには `external` を使用します。 | `external` |
| `aws-load-balancer-nlb-target-type` | トラフィックをノードインスタンスにルーティングするか、ポッド IP に直接ルーティングするかを指定します。標準デプロイでは `instance` を、直接ポッドルーティングでは `ip` を使用します。 | `instance` |
| `aws-load-balancer-scheme` | ロードバランサーが内部向けかインターネット向けかを指定します。 | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | ターゲットグループのヘルスチェックプロトコル。一般的なオプションは `TCP` (デフォルト) または `HTTP` です。 | `HTTP` |
| `aws-load-balancer-healthcheck-path` | HTTP/HTTPS プロトコルを使用する場合のヘルスチェックの HTTP パス。 | `/healthz` |
| `aws-load-balancer-healthcheck-port` | ヘルスチェックに使用されるポート。特定のポート番号または `traffic-port` を指定できます。 | `traffic-port` |
| `aws-load-balancer-subnets` | ロードバランサーを作成するサブネットを指定します。サブネット ID またはサブネット名を使用できます。 | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | HTTPS/TLS 用の AWS Certificate Manager からの SSL 証明書の ARN。 | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | SSL/TLS を使用するポートを指定します。 | `443, 8443` |
| `load-balancer-source-ranges` | ロードバランサーへのアクセスが許可されている CIDR 範囲。 | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | ロードバランサーおよび関連リソースに適用する追加の AWS タグ。 | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | ロードバランサーが使用するのが IPv4 かデュアルスタック (IPv4 \$1 IPv6) かを指定します。 | `ipv4`-または-`dualstack` |
## 考慮事項
+ クラスター IAM ロールを更新して、Kubernetes から AWS ロードバランサーリソースへのタグの伝播を有効にする必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ リソースを EKS Auto Mode またはセルフマネージド AWS Load Balancer Controller に関連付ける方法については、「[移行のリファレンス](migrate-auto.md#migration-reference)」を参照してください。
+ ロードバランサーの問題の修正方法については、「[EKS 自動モードl のトラブルシューティング](auto-troubleshoot.md)」を参照してください。
+ EKS Auto Mode のロードバランシング機能の使用に関する考慮事項については、「[負荷分散](auto-networking.md#auto-lb-consider)」を参照してください。
ロードバランシングのために EKS Auto Mode に移行する場合は、サービス注釈とリソース設定にいくつかの変更が必要です。次の表は、サポートされていないオプションや推奨される代替案など、新旧の実装の主な違いをまとめたものです。
### サービス注釈
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | サポートされていません | Service で `spec.loadBalancerSourceRanges` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-type` | サポートされていません | Service で `spec.loadBalancerClass` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | サポートされていません | `service.beta.kubernetes.io/aws-load-balancer-scheme` を使用する |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` を使用 |
| 各種ロードバランサー属性 | サポートされていません | `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用する |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
非推奨のロードバランサー属性注釈から移行するには、これらの設定を `service.beta.kubernetes.io/aws-load-balancer-attributes` 注釈に統合します。この注釈は、各種ロードバランサー属性のキーと値のペアのカンマ区切りリストを受け入れます。例えば、アクセスログ記録とクロスゾーンロードバランシングを指定するには、次の形式を使用します。
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
この統合形式により、より優れた一貫性と柔軟性で、必要な個々の注釈の数を減らしつつロードバランサー属性を設定することができます。既存の Service 設定を確認し、この統合形式を使用するように更新してください。
### TargetGroupBinding
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.targetType` が任意 | `spec.targetType` が必須 | 明示的なターゲットタイプの指定 |
| `spec.networking.ingress.from` | サポートされていません | セキュリティグループなしでは NLB がサポートされなくなりました |
注意: カスタム TargetGroupBinding 機能を使用するには、ターゲットグループにクラスター名と共に `eks:eks-cluster-name` タグを付けて、必要な IAM アクセス許可をコントローラーに付与する必要があります。TargetGroupBinding リソースまたはクラスターを削除すると、コントローラーがターゲットグループを削除することに注意してください。
# ストレージクラスを作成する
Amazon EKS Auto Mode の `StorageClass` は、アプリケーションが永続的ストレージをリクエストしたときの Amazon EBS ボリュームを自動的にプロビジョニングする方法を定義します。このページでは、Amazon EKS Auto Mode で動作する `StorageClass` を作成して設定し、EBS ボリュームをプロビジョニングする方法について説明します。
`StorageClass` を設定することで、ボリュームタイプ、暗号化、IOPS、その他のストレージパラメータなど、EBS ボリュームのデフォルト設定を指定できます。暗号化管理に AWS KMS キーを使用するように `StorageClass` を設定することもできます。
EKS Auto Mode では、お客様用の `StorageClass` は作成されません。EKS Auto Mode のストレージ機能を使用するには、`ebs.csi.eks.amazonaws.com` を参照する `StorageClass` を作成する必要があります。
まず、`storage-class.yaml` という名前のファイルを作成します。
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
次に、ストレージクラスをクラスターに適用します。
```
kubectl apply -f storage-class.yaml
```
**主要コンポーネント:**
+ `provisioner: ebs.csi.eks.amazonaws.com` - EKS Auto Mode を使用する
+ `allowedTopologies` - `matchLabelExpressions` を `eks.amazonaws.com/compute-type:auto` に一致するように指定した場合、自動モードを使用してポッドに必要なボリュームを自動的にプロビジョニングするようにすれば、そのポッドは自動以外のノードにスケジュールされなくなります。
+ `volumeBindingMode: WaitForFirstConsumer` - ポッドが必要とするまでボリュームの作成を遅らせる
+ `type: gp3` - EBS ボリュームタイプを指定する
+ `encrypted: "true"` – EBS は、`StorageClass` を使用して作成されたすべてのボリュームを暗号化します。EBS はデフォルトの `aws/ebs` キーエイリアスを使用します。詳細については、「Amazon EBS ユーザーガイド」の「[How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)」を参照してください。この値は省略可能ですが、推奨です。
+ `storageclass.kubernetes.io/is-default-class: "true"` – 永続ボリュームのクレームで別のボリュームクラスを指定しない限り、Kubernetes はデフォルトでこのストレージクラスを使用します。この値はオプションです。別のストレージコントローラーから移行する場合は、この値を設定するときに注意してください。
## セルフマネージド KMS キーを使用して EBS ボリュームを暗号化する
セルフマネージド KMS キーを使用して EKS Auto Mode によって自動化される EBS ボリュームを暗号化するには、以下を実行する必要があります。
1. セルフマネージド KMS キーを作成します。
+ 詳細については、「KMS ユーザーガイド」の「[Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)」または「[How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)」を参照してください。
1. KMS キーへのアクセスを許可する新しいポリシーを作成します。
+ 以下のサンプル IAM ポリシーを使用してポリシーを作成します。新しいセルフマネージド KMS キーの ARN を挿入します。詳細については、「AWS IAM ユーザーガイド」の「[ロールの作成とポリシーのアタッチ (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)」を参照してください。
1. ポリシーを EKS クラスターロールにアタッチします。
+ AWS コンソールを使用して、EKS クラスターロールの ARN を見つけます。ロール情報は **[概要]** セクションに表示されます。詳細については、「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
1. `parameters.kmsKeyId` フィールドの KMS キー ID を参照するように `StorageClass` を更新します。
### サンプルセルフマネージド KMS IAM ポリシー
以下のポリシーで次の値を更新します。
+ `` – AWS アカウント ID (`111122223333` など)
+ `` – クラスターの AWS リージョン (`us-west-2` など)
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### サンプルセルフマネージド KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` パラメータリファレンス
Kubernetes `StorageClass` リソースの一般的な情報については、Kubernetes ドキュメントの「[ストレージクラス](https://kubernetes.io/docs/concepts/storage/storage-classes/)」を参照してください。
`StorageClass` リソースの `parameters` セクションは AWS に固有です。次の表を使用して使用可能なオプションを確認してください。
| パラメータ | 値 | デフォルト | 説明 |
| --- | --- | --- | --- |
| 「csi.storage.k8s.io/fstype」 | xfs、ext2、ext3、ext4 | ext4 | ボリュームの作成時にフォーマットされるファイルシステムタイプ。このパラメータは大文字と小文字が区別されます。 |
| 「type」 | io1、io2、gp2、gp3、sc1、st1、standard、sbp1、sbg1 | gp3 | EBS ボリュームタイプ。 |
| 「iopsPerGB」 | | | GiB ごとの 1 秒あたりの I/O オペレーション回数秒。IO1、IO2、GP3 ボリュームで指定できます。 |
| 「allowAutoIOPSPerGBIncrease」 | true、false | false | `"true"` であると、`iopsPerGB * ` が小さすぎて AWS でサポートされている IOPS 範囲に収まらない場合に、CSI ドライバーによりボリュームの IOPS が増加します。この結果、ユーザーが指定する PVC キャパシティーや `iopsPerGB` 値が小さすぎる場合でも、動的プロビジョニングが常に成功します。一方、このようなボリュームの IOPS は `iopsPerGB` でリクエストされた値よりも高くなるため、追加コストが発生する可能性があります。 |
| 「iops」 | | | 1 秒あたりの I/O オペレーション回数。IO1、IO2、GP3 ボリュームで指定できます。 |
| 「throughput」 | | 125 | 単位 MiB/秒でのスループット。gp3 ボリュームタイプが指定されている場合にのみ有効です。 |
| 「encrypted」 | true、false | false | ボリュームを暗号化するかどうか。有効な値は「true」または「false」です。 |
| 「blockExpress」 | true、false | false | io2 Block Express ボリュームの作成を有効にします。 |
| 「kmsKeyId」 | | | ボリュームの暗号化時に使用するキーの完全な ARN。指定されていない場合、AWS ではボリュームが存在するリージョンのデフォルトの KMS キーが使用されます。これは、変更されていない場合、`/aws/ebs` という名前の自動生成キーになります。 |
| 「blockSize」 | | | 基盤となるファイルシステムをフォーマットするときに使用するブロックサイズ。Linux ノードと fstype `ext2`、`ext3`、`ext4` または `xfs` でのみサポートされます。 |
| 「inodeSize」 | | | 基盤となるファイルシステムをフォーマットするときに使用する inode サイズ。Linux ノードと fstype `ext2`、`ext3`、`ext4` または `xfs` でのみサポートされます。 |
| 「bytesPerInode」 | | | 基盤となるファイルシステムをフォーマットするときに使用する `bytes-per-inode`。Linux ノードと fstype `ext2`、`ext3`、`ext4` でのみサポートされます。 |
| 「numberOfInodes」 | | | 基盤となるファイルシステムをフォーマットするときに使用する `number-of-inodes`。Linux ノードと fstype `ext2`、`ext3`、`ext4` でのみサポートされます。 |
| 「ext4BigAlloc」 | true、false | false | `bigalloc` フォーマットオプションを有効にして、クラスター化されたブロック割り当てを使用するように `ext4` ファイルシステムを変更します。警告: ノードの Linux カーネルでは `bigalloc` が完全にはサポートされない場合があります。 |
| 「ext4ClusterSize」 | | | `bigalloc` 機能が有効になっている場合に、`ext4` ファイルシステムをフォーマットするときに使用するクラスターサイズ。注: `ext4BigAlloc` パラメータを true に設定する必要があります。 |
詳細については、GitHub の「[AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)」を参照してください。
## 考慮事項
**注記**
EKS オートモードノードの EKS オートモード StorageClasses に依存するワークロードのみをデプロイできます。ノードのタイプが混在するクラスターがある場合は、ワークロードを EKS オートモードノードでのみ実行するように設定する必要があります。詳細については、「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。
EKS Auto Mode のブロックストレージ機能は、EBS CSI ドライバーとは異なります。
+ 静的プロビジョニング
+ EKS Auto Mode で外部作成の EBS ボリュームを使用する場合は、キー `eks:eks-cluster-name` とクラスター名の値を含む AWS タグを手動で追加する必要があります。
+ ノード起動テイント
+ ノード起動テイント機能を使用して、ストレージ機能の準備が整う前にポッドのスケジューリングを防ぐことはできません
+ 動的にプロビジョニングされたボリュームのカスタムタグ
+ 追加タグ CLI フラグを使用して、動的にプロビジョニングされた EBS ボリュームにカスタムタグを設定することはできません
+ `StorageClass` タグ付けを使用してカスタムタグを追加できます。EKS Auto Mode は、関連付けられた AWS リソースにタグを追加します。カスタムタグのクラスター IAM ロールを更新する必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ EBS 詳細パフォーマンスメトリクス
+ EBS 詳細パフォーマンスの Prometheus メトリクスにアクセスできません
## CSI スナップショットコントローラーアドオンをインストールする
EKS Auto Mode は、CSI スナップショットコントローラー Amazon EKS アドオンと互換性があります。
AWS では、組み込み `system` ノードプールで実行するようにこのアドオンを設定することをお勧めします。
詳細については、以下を参照してください。
+ [ハードウェア専有インスタンスで重要なアドオンを実行する](critical-workload.md)
+ [組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)
+ [CSI ボリュームのためにスナップショット機能を有効にする](csi-snapshot-controller.md)
### スナップショットコントローラーをシステムノードプールにインストールするには
1. AWS コンソールで EKS クラスターを開きます
1. **[アドオン]** タブから、**[アドオンをさらに追加]** を選択します
1. **[CSI スナップショットコントローラー]**、**[次へ]** の順に選択します
1. **[選択したアドオン設定を構成する]** ページで、**[オプションの設定]** を選択して **[アドオン設定スキーマ]** を表示します
1. 次の yaml を挿入して、スナップショットコントローラーを `system` ノードプールに関連付けます。スナップショットコントローラーには、`CriticalAddonsOnly` テイントの許容が含まれています。
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. **[次へ]** を選択します
1. アドオン設定を確認し、**[作成]** を選択します
# EKS 自動モードl を無効にする
既存の EKS クラスターで EKS 自動モードl を無効にすることができます。これは破壊的な操作です。
+ EKS はEKS 自動モードl によって運用されているすべての EC2 インスタンスを終了します。
+ EKS はEKS 自動モードl によって運用されているすべてのロードバランサーを削除してください。
+ EKS はEKS 自動モードl によってプロビジョニングされた EBS ボリュームを削除**しません**。
EKS Auto Mode は作成するリソースを完全に管理するように設計されています。手動で操作すると、EKS Auto Mode が無効になっているときにそれらのリソースを完全にクリーンアップできなくなる可能性があります。例えば、外部のセキュリティグループルールからマネージドセキュリティグループを参照し、クラスターの EKS Auto Mode を無効にする前にその参照を削除するのを忘れた場合、マネージドセキュリティグループはリークします (削除されません)。以下のステップではリークされたセキュリティグループが発生した場合に削除する方法について説明します。
## EKS 自動モードl を無効にする (AWS コンソール)
1. AWS マネジメントコンソールでクラスターの概要ページを開きます。
1. **[EKS 自動モードl]** で **[管理]** を選択してください
1. **EKS 自動モードl** を `off` に切り替えます。
このプロセスの最後にマネージドセキュリティグループが削除されない場合は、「[セキュリティグループを削除する](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)」の説明を参照して手動で削除できます。
## EKS 自動モードl を無効にする (AWS CLI)
既存のクラスターで EKS 自動モードl を無効にするには次のコマンドを使用します。
`aws` CLI をインストールし、EKS クラスターを管理するのに十分なアクセス許可が付与された状態でログインする必要があります。詳細については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
**注記**
コンピューティング、ブロックストレージ、およびロードバランシング機能はすべて、同じリクエストで有効または無効にする必要があります。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
EKS Auto Mode を無効にした後、リークした EKS Auto Mode セキュリティグループ の削除に失敗したかどうかは次のように確認できます。
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
セキュリティグループを削除するには：
```
aws ec2 delete-security-group --group-name=
```
# EKS Auto Mode クラスターの Kubernetes バージョンを更新する
このトピックでは、Auto Mode クラスターの Kubernetes バージョンを更新する方法について説明します。Auto Mode は、ポッド中断の予算を通じてワークロードの可用性を維持しながら、ノード交換によるコントロールプレーンの更新を調整することで、バージョン更新プロセスを簡素化します。
Auto Mode クラスターのアップグレード時に、従来手動更新が必要だった多くのコンポーネントがサービスの一部として管理されるようになりました。アップグレードプロセスの自動化された側面とユーザー担当部分を理解することで、クラスターのバージョンをスムーズに移行できます。
## EKS Auto Mode による更新についての説明
コントロールプレーンのアップグレードを開始したら、EKS Auto Mode によってクラスター内のノードがアップグレードされます。ノードの有効期限が切れると、EKS Auto Mode によって新しいノードに置き換えられます。新しいノードには、対応する新しい Kubernetes バージョンがあります。EKS Auto Mode は、ノードのアップグレード時にポッド中断の予算を監視します。
さらに、次のようなコンポーネントは更新する必要がありません。
+ Amazon VPC CNI
+ AWS ロードバランサーコントローラー
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI ドライバー
EKS Auto Mode は、これらのコンポーネントをサービス機能に置き換えます。
以下の更新は引き続きユーザーが行います。
+ クラスターにデプロイされたアプリケーションとワークロード
+ セルフマネージドアドオンおよびコントローラー
+ Amazon EKS アドオン
+ 「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」ではその方法を説明しています。
「[クラスターのアップグレードのベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)」を参照してください
## クラスターの更新を開始する
クラスターの更新を開始するには、「[既存のクラスターを新しい Kubernetes バージョンに更新する](update-cluster.md)」を参照してください。
# 組み込み NodePool を有効または無効にする
EKS Auto Mode には 2 つの組み込み NodePool があります。これらの NodePool を有効または無効にするには、AWS コンソール、CLI、または API を使用します。
## 組み込み NodePool リファレンス
+ `system`
+ この NodePool には `CriticalAddonsOnly` テイントがあります。CoreDNS など多くの EKS アドオンで、このテイントが許容されています。このシステムノードプールを使用して、クラスターに不可欠なアプリケーションを分離します。
+ `amd64` と `arm64` アーキテクチャの両方をサポートします。
+ `general-purpose`
+ この NodePool は、クラスター内の汎用ワークロード用のノードの起動をサポートします。
+ `amd64` アーキテクチャのみを使用します。
両方の組み込み NodePool:
+ デフォルトの EKS NodeClass を使用する
+ オンデマンド EC2 容量のみを使用する
+ C、M、および R EC2 インスタンスファミリーを使用する
+ 世代 5 以降の EC2 インスタンスが必要になる
**注記**
EKS が「デフォルト」の NodeClass をプロビジョニングするには、少なくとも 1 つの組み込み NodePool を有効にする必要があります。すべての組み込み NodePool を無効にする場合は、カスタム NodeClass を作成し、それを使用するように NodePool を設定する必要があります。NodeClass の詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## 手順
### 前提条件
+ AWS コマンドラインインターフェイス (AWS CLI) の最新バージョンがデバイスにインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version`」を参照してください。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)」を参照してください。
+ 十分な IAM アクセス許可を使用して CLI にログインし、IAM ポリシー、IAM ロール、EKS クラスターなどの AWS リソースを作成します。
### AWS CLI で有効にする
次のコマンドを使用して、両方の組み込み NodePool を有効にします。
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
コマンドを変更して、NodePool を選択的に有効にすることができます。
### AWS CLI で無効にする
次のコマンドを使用して、両方の組み込み NodePool を無効にします。
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する
EKS Auto Mode を使用して EKS クラスターでワークロードを実行する場合、特定のワークロードが EKS Auto Mode ノードで実行されるか、他のコンピューティングタイプで実行されるかを制御することが必要になる場合があります。このトピックでは、ノードセレクターとアフィニティルールを使用して、ワークロードを目的のコンピューティングインフラストラクチャでスケジュールする方法について説明します。
このトピックの例では、`eks.amazonaws.com/compute-type` ラベルを使用して EKS Auto Mode ノードへのワークロードのデプロイを要求または禁止する方法を示します。これは、EKS Auto Mode と、セルフマネージド Karpenter プロビジョナーや EKS マネージドノードグループなどの他のコンピューティングタイプの両方を実行している混合モードクラスターで特に便利です。
EKS Auto Mode ノードでは、ラベル `eks.amazonaws.com/compute-type` の値が `auto` に設定されています。このラベルを使用して、ワークロードが EKS Auto Mode によって管理されるノードにデプロイされるかどうかを制御できます。
## ワークロードを EKS Auto Mode ノードにデプロイするように要求する
**注記**
この `nodeSelector` 値は EKS Auto Mode では必須ではありません。この `nodeSelector` 値は、クラスターを混合モードで実行している場合にのみ関連し、ノードタイプは EKS Auto Mode で管理されません。例えば、EKS マネージドノードグループを使用してクラスターに静的コンピューティング容量をデプロイし、EKS Auto Mode で動的計算能力を管理しているとします。
この `nodeSelector` をデプロイまたは他のワークロードに追加して、Kubernetes が EKS Auto Mode ノードにスケジュールするように要求できます。
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## ワークロードを EKS Auto Mode ノードにデプロイしないように要求する
この `nodeAffinity` をデプロイまたは他のワークロードに追加して、Kubernetes が EKS Auto Mode ノードにスケジュール**しないように**要求できます。
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# ハードウェア専有インスタンスで重要なアドオンを実行する
このトピックでは、EKS Auto Mode が `system` ノードプールにワークロードをスケジュールできるように、`CriticalAddonsOnly` の容認を持つワークロードをデプロイする方法について説明します。
EKS Auto Mode の組み込みの `system` ノードプールは、専用インスタンス上で重要なアドオンを実行するために設計されています。この分離により、重要なコンポーネントに専用のリソースが備わり、一般的なワークロードから分離されることが保証され、クラスター全体の安定性とパフォーマンスが向上します。
このガイドでは、`CriticalAddonsOnly` の容認と適切なノードセレクターを利用して、`system` ノードプールにアドオンをデプロイする方法を説明します。これらのステップに従うことで、EKS Auto Mode の特殊なノードプール構造が提供する分離とリソース割り当ての利点を活用して、重要なアプリケーションを専用の `system` ノードにスケジュールできるようになります。
EKS Auto Mode には、`general-purpose` と `system` の 2 つのノードプールが組み込まれています。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
`system` ノードプールの目的は、重要なアドオンを異なるノードに分離することです。`system` ノードプールによってプロビジョニングされたノードには、`CriticalAddonsOnly` という Kubernetes のテイントがあります。Kubernetes は、対応する容認がある場合のみ、これらのノードにポッドをスケジュールします。詳細については、Kubernetes ドキュメントの「[テイントと容認](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。
## 前提条件
+ EKS Auto Mode クラスターで組み込みの `system` ノードプールが有効になっていること。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ `kubectl` がインストールされ、設定済みであること。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## 手順
以下の yaml の例を確認してください。以下の設定に留意してください。
+ `nodeSelector` — これにより、ワークロードが組み込みの `system` ノードプールに関連付けられます。このノードプールは AWS API で有効にする必要があります。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ `tolerations` — この容認は、`system` ノードプール内のノードの `CriticalAddonsOnly` テイントを克服します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
`system` ノードプールで実行するようにワークロードを更新するには、以下の操作を行う必要があります。
1. 既存のワークロードを更新して、上記で説明した以下の設定を追加します。
+ `nodeSelector`
+ `tolerations`
1. `kubectl apply` を使用して、更新されたワークロードをクラスターにデプロイする
ワークロードを更新すると、専用ノードで実行されるようになります。
# EKS Auto Mode でネットワークポリシーを使用する
## 概要:
お客様が EKS を使用してアプリケーション環境をスケールするにつれて、クラスター内外のリソースへの不正アクセスを防ぐ必要があり、そのためにはネットワークトラフィックの分離がますます欠かせないものになります。これは、クラスター内で互いに関連性のない複数のワークロードが並行して動作するマルチテナント環境で特に重要です。Kubernetes ネットワークポリシーを使用すると、Kubernetes ワークロードのネットワークセキュリティ体制を強化し、それをクラスター外のエンドポイントと強固に統合できます。EKS 自動モードは、さまざまなタイプのネットワークポリシーをサポートしています。
### レイヤー 3 と 4 の分離
標準の Kubernetes ネットワークポリシーは OSI ネットワークモデルのレイヤー 3 と 4 で動作し、Amazon EKS クラスター内の IP アドレスまたはポートレベルでトラフィックフローを制御できます。
#### ユースケース
+ ワークロード間でネットワークトラフィックをセグメント化すると、関連するアプリケーションのみが相互に通信できるようになります。
+ ポリシーを使用して名前空間レベルでテナントを分離すると、ネットワークを分離できます。
### DNS ベースの適用
お客様が EKS にデプロイするワークロードはより広範な分散環境に属しているのが一般的で、その中にはクラスター外のシステムやサービスとの通信を必要とするものもあります (インバウンドトラフィック)。こうしたシステムやサービスは、AWS クラウド内にあっても AWS 外にあってもかまいません。ドメインネームシステム (DNS) ベースのポリシーを使用すると、予測精度の高い安定したアプローチに沿って、ポッドからクラスター外のリソースやエンドポイントへの不正アクセスを防ぎ、セキュリティ体制を強化できます。このメカニズムにより、特定の IP アドレスを手動で追跡して許可リストに登録する必要がなくなります。DNS ベースのアプローチに沿ってリソースを保護することで、アップストリームサーバーやホストを変更する際にセキュリティ体制を緩和することも、ネットワークポリシーを変更することもなく、柔軟に外部インフラストラクチャを更新できます。完全修飾ドメイン名 (FQDN)、または DNS ドメイン名に一致するパターンを使用すると、外部エンドポイントへの出力トラフィックをフィルタリングできます。これにより、クラスター外の特定のエンドポイントに複数のサブドメインが関連付けられている場合に、各サブドメインへのアクセスを柔軟に拡張できます。
#### ユースケース
+ Kubernetes 環境からクラスター外のエンドポイントへのアクセスをフィルタリングする場合には、DNS ベースのアプローチを標準とします。
+ マルチテナント環境で AWS サービスへのアクセスを保護します。
+ ハイブリッドクラウド環境でポッドからオンプレミスワークロードへのネットワークアクセスを管理します。
### 管理者 (またはクラスター範囲の) ルール
マルチテナントシナリオのように、ネットワークセキュリティ標準をクラスター全体に適用しなければならないという要件が求められる場合があります。名前空間ごとにポリシーを繰り返し定義して維持するのではなく、単一のポリシーを使用して、名前空間に関係なく、クラスター内のさまざまなワークロードに対するネットワークアクセスコントロールを一元管理できます。こうしたタイプのポリシーでは、レイヤー 3、レイヤー 4、および DNS ルールの使用時に適用されるネットワークフィルタリングルールの適用範囲を拡張できます。
#### ユースケース
+ EKS クラスター内のすべての (または一部の) ワークロードに対するネットワークアクセスコントロールを一元管理します。
+ クラスター全体にわたるデフォルトのネットワークセキュリティ体制を定義します。
+ 組織のセキュリティ標準を運用効率の高い方法でクラスターの範囲へと拡張します。
## 開始方法
### 前提条件
+ EKS Auto Mode が有効になっている Amazon EKS クラスター
+ kubectl がクラスターに接続するように設定されている
### ステップ 1: ネットワークポリシーコントローラーを有効にする
EKS Auto Mode でネットワークポリシーを使用するには、まずクラスターに ConfigMap を適用してネットワークポリシーコントローラーを有効にする必要があります。
1. 以下の内容で `enable-network-policy.yaml` という名前のファイルを作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. ConfigMap をクラスターに適用します。
```
kubectl apply -f enable-network-policy.yaml
```
### ステップ 2: ネットワークポリシーを作成してテストする
これで、EKS Auto Mode クラスターが Kubernetes ネットワークポリシーをサポートするように設定されました。これは [Amazon EKS のネットワークポリシーの星型デモ](network-policy-stars-demo.md) でテストできます。
### ステップ 3: ノードクラスでネットワークポリシーエージェント設定を調整する (オプション)
オプションで新しいノードクラスを作成して、ノード上のネットワークポリシーエージェントのデフォルトの動作を変更したり、ネットワークポリシーイベントのログ記録を有効にしたりできます。これを実行するには、以下の手順を実行します。
1. 次の内容でノードクラス YAML ファイル (例: `nodeclass-network-policy.yaml`) を作成または編集します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. ノードクラス設定をクラスターに適用します。
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. ノードクラスが作成されていることを確認します。
```
kubectl get nodeclass network-policy-config
```
1. このノードクラスを使用するようにノードプールを更新します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## 動作の仕組み
### DNS ベースのネットワークポリシー
![\[EKS 自動で DNS ベースのポリシーが適用される際のワークフローの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[EKS 自動で DNS ベースのポリシーが適用される際のワークフローの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/apply-dns-policy-2.png)
1. プラットフォームチームが、DNS ベースのポリシーを EKS クラスターに適用します。
1. ネットワークポリシーコントローラーが、クラスター内でのポリシーの作成をモニタリングし、ポリシーエンドポイントを調整します。このユースケースの場合、ネットワークポリシーコントローラーは、作成されたポリシーの許可リストに登録されたドメインに基づいて DNS リクエストをフィルタリングするようにノードエージェントに指示します。ドメイン名を許可リストに登録する場合は、FQDN を使用するか、Kubernetes リソース設定に定義されたパターンと一致するドメイン名を使用します。
1. ワークロード A が、クラスター外のエンドポイントの IP を解決しようとします。DNS リクエストはまずプロキシを通過します。その際に、ネットワークポリシーで適用された許可リストに基づいて該当するリクエストがフィルタリングされます。
1. DNS フィルター許可リストを通過した DNS リクエストは、CoreDNS にプロキシされます。
1. CoreDNS は、受け取ったリクエストを外部 DNS リゾルバー (Amazon Route 53 Resolver) に送信して、ドメイン名の背後にある IP アドレスのリストを取得します。
1. 解決した IP が TTL と共に、DNS リクエストへのレスポンスで返されます。こうして解決した IP が eBPF マップに書き込まれて、次のステップで IP レイヤーを適用する際に使用されます。
1. ポッドの veth インターフェイスにアタッチされた eBPF プローブが、所定のルールに基づいて、ワークロード A からクラスター外のエンドポイントへのエグレストラフィックをフィルタリングします。これにより、ポッドは許可リストに登録されたドメインの IP にのみクラスター外のトラフィックを送信できるようになります。こうした IP の有効性は、外部 DNS リゾルバー (Amazon Route 53 Resolver) から取得した TTL に基づいています。
#### ApplicationNetworkPolicy を使用する
`ApplicationNetworkPolicy` は、単一のカスタムリソース定義 (CRD) を使用して、標準の Kubernetes ネットワークポリシーの機能と DNS ベースのフィルタリングを名前空間レベルで結合します。そのため、`ApplicationNetworkPolicy` は以下の用途に使用できます。
1. IP ブロックとポート番号を使用して、ネットワークスタックのレイヤー 3 と 4 に制限内容を定義します。
1. ネットワークスタックのレイヤー 7 で機能するルールを定義し、FQDN に基づいてトラフィックをフィルタリングします。
**重要**
`ApplicationNetworkPolicy` で定義した DNS ベースのルールは、EKS 自動モードで起動した EC2 インスタンスで動作するワークロードにのみ適用できます。`ApplicationNetworkPolicy` は、標準の Kubernetes `NetworkPolicy` のすべてのフィールドをサポートするほか、Egress ルール用の FQDN フィルターにも対応しています。
**警告**
同じ名前空間内で `ApplicationNetworkPolicy` と `NetworkPolicy` に同じ名前を使用しないでください。名前が競合すると、生成された `PolicyEndpoints` オブジェクトにどちらのポリシーも正しく反映されない可能性があります。エラーになることなくどちらのリソースも受け入れられるため、この問題を診断するのは容易ではありません。
名前の競合を解決するには、その名前空間内で一意になるように `ApplicationNetworkPolicy` または `NetworkPolicy` の名前を変更し、対応する `PolicyEndpoints` オブジェクトが正しく更新されることを確認します。
#### 例
EKS 自動モードクラスターにワークロードがあり、DNS 名が付与されたロードバランサーの背後にあるオンプレミスのアプリケーションと通信する必要があります。そのために、次のネットワークポリシーを使用します。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Kubernetes ネットワークレベルでは、`role: backend` というラベルが付いた「galaxy」名前空間内のポッドからのエグレスが、TCP ポート 8080 で **myapp.mydomain.com** というドメイン名に接続できるようになります。また、VPC から社内のデータセンターへのエグレストラフィック用にネットワーク接続をセットアップする必要があります。
![\[EKS 自動でオンプレミスのアプリケーションと通信しているワークロードの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 管理者 (あるいはクラスター) ネットワークポリシー
![\[EKS でネットワークポリシーが評価される順序を示した図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/evaluation-order.png)
#### ClusterNetworkPolicy を使用する
`ClusterNetworkPolicy` を使用する場合、管理者階層ポリシーが最初に評価され、このポリシーを上書きすることはできません。管理者階層ポリシーが評価されたら、名前空間範囲の標準ポリシーに従って、適用したネットワークセグメンテーションルールが実行されます。そのためには、`ApplicationNetworkPolicy` または `NetworkPolicy` を使用します。最後に、ベースライン階層ルールが適用されます。ここには、クラスターワークロードに対するデフォルトのネットワーク制限が定義されています。こうしたベースライン階層ルールは、必要に応じて名前空間範囲のポリシーで上書き**できます**。
#### 例
クラスター内にアプリケーションがあり、これを他のテナントワークロードから分離する必要があります。他の名前空間からクラスタートラフィックを明示的にブロックすると、機密性の高いワークロード名前空間へのネットワークアクセスを防ぐことができます。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 考慮事項
### ポリシー評価順序を理解する
EKS でサポートされているネットワークポリシー機能は、トラフィックを予測して安全に管理できるように、特定の順序で評価されます。そのため、評価の流れを理解したうえで、ご使用の環境に適した効果的なネットワークセキュリティ体制を設計することが重要です。
1. **管理者層ポリシー (最初に評価)**: 管理者階層のすべての ClusterNetworkPolicy が他のポリシーよりも先に評価されます。管理者階層内では、優先順位に従って (優先順位番号の最も小さいものから) ポリシーが処理されます。次にどうなるかは、アクションタイプによって決まります。
+ **拒否アクション (最も高い優先順位)**: 拒否アクションを定義した管理者ポリシーがトラフィックと一致すると、そのトラフィックは他のポリシーとは関係なくすぐにブロックされます。ClusterNetworkPolicy や NetworkPolicy ルールはそれ以上処理されません。これにより、組織全体のセキュリティコントロールを名前空間レベルのポリシーで上書きできないようにしています。
+ **許可アクション**: 拒否ルールが評価されると、許可アクションを定義した管理者ポリシーが優先順位に従って (優先順位番号の最も小さいものから) 処理されます。許可アクションに一致すると、トラフィックは受け入れられ、ポリシーはそれ以上評価されません。これらのポリシーは、ラベルセレクターに基づいて複数の名前空間に対するアクセスを許可して、特定のリソースにどのワークロードがアクセスできるかを一元的に制御できます。
+ **パスアクション**: 管理階層ポリシーにパスアクションを定義すると、意思決定が下位の階層に委任されます。トラフィックがパスルールに一致すると、そのトラフィックの残りの管理者階層ルールの評価がスキップされ、NetworkPolicy 階層に直接進みます。これにより、管理者は特定のトラフィックパターンに対する制御をアプリケーションチームに明示的に委任できます。例えば、パスルールを使用すると、外部アクセスを厳密に制御しつつ、名前空間内のトラフィック管理を名前空間管理者に委任できます。
1. **ネットワークポリシー階層**: 拒否または許可に一致する管理者階層ポリシーがない場合や、パスアクションが一致した場合、次は名前空間範囲の ApplicationNetworkPolicy と従来の NetworkPolicy リソースが評価されます。これらは個々の名前空間内できめ細かく制御できるポリシーで、アプリケーションチームによって管理されます。名前空間範囲のポリシーでは、管理者ポリシーよりも厳しく制限を課すことができます。管理者ポリシーによる拒否の判断を上書きすることはできませんが、管理者ポリシーによって許可またはパスされたトラフィックをさらに制限できます。
1. **ベースライン階層管理ポリシー**: トラフィックに一致する管理者ポリシーや名前空間範囲のポリシーがない場合、ベースライン階層の ClusterNetworkPolicy が評価されます。これにより、デフォルトのセキュリティ体制を名前空間範囲のポリシーで上書きできるため、管理者が組織全体のデフォルトを設定する一方で、チームが必要に応じて柔軟にカスタマイズできます。ベースラインポリシーは、優先順位に従って (優先順位番号の最も小さいものから) 評価されます。
1. **デフォルト拒否 (一致するポリシーがない場合)**: この deny-by-default 動作により、明示的に認められた接続のみが許可されるため、強力なセキュリティ体制を維持できます。
### 最小特権の原則を適用する
+ **制限ポリシーから開始し、必要に応じて徐々にアクセス許可を追加する** - まずはクラスターレベルで deny-by-default ポリシーを実装し、次に正当な接続要件の検証に合わせて許可ルールを段階的に追加していきます。このアプローチにより、チームは外部接続ごとにその正当性を明示的に評価して、より安全で監査可能な環境を構築できるようになります。
+ **未使用のポリシールールを定期的に監査して削除する** - ネットワークポリシーは、アプリケーションの進化に伴い時間が経つにつれて増えていきます。そのために、古いルールが残ってアタックサーフェスが不必要に拡大する可能性があります。ポリシールールを定期的に見直すプロセスを実装して、不要になったものを特定して削除するようにすると、厳格で管理しやすいセキュリティ体制を維持できます。
+ **可能であれば、広範なパターンではなく特定のドメイン名を使用する** - `*.amazonaws.com` のようなワイルドカードパターンは便利ですが、同時に幅広いサービスへのアクセスも許可することになります。可能な限り、`s3.us-west-2.amazonaws.com` のような厳密なドメイン名を指定して、アプリケーションが必要とする特定のサービスにのみアクセスを制限して、ワークロードが侵害された場合に横展開されるリスクを軽減します。
### EKS での DNS ベースのポリシーを使用する
+ `ApplicationNetworkPolicy` を使用して定義した DNS ベースのルールは、EKS 自動モードで起動された EC2 インスタンスで動作するワークロードにのみ適用できます。混合モードクラスター (EKS 自動ワーカーノードと非 EKS 自動ワーカーノードの両方で構成) を実行している場合、DNS ベースのルールは EKS 自動モードのワーカーノード (EC2 マネージドインスタンス) でのみ有効です。
### DNS ポリシーを検証する
+ **ステージングクラスターを使用してテスト用に本番稼働のネットワークトポロジをミラーリングする** - ステージング環境では、ポリシーを正確にテストできるように、本番稼働のネットワークアーキテクチャ、外部依存関係、および接続パターンをレプリケートする必要があります。例えば、VPC 設定、DNS 解決動作、本番稼働のワークロードで必要になるのと同じ外部サービスへのアクセスを一致させます。
+ **重要なネットワークパスを自動的にテストする機能を実装する** - CI/CD パイプラインの一部として、必要不可欠な外部サービスへの接続を検証する自動テストを構築します。自動テストでは、正当なトラフィックフローは許可され、不正な接続はブロックされることを検証します。インフラストラクチャが進化しても、ネットワークポリシーにより、正しいセキュリティ体制が維持されていることを継続的に検証する必要があります。
+ **ポリシーが変更されたらアプリケーションの動作をモニタリングする** - 新規または変更後のネットワークポリシーを本番稼働にデプロイしたら、アプリケーションログ、エラー率、パフォーマンスメトリクスを注意深くモニタリングして、接続の問題があればすばやく特定できるようにします。明確なロールバック手順を確立して、予期しないアプリケーションの動作やサービスの中断が発生したら、ポリシーへの変更をすばやく元に戻せるようにします。
### Amazon Route 53 DNS ファイアウォールとのインタラクション
EKS 管理者ポリシーとネットワークポリシーは、トラフィックの開始時にポッドレベルで最初に評価されます。EKS ネットワークポリシーで特定のドメインへのエグレスを許可している場合、ポッドは Route 53 Resolver に到達する DNS クエリを実行します。この時点で、Route 53 DNS ファイアウォールルールが評価されます。DNS ファイアウォールがドメインクエリをブロックしている場合、EKS ネットワークポリシーで許可していたとしても、DNS 解決は失敗し、接続を確立できません。そのため、セキュリティレイヤーをいくつか作成して補完します。EKS DNS ベースのネットワークポリシーではアプリケーションに固有のアクセス要件とマルチテナントセキュリティ境界に応じてポッドレベルでエグレスを制御し、DNS ファイアウォールでは既知の悪意のあるドメインから VPC 全体を保護して組織全体のブロックリストを適用します。
# EKS Auto Mode のサブネットにタグを付ける
EKS Auto Mode の負荷分散機能を使用する場合は、VPC サブネットに AWS タグを追加する必要があります。
## 背景
これらのタグは、サブネットがクラスターに関連付けられているものと特定し、さらに重要な点として、サブネットがパブリックかプライベートかを識別します。
パブリックサブネットは、インターネットゲートウェイを介してインターネットに直接アクセスできます。ロードバランサーなど、パブリックにアクセスできるようにする必要があるリソースに使用されます。
プライベートサブネットには直接インターネットにアクセスできる機能がなく、アウトバウンドトラフィックに NAT ゲートウェイを使用します。プライベートサブネットは、パブリック IP を必要としない EKS ノードなどの内部リソースに使用されます。
NAT ゲートウェイとインターネットゲートウェイの詳細については、「Amazon Virtual Private Cloud (VPC) ユーザーガイド」の「[VPC を他のネットワークに接続する](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)」を参照してください。
## 要件
現時点で、EKS Auto Mode で負荷分散に使用するサブネットには、次のいずれかのタグが必要です。
### パブリックサブネット
パブリックサブネットは、インターネット向けロードバランサーに使用されます。これらのサブネットには、次のタグが必要です。
| キー | 値 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` または `` |
### プライベートサブネット
プライベートサブネットは、内部ロードバランサーに使用されます。これらのサブネットには、次のタグが必要です。
| キー | 値 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` または `` |
## 手順
開始する前に、パブリックサブネット (インターネットゲートウェイアクセスを使用) とプライベートサブネット (NAT ゲートウェイを使用) を特定します。VPC リソースを変更するには、アクセス許可が必要です。
### AWS マネジメントコンソール
1. Amazon VPC コンソールを開き、**[サブネット]** に移動します。
1. タグ付けするサブネットを選択します。
1. **[タグ]** タブを選択してから、**[タグを追加]** を選択します。
1. 適切なタグを追加します。
+ パブリックサブネットの場合: Key=`kubernetes.io/role/elb`
+ プライベートサブネットの場合: Key=`kubernetes.io/role/internal-elb`
1. **[値]** を `1` に設定するか、空白のままにします。
1. 保存し、残りのサブネットについても同じ操作を繰り返します。
### AWS CLI
パブリックサブネットの場合:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
プライベートサブネットの場合:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
`subnet-ID` を実際のサブネット ID に置き換えます。
# kubectl debug を使用して Kubernetes ノードの CIS コンプライアンスレポートを生成する
このトピックでは、`kubectl debug` コマンドを使用して Amazon EKS ノードの CIS (Center for Internet Security) コンプライアンスレポートを生成する方法について説明します。このコマンドを使用すると、Kubernetes ノードにデバッグコンテナを一時的に作成し、`apiclient` ツールを使用して CIS コンプライアンスチェックを実行できます。この `apiclient` ツールは、Bottlerocket OS (EKS Auto Mode ノードで使用する OS) に組み込まれています。
## 前提条件
開始する前に、以下を確認してください。
+ `kubectl` が設定された Amazon EKS クラスターへのアクセス (バージョンは v1.32.0 以上である必要があります。確認するには `kubectl version` と入力します)。
+ ノードをデバッグするための適切な IAM アクセス権限。
+ デバッグオペレーションが許可される有効なプロファイル (例: `sysadmin`)。
`kubectl` とデバッグプロファイルの併用方法については、Kubernetes ドキュメントの「[Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)」で詳しく確認できます。
## 手順
1. レポートを実行するノードの AWS インスタンス ID を決定します。クラスター内のノードを一覧表示するには、以下のコマンドを使用します。インスタンス ID は名前の列にあり、`i-` で始まります。
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. `` を、クエリするノードのインスタンス ID に置き換えて、次のコマンドを実行します。
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
このコマンドのコンポーネントは次のとおりです。
+ `kubectl debug node/` — 指定した EC2 インスタンス ID でデバッグセッションを作成します。
+ `-it` — TTY (コマンドラインシェル) を割り当てて、stdin を開いたままにし、インタラクティブに使用できるようにします。
+ `--profile=sysadmin` — 指定した `kubectl` プロファイル (適切なアクセス権限が付与されている) を使用します。
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` — `amazonlinux:2023` を、デバッグ用のコンテナイメージに使用します。
+ `bash -c "…"` — bash シェルで次のコマンドを実行します。
+ `yum install -q -y util-linux-core` — 必要なユーティリティパッケージをサイレントインストールします。
+ `nsenter -t 1 -m` — `nsenter` を実行して、ホストプロセス (PID 1) の名前空間に入ります。
+ `apiclient report cis --level 1 --format text` — テキスト出力を使用して、レベル 1 で CIS コンプライアンスレポートを実行します。
1. レポートのテキスト出力を確認します。
## 出力の解釈
このコマンドにより、テキストベースのレポートを生成して、さまざまな CIS コントロールのコンプライアンスステータスを確認できます。以下のような情報が出力されます。
+ 個々の CIS コントロール ID
+ 各コントロールの説明
+ 各チェックの合格、失敗、スキップのステータス
+ コンプライアンス上の問題の詳細説明
Bottlerocket インスタンスで実行したレポートの出力例を次に示します。
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
ベンチマークの詳細については、Center for Internet Security (CIS) の「[Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)」を参照してください。
## 関連リソース
+ 「[Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)」(Bottlerocket OS ドキュメント)
+ 「[実行中のポッドのデバッグ](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)」(Kubernetes ドキュメント)
+ 「[Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)」(Center for Internet Security (CIS))
# EKS オートモードでカスタマーマネージド KMS キー使用した EBS ボリュームの暗号化を有効にする
カスタマーマネージド KMS キーを使用すると、EKS オートモードのインスタンスのエフェメラルルートボリュームを暗号化することができます。
Amazon EKS オートモードは、Kubernetes クラスターの暗号化された EBS ボリュームを管理するときに、サービスリンクロールを使用して他の AWS サービスにアクセス許可を委任します。このトピックでは、EKS オートモードの Amazon EBS 暗号化のカスタマーマネージドキーを指定するときに必要になる、キーポリシーの設定方法について解説します。
考慮事項:
+ EKS オートモードでは、デフォルトの AWS マネージドキーを使用してアカウントにある暗号化されたボリュームを保護する場合、追加の承認は不要です。
+ このトピックでは、EC2 インスタンスのルートボリュームである、エフェメラルボリュームを暗号化する方法について取り上げます。ワークロードに使用するデータボリュームの暗号化の方法については、「[ストレージクラスを作成する](create-storage-class.md)」を参照してください。
## 概要
以下の AWS KMS キーは、EKS オートモードでインスタンスを起動するときに、Amazon EBS ルートボリュームの暗号化に使用できます。
+ **AWS マネージドキー** – Amazon EBS が作成、所有、管理するアカウント内の暗号化キーです。これは、新しいアカウントのデフォルトの暗号化キーです。
+ **カスタマーマネージド型キー** – お客様が作成、所有、および管理するカスタム暗号化キー。
**注記**
KMS キーは対称である必要があります。Amazon EBS は非対称カスタマー管理キーをサポートしていません。
## ステップ 1: キーポリシーを設定する
KMS キーには、カスタマーマネージドキーで暗号化された Amazon EBS ボリュームを使用してインスタンスを起動することを EKS オートモードに許可する、キーポリシーが必要です。
キーポリシーは次の構造で設定します。
**注記**
このポリシーには EKS オートモードのアクセス許可しか含まれていません。他の ID でキーを使用したり許可を管理したりする必要がある場合、このキーポリシーに追加のアクセス許可が必要になる可能性があります。
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
`` を、現在お使いの AWS アカウント ID に置き換えます。
キーポリシーを設定する場合:
+ `ClusterServiceRole` には、暗号化のオペレーションに KMS キーを使用するために必要な、IAM アクセス許可が含まれている必要があります。
+ `kms:GrantIsForAWSResource` 条件によって、AWS サービスに対してのみ許可を作成することができます。
## ステップ 2: カスタマーマネージドキーを使用して NodeClass を設定する
キーポリシーを設定したら、EKS オートモード NodeClass 設定で KMS キーを参照します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
プレースホルダーの値を実際の値にそれぞれ置き換えます。
+ `` は現在の AWS リージョンに
+ `` はご自身の AWS アカウント ID に
+ `` はご自身の KMS キー ID に
KMS キーは以下のいずれかの形式を使用して指定することができます。
+ KMS キー ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS キー ARN: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ キーエイリアス名: `alias/eks-auto-mode-key`
+ キーエイリアス ARN: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
kubectl を使用して NodeClass 設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
## 関連リソース
+ [Amazon EKS のノードクラスを作成する](create-node-class.md)
+ 詳細については、「AWS Key Management Service デベロッパーガイド」を参照してください。
+ [キーポリシーにおける AWS サービスのアクセス許可](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [キーポリシーを変更する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# EKS Auto Mode の組織コントロールを更新する
一部の組織コントロールは、EKS Auto Mode の正常な機能を妨げる場合があります。その場合、これらのコントロールを更新し、EKS Auto Mode がユーザーに代わって EC2 インスタンスを管理するために必要なアクセス許可を持てるようにする必要があります。
EKS Auto Mode には、EKS Auto Mode ノードをバックアップする EC2 インスタンスを起動するためのサービスロールが使用されます。サービスロールはユーザーの名義で作成された [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)であり、サービスがユーザーに代わってアクションを実行するために引き受けます。[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) はサービスロールで実行されるアクションに常に適用されます。SCP が自動モードのオペレーションを禁止できるようにします。最も一般的なケースは、SCP を使用して起動できる Amazon マシンイメージ (AMI) を制限する場合です。EKS Auto Mode を機能させるには、SCP を変更して EKS Auto Mode アカウントから AMI の起動を許可します。
[EC2 が許可された AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 機能を使用し、他のアカウントで AMI の可視性を制限することもできます。この機能を使用する場合、対象リージョンに EKS Auto Mode AMI アカウントも含めるため、イメージ条件を拡張する必要があります。
## EKS Auto Mode AMI を除くすべての AMI をブロックする SCP の例
以下の SCP では、AMI が us-west-2 または us-east-1 の EKS Auto Mode AMI アカウントに属していない限り、`ec2:RunInstances` の呼び出しが防止されます。
**注記**
`ec2:Owner` コンテキストキーを使用**しない**ことが重要です。Amazon は EKS Auto Mode AMI アカウントを所有しており、このキーの値は常に `amazon` になります。`ec2:Owner` が `amazon` の場合に AMI の起動を許可する SCP を構築すると、EKS Auto Mode 用の AMI だけでなく、Amazon が所有する AMI の起動も許可されます。\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS Auto Mode AMI アカウント
リージョンによって異なる AWS アカウントは、EKS Auto Mode パブリック AMI をホストします。
| | |
| --- |--- |
| AWS リージョン | アカウント |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us–east–1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## パブリック IP アドレスの関連付け
`ec2:RunInstances` が呼び出されると、インスタンス起動の `AssociatePublicIpAddress` フィールドは、インスタンスが起動されるサブネットのタイプによって自動的に決定されます。SCP を使用すると、起動するサブネットのタイプに関係なく、この値を明示的に false に設定することができます。この場合、SCP の要件を満たすために NodeClass フィールド `spec.advancedNetworking.associatePublicIPAddress` を false に設定することもできます。
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する
[キャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)へのワークロードのデプロイを制御できます。EKS 自動モードは、EC2 On-Demand Capacity Reservations (ODCR) と EC2 Capacity Block for ML をサポートしています。
**ヒント**
デフォルトでは、EKS Auto Mode はオープンマッチングを通じてオープン ODCR に起動できますが、優先順位は付けられません。オープンマッチングによって起動されたインスタンスには、`reserved` ではなく `karpenter.sh/capacity-type: on-demand` というラベルが付けられます。ODCR の使用を優先し、インスタンスに `karpenter.sh/capacity-type: reserved` というラベルを付けるには、NodeClass 定義で `capacityReservationSelectorTerms` を設定します。Capacity Blocks for ML には、常に `capacityReservationSelectorTerms` が必要であり、自動的には使用されません。
## EC2 オンデマンドキャパシティ予約 (ODCR)
EC2 オンデマンドキャパシティ予約 (ODCR) を使用すると、任意の期間中に特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。EKS Auto Mode を使用するとき、Kubernetes ワークロードをこれらの予約されたインスタンスにデプロイするかどうかを制御し、事前購入された容量の使用率を最大化したり、重要なワークロードが保証されたリソースにアクセスできるようにしたりすることができます。
デフォルトでは、EKS Auto Mode は自動的にオープン ODCR として起動します。ただし、NodeClass で `capacityReservationSelectorTerms` を設定することで、ワークロードが使用する ODCR を明示的に制御できます。設定された ODCR を使用してプロビジョニングされたノードには `karpenter.sh/capacity-type: reserved` があり、オンデマンドおよびスポットよりも優先されます。この機能を有効にすると、EKS Auto Mode はオープン ODCR を自動的に使用しなくなります。NodeClass で明示的に選択する必要があり、クラスター全体のキャパシティ予約の使用状況を正確に制御できます。
**警告**
クラスター内の NodeClass で `capacityReservationSelectorTerms` を設定した場合、EKS Auto Mode はクラスター内の*すべて*の NodeClass に対してオープン ODCR を自動的に使用しなくなります。
### NodeClass の例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
この NodeClass の例では、ODCR を選択するための 2 つのアプローチが示されています。1 番目の方法では、特定の ODCR が ID (`cr-56fac701cc1951b03`) で直接参照されます。2 番目の方法ではタグベースの選択を使用し、タグ `Name: "targeted-odcr"` で ODCR がターゲットされます。オプションとして、予約を所有する AWS アカウントでフィルタリングすることもできます。アカウント間シナリオや共有キャパシティ予約を使用する場合に特に便利です。
## EC2 Capacity Blocks for ML
Capacity Blocks for ML は、短期間の機械学習ワークロードをサポートするため、GPU ベースの高速コンピューティングインスタンスを将来の日付で予約します。キャパシティブロック内で実行されるインスタンスは、Amazon EC2 UltraClusters 内に自動的に互いに近く配置され、低レイテンシーでペタビットスケールのノンブロッキングネットワーキングを実現します。
サポートされているプラットフォームとインスタンスタイプの詳細については、「EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」を参照してください。
前述の ODCR と同じく、EKS 自動モードの NodeClass を作成し、その中で Capacity Block for ML を使用できます。
次のサンプル定義では、3 つのリソースを作成しています。
1. キャパシティブロック予約を参照する NodeClass
1. NodeClass を使用し、テイントを適用する NodePool
1. テイントを許容し、GPU リソースをリクエストするポッド仕様
### NodeClass の例
この NodeClass は、特定の Capacity Block for ML をその予約 ID で参照します。この ID は、EC2 コンソールから取得できます。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
### NodePool の例
この NodePool は、`gpu` NodeClass を参照し、以下の重要な設定を指定します。
+ `karpenter.sh/capacity-type: reserved` を設定してリザーブドキャパシティ**のみ**を使用します。
+ ML ワークロードに適した特定の GPU インスタンスファミリーをリクエストします。
+ `nvidia.com/gpu` テイントを適用して、これらのノードで GPU ワークロードのみがスケジュールされるようにします。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
### ポッドの例
この例に示したポッドは、キャパシティブロックノードで動作するようにワークロードを設定する方法を示しています。
+ **nodeSelector** を使用して、特定の GPU タイプ (この例では H200 GPU) をターゲットとしています。
+ NodePool で適用される `nvidia.com/gpu` テイントの**許容値**が含まれています。
+ `nvidia.com/gpu` リソースタイプを使用して明示的に **GPU リソースをリクエスト**します。
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
詳細については、Kubernetes ドキュメントの「[ポッド](https://kubernetes.io/docs/concepts/workloads/pods/)」を参照してください。
### 関連リソース
+ 「Amazon EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」
+ 「Amazon EC2 ユーザーガイド」の「[キャパシティブロックの検索と購入](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)」
+ [Amazon EKS で AI/ML ワークロードのコンピューティングリソースを管理する](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ 「EKS ベストプラクティスガイド」の「[GPU リソースの最適化とコスト管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)」
# Local Zone に EKS 自動モードノードをデプロイする
EKS 自動モードでは、自動ノードプロビジョニングでクラスター管理をシンプルにできます。AWSLocal Zone は、エンドユーザーに地理的に近い場所まで AWS インフラストラクチャを拡張して、レイテンシーの影響を受けやすいアプリケーションのレイテンシーを軽減します。このガイドでは、EKS 自動モードノードを AWS Local Zone にデプロイするプロセスを見ていきます。ガイドに従うと、特定の地理的エリアのユーザーを対象に、コンテナ化されたアプリケーションを低レイテンシーで実行できます。
また、Kubernetes テイントおよび許容を使用して、特定のワークロードのみが Local Zone ノードで実行されるようにする方法も示します。これにより、コストを抑え、リソースの使用を最適化できます。
## 前提条件
EKS 自動モードノードを Local Zone にデプロイする前に、次の前提条件が満たされていることを確認してください。
+ [EKS 自動モードのクラスターが既に存在している](create-auto.md)
+ [AWS アカウントで Local Zone にオプトインされている](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## ステップ 1: Local Zone サブネットを作成する
EKS 自動モードノードを Local Zone にデプロイする最初のステップは、その Local Zone にサブネットを作成することです。このサブネットは、ノードのネットワークインフラストラクチャとなるもので、VPC の他の要素と通信できるようになります。「[Local Zone サブネットを作成する](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)」の手順 (「AWS Local Zone ユーザーガイド」) に従って、選択した Local Zone にサブネットを作成します。
**ヒント**
Local Zone サブネットの名前をメモします。
## ステップ 2: Local Zone サブネット用に NodeClass を作成する
Local Zone サブネットを作成したら、このサブネットを参照する NodeClass を定義する必要があります。NodeClass は、ノードのインフラストラクチャ属性を指定する Kubernetes カスタムリソースで、例えば使用するサブネット、セキュリティグループ、ストレージ設定を指定します。以下の例では、Local Zone サブネットをその名前に基づいてターゲットとする NodeClass を「local-zone」という名前で作成しています。また、サブネット ID を使用することもできます。Local Zone サブネットをターゲットとするように、この設定を調整する必要があります。
詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## ステップ 3: NodeClass とテイントで NodePool を作成する
NodeClass を設定したら、この NodeClass を使用する NodePool を作成する必要があります。NodePool では、インスタンスタイプなど、ノードのコンピューティング特性を定義します。NodePool は、インスタンスの起動場所を決定する際に NodeClass をリファレンスとして使用します。
以下の例では、「local-zone」NodeClass を参照する NodePool を作成しています。また、ノードにテイントを追加して、これらの Local Zone ノードでは許容範囲が一致するポッドのみをスケジュールできるようにしています。これは、Local Zone ノードにとって特に重要です。このノードは、通常コストが高く、レイテンシーを短縮すると特にメリットが得られるワークロードでのみ使用する必要があるからです。
詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
key が `aws.amazon.com/local-zone` で effect が `NoSchedule` のテイントにより、許容範囲が一致しないポッドがこれらのノードでスケジュールされることはありません。これにより、通常のワークロードが誤って Local Zone で実行されて、想定外のコストが発生するのを防ぐことができます。
## ステップ 4: 許容範囲とノードアフィニティでワークロードをデプロイする
Local Zone ノードへのワークロードの配置を最適に制御するには、テイント/許容範囲とノードアフィニティの両方を一緒に使用します。このように組み合わせたアプローチには以下のメリットがあります。
1. **コストの抑制**: テイントにより、許容範囲が明示的に指定されたポッドのみが、コストが高くつく可能性がある Local Zone リソースを使用できるようになります。
1. **保証された配置**: ノードアフィニティにより、レイテンシーの影響を受けやすいアプリケーションは、通常のクラスターノードではなく、Local Zone でのみ実行されます。
以下に、Local Zone ノードでのみ実行されるように設定された Deployment の例を示します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
この Deployment には、重要なスケジューリング設定が 2 つあります。
1. **許容範囲**により、テイントが `aws.amazon.com/local-zone` のノードにポッドをスケジュールできます。
1. **ノードアフィニティ**要件により、こうしたポッドはラベルが `node-type: local-zone` のノードでのみ実行されます。
これにより、レイテンシーの影響を受けやすいアプリケーションは Local Zone ノードでのみ実行され、通常のアプリケーションは明示的に設定されていない限り Local Zone リソースを消費しません。
## ステップ 5: AWS コンソールで検証する
NodeClass、NodePool、Deployment をセットアップしたら、ノードが想定どおりに Local Zone にプロビジョニングされていることと、ワークロードがノードで実行されていることを確認する必要があります。AWS マネジメントコンソールを使用すると、EC2 インスタンスが適切な Local Zone サブネットで起動されていることを確認できます。
また、`kubectl get nodes -o wide` を使用すると、Kubernetes ノードリストをチェックして、ノードが適切なラベルとテイントでクラスターに参加していることを確認できます。
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
さらに、ワークロードポッドが Local Zone ノードにスケジュールされていることを確認することもできます。
```
kubectl get pods -o wide
```
このアプローチにより、指定された範囲で Local Zone テイントを許容するワークロードのみがこれらのノードでスケジュールされるため、コストを抑え、Local Zone リソースを最も効率的に使用できます。
# ノードの高度なセキュリティ設定を構成する
このトピックでは、ノードクラスの `advancedSecurity` 仕様を使用して Amazon EKS Auto Mode ノードの高度なセキュリティ設定を構成する方法について説明します。
## 前提条件
開始する前に、以下を確認してください。
+ Amazon EKS Auto Mode クラスター。詳細については、「[Amazon EKS 自動モードl クラスターを作成する](create-auto.md)」を参照してください。
+ `kubectl` がインストールされ、設定済みであること。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
+ ノードクラス設定について。詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## 高度なセキュリティ設定を構成する
ノードの高度なセキュリティ設定を構成するには、ノードクラス仕様の `advancedSecurity` フィールドを設定します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
この設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
ノードプール設定でこのノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## フィールドの説明
+ `fips` (ブール値、オプション): `true` に設定すると、FIPS 140-2 検証済み暗号化モジュールを含む AMI を使用してノードをプロビジョニングします。この設定では、FIPS 準拠の AMI が選択されます。お客様はコンプライアンス要件を管理する責任があります。詳細については、「[AWS FIPS Compliance](https://aws.amazon.com/compliance/fips/)」を参照してください。デフォルト: `false`。
+ `kernelLockdown` (文字列、オプション): カーネルロックダウンセキュリティモジュールモードを制御します。使用できる値:
+ `integrity`: カーネルメモリを上書きしたり、カーネルコードを変更するメソッドをブロックします。署名なしカーネルモジュールがロードされないようにします。
+ `none`: カーネルロックダウン保護を無効にします。
詳細については、「[Linux kernel lockdown](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)」ドキュメントを参照してください。
## 考慮事項
+ FIPS 準拠の AMI は、AWS 米国東部/西部、AWS GovCloud (米国)、AWS カナダ (中部/西部) の各リージョンで利用できます。詳細については、「[AWS FIPS Compliance](https://aws.amazon.com/compliance/fips/)」を参照してください。
+ `kernelLockdown: "integrity"` を使用する場合は、ワークロードが署名なしカーネルモジュールのロードやカーネルメモリの変更を必要としないことを確認してください。
## 関連リソース
+ [Amazon EKS のノードクラスを作成する](create-node-class.md) – 完全なノードクラス設定ガイド
+ [EKS 自動モードl 用のノードプールを作成する](create-node-pool.md) – ノードプールの設定
# EKS Auto Mode の仕組みの説明
この章では、Amazon EKS Auto Mode クラスターのコンポーネントの仕組みについて説明します。
**Topics**
+ [Amazon EKS 自動モードl マネージドインスタンスについての説明](automode-learn-instances.md)
+ [EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)
+ [EKS 自動モードl での VPC ネットワーキングとロードバランシングの説明](auto-networking.md)
# Amazon EKS 自動モードl マネージドインスタンスについての説明
このトピックではAmazon EKS 自動モードl が EKS クラスター内の Amazon EC2 インスタンスを管理する方法について説明します。EKS 自動モードl を有効にすると、クラスターのコンピューティングリソースが EKS によって自動的にプロビジョニングおよび管理され、クラスター内のノードとして機能する EC2 インスタンスの操作方法が変わります。
Amazon EKS 自動モードl がインスタンスを管理する方法を理解することはワークロードのデプロイ戦略と運用手順を計画するのに不可欠です。従来の EC2 インスタンスやマネージドノードグループとは異なり、これらのインスタンスは特定のタイプのアクセスとカスタマイズを制限しながら、EKS が多くの運用面に対して責任を負う別のライフサイクルモデルに従います。
Amazon EKS 自動モードl は新しい EC2 インスタンスを作成するためのルーチンタスクを自動化し、それらをノードとして EKS クラスターにアタッチします。EKS 自動モードl はワークロードが既存のノードに収まらない状況を検出し、新しい EC2 インスタンスを作成します。
Amazon EKS 自動モードl はEC2 インスタンスの作成、削除、パッチ適用を担います。インスタンスにデプロイされたコンテナとポッドについてはユーザーの責任となります。
EKS 自動モードl によって作成された EC2 インスタンスは他の EC2 インスタンスとは異なり、マネージドインスタンスです。このマネージドインスタンスは EKS によって所有され、制限が厳しくなっています。EKS 自動モードl によって管理されているインスタンスに直接アクセスしたりソフトウェアをインストールしたりすることはできません。
AWS ではEKS 自動モードl またはセルフマネージド Karpenter の実行をお勧めします。移行中でも高度な設定においてでもインストールが可能です。両方がインストールされている場合はワークロードが Karpenter または EKS 自動モードl に関連付けられるようにノードプールを設定します。
詳細については「Amazon EC2 ユーザーガイド」の「[Amazon EC2 管理されたインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)」を参照してください。
## 比較表
| スタンダード EC2 インスタンス | EKS 自動モードl マネージドインスタンス |
| --- | --- |
| インスタンスのパッチ適用と更新はユーザーの責任となります。 | AWS で自動的にインスタンスのパッチ適用と更新が行われます。 |
| EKS はインスタンス上のソフトウェアに関与しません。 | EKS は`kubelet`、コンテナランタイム、オペレーティングシステムなど、インスタンス上の特定のソフトウェアに関与します。 |
| EC2 API を使用して EC2 インスタンスを削除できます。 | EKS によりアカウントにデプロイされたインスタンスの数が決定されます。ワークロードを削除すると、EKS によりアカウント内のインスタンスの数が減ります。 |
| SSH を使用して EC2 インスタンスにアクセスできます。 | ポッドとコンテナをマネージドインスタンスにデプロイできます。 |
| ユーザーがオペレーティングシステムとイメージ (AMI) を決定します。 | AWS によりオペレーティングシステムとイメージが決定されます。 |
| Windows または Ubuntu の機能に依存するワークロードをデプロイできます。 | Linux に基づいてコンテナをデプロイできますが、特定の OS 依存関係はありません。 |
| ユーザーが起動するインスタンスタイプとファミリーを決定します。 | AWS により起動するインスタンスタイプとファミリーが決定されます。ノードプールを使用して、EKS 自動モードl が選択するインスタンスタイプを制限できます。 |
次の機能はマネージドインスタンスとスタンダード EC2 インスタンスの両方で機能します：
+ インスタンスは AWS コンソールで表示できます。
+ インスタンスストレージはワークロードのエフェメラルストレージとして使用できます。
### AMI サポート
EKS Auto Mode では、AWS がコンピューティングノードに使用されるイメージ (AMI) を決定します。AWS は新しい EKS Auto Mode AMI バージョンのロールアウトをモニタリングします。AMI バージョンに関連するワークロードの問題が発生した場合は、サポートケースを作成します。詳細については、「AWS サポートユーザーガイド」の「[Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)」を参照してください。
EKS の場合、通常、CVE とセキュリティ修正を含む新しい AMI が毎週リリースされます。
## EKS Auto Mode でサポートされているインスタンスリファレンス
EKS Auto Mode は、サポートされているタイプの、最小サイズ要件を満たしたインスタンスのみを作成します。
EKS 自動モードl では次のインスタンスタイプがサポートされています：
| ファミリー | インスタンスタイプ |
| --- | --- |
| コンピューティングの最適化 (C ) | c8i、c8i-flex、c8gd、c8gn、c8g、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4 |
| 汎用 (M) | m8i、m8i-flex、m8a、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、m5d、m5zn、m4 |
| メモリ最適化 (R ) | r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4 |
| バースト可能 (T) | t4g、t3、t3a、t2 |
| ハイメモリ (Z/X) | z1d、x8g、x2gd |
| ストレージ最適化 (I/D) | i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn |
| 高速コンピューティング (P/G/Inf/Trn) | p5、p4d、p4de、p3、p3dn、gr6、g6、g6e、g5g、g5、g4dn、inf2、inf1、trn1、trn1n |
| ハイパフォーマンスコンピューティング (X2) | x2iezn、x2iedn、x2idn |
さらに、EKS Auto Mode は、次の要件を満たす EC2 インスタンスのみを作成します。
+ 複数の CPU
+ インスタンスサイズがナノ、マイクロ、スモールではない
詳細については、「[Amazon EC2 インスタンスタイプの命名規則](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)」を参照してください。
## インスタンスメタデータサービス
+ EKS Auto Mode では、デフォルトでホップ制限が 1 の IMDSv2 が実施され、AWS セキュリティのベストプラクティスに準拠します。
+ このデフォルト設定は自動モードでは変更できません。
+ 通常は IMDS アクセスが必要なアドオンの場合、IMDS ルックアップを避けるため、インストール中にパラメータ (AWS リージョンなど) を指定します。詳細については、「[Amazon EKS アドオンのためにカスタマイズできるフィールドを決定する](kubernetes-field-management.md)」を参照してください。
+ 自動モードで実行するときにポッドが IMDS アクセスを絶対に必要とする場合は、ポッドを で実行するように設定する必要があります`hostNetwork: true`。ポッドがインスタンスメタデータサービスに直接アクセスできるようになります。
+ ポッドにインスタンスメタデータへのアクセスを付与する場合、セキュリティ上の影響などを配慮してください。
Amazon EC2 インスタンスメタデータサービス (IMDS) に関する詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータサービスのオプション設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)」を参照してください。
## 考慮事項
+ NodeClass で設定されたエフェメラルストレージがインスタンスの NVMe ローカルストレージよりも小さい場合、EKS Auto Mode は次のアクションを自動的に実行することで、手動設定の必要性を排除します。
+ より小さい (20 GiB) Amazon EBS データボリュームを使用し、コストを削減します。
+ エフェメラルデータ用に NVMe ローカルストレージをフォーマットして設定します。複数の NVMe ドライブがある場合、これには RAID 0 アレイの設定が含まれます。
+ `ephemeralStorage.size` がローカルの NVMe 容量と等しいかそれより大きい場合、以下のアクションが実行されます。
+ Auto Mode では、容量の少ない EBS ボリュームはスキップされます。
+ NVMe ドライブは、ワークロードに直接公開されます。
+ Amazon EKS 自動モードは、以下の AWS Fault Injection Service アクションをサポートしていません。
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS 自動モードは、AWS Fault Injection Service EKS ポッドアクションをサポートしています。詳細については「AWS レジリエンスハブユーザーガイド」の「[Fault Injection Service の実験管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)」と「[AWS FIS aws:eks:pod アクション](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)」を参照してください。
+ EKS 自動モードl ノードに `Neuron Device Plugin` をインストールする必要はありません。
クラスター内に他のタイプのノードがある場合、自動モードのノードで実行されないように Neuron Device プラグインを設定する必要があります。詳細については「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。
# EKS Auto Mode での ID とアクセスについての説明
このトピックでは、EKS Auto Mode を使用するのに必要な Identity and Access Management (IAM) ロールとアクセス許可について説明します。EKS Auto Mode は、クラスター IAM ロールとノード IAM ロールという 2 つのプライマリ IAM ロールを使用します。これらのロールは、EKS Pod Identity および EKS アクセスエントリと連携して動作し、EKS クラスターの包括的なアクセス管理を提供します。
EKS Auto Mode を設定するときには、AWS サービスがクラスターリソースとやり取りできるようにする特定のアクセス許可を持つこれらの IAM ロールを設定する必要があります。これには、コンピューティングリソース、ストレージボリューム、ロードバランサー、ネットワーキングコンポーネントを管理するためのアクセス許可が含まれます。これらのロール設定を理解することは、適切なクラスターオペレーションおよびセキュリティに不可欠です。
EKS Auto Mode では、AWS IAM ロールは EKS アクセスエントリを介して Kubernetes アクセス許可に自動的にマッピングされるため、`aws-auth` ConfigMaps またはカスタムバインディングを手動で設定する必要はありません。新しい Auto Mode クラスターを作成すると、EKS はアクセスエントリを使用して対応する Kubernetes アクセス許可を自動的に作成し、AWS サービスとクラスターコンポーネントが AWS と Kubernetes の両方の認証システムで適切なアクセスレベルになるようにします。この自動統合により、設定の複雑さが軽減され、EKS クラスターの管理時によく発生するアクセス許可関連の問題を防ぐことができます。
## クラスター IAM ロール
クラスター IAM ロールは、Kubernetes クラスターのアクセス許可を管理するために Amazon EKS が使用する AWS Identity and Access Management (IAM) ロールです。このロールは、クラスターに代わって他の AWS サービスとやり取りするのに必要なアクセス許可を Amazon EKS に付与し、EKS アクセスエントリにより Kubernetes アクセス許可が付与されて自動的に設定されます。
+ AWS IAM ポリシーをこのロールにアタッチする必要があります。
+ EKS Auto Mode は、EKS アクセスエントリを使用して、このロールに Kubernetes アクセス許可を自動的にアタッチします。
+ EKS Auto Mode を使用する場合、AWS では AWS アカウントごとに 1 つのクラスター IAM ロールを作成することをお勧めします。
+ AWS では、このロールの名前を `AmazonEKSAutoClusterRole` とすることをお勧めします。
+ このロールには、EBS ボリューム、Elastic Load Balancer、EC2 インスタンスなどのリソースを管理するために、複数の AWS サービスに対するアクセス許可が必要です。
+ このロールの推奨設定には、EKS Auto Mode のさまざまな機能に関連する複数の AWS マネージド IAM ポリシーが含まれます。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
クラスター IAM ロールと AWS マネージド IAM ポリシーの詳細については、次を参照してください。
+ [Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)
Kubernetes アクセスの詳細については、次を参照してください。
+ [アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)
## ノード の IAM ロール
ノード IAM ロールは、Kubernetes クラスター内のワーカーノードのアクセス許可を管理するために Amazon EKS が使用する AWS Identity and Access Management (IAM) ロールです。このロールは、Kubernetes ノードとして実行されている EC2 インスタンスに、AWS サービスおよびリソースを操作するのに必要なアクセス許可を付与し、EKS アクセスエントリにより Kubernetes RBAC アクセス許可が付与されて自動的に設定されます。
+ AWS IAM ポリシーをこのロールにアタッチする必要があります。
+ EKS Auto Mode は、EKS アクセスエントリを使用して、このロールに Kubernetes RBAC アクセス許可を自動的にアタッチします。
+ AWS では、このロールの名前を `AmazonEKSAutoNodeRole` とすることをお勧めします。
+ EKS Auto Mode を使用する場合、AWS では AWS アカウントごとに 1 つのノード IAM ロールを作成することをお勧めします。
+ このロールには制限されたアクセス許可があります。その主なアクセス許可には、Pod Identity ロールの引き受け、ECR からのイメージのプルなどがあります。
+ AWS では、以下の AWS マネージド IAM ポリシーをお勧めします。
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
クラスター IAM ロールと AWS マネージド IAM ポリシーの詳細については、次を参照してください。
+ [Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [Amazon EKS ノードの IAM ロール](create-node-role.md)
Kubernetes アクセスの詳細については、次を参照してください。
+ [アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)
## サービスリンクロール
Amazon EKS は、特定のオペレーションにサービスリンクロール (SLR) を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
AWS では SLR が自動的に作成および設定されます。先に関連リソースを削除した後にのみ、SLR を削除できます。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
SLR ポリシーは、EC2 リソース (インスタンス、ネットワークインターフェイス、セキュリティグループ)、ELB リソース (ロードバランサー、ターゲットグループ)、CloudWatch 機能 (ログ記録とメトリクス)、「eks」というプレフィックスが付いた IAM ロールなどのコアインフラストラクチャコンポーネントを監視および削除する Amazon EKS アクセス許可を付与します。また、VPC/ホストゾーンの関連付けによるプライベートエンドポイントネットワーキングを有効にし、EKS タグ付きリソースの EventBridge モニタリングとクリーンアップのためのアクセス許可を備えています。
詳細については、以下を参照してください。
+ [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## EKS Auto リソースのカスタム AWS タグ
デフォルトでは、EKS Auto Mode に関連するマネージドポリシーでは、ユーザー定義タグを Auto Mode でプロビジョニングされた AWS リソースに適用することはできません。ユーザー定義タグを AWS リソースに適用する場合は、AWS リソースのタグを作成および変更するのに十分なアクセス許可を持つクラスター IAM ロールに追加のアクセス許可をアタッチする必要があります。以下は、無制限のタグ付けアクセスを許可するポリシーの例です。
### カスタムタグポリシーの例を表示する
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## アクセスポリシーのリファレンス
EKS Auto Mode で使用される Kubernetes アクセス許可の詳細については、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
# EKS 自動モードl での VPC ネットワーキングとロードバランシングの説明
このトピックではEKS 自動モードl で Virtual Private クラウド (VPC ネットワーキングおよびロードバランシング機能を設定する方法について説明します。EKS Auto Mode はほとんどのネットワークコンポーネントを自動的に管理しますが、`NodeClass` リソースとロードバランサーの注釈を使用してクラスターのネットワーキング設定の特定の側面をカスタマイズできます。
EKS 自動モードl を使用すると、AWS でクラスターの VPC Container Network Interface (CNI 設定とロードバランサーのプロビジョニングが管理されます。`NodeClass` オブジェクトを定義し、サービスリソースとイングレスリソースに特定の注釈を適用することで、EKS Auto Mode が提供する自動運用モデルを維持しながら、ネットワーキング動作に関与することができます。
## ネットワーク機能
EKS Auto Mode には、ノードとポッドのネットワークを処理する新しいネットワーク機能があります。この機能は、`NodeClass` Kubernetes オブジェクトを作成することで設定できます。
以前の AWS VPC CNI の設定オプションは EKS Auto Mode には適用されません。
### `NodeClass` を使用したネットワークの設定
EKS Auto Mode の `NodeClass` リソースを使用すると、ネットワーク機能の特定の側面をカスタマイズできます。`NodeClass` を使用すると、セキュリティグループ選択の指定、VPC サブネット間のノード配置の制御、SNAT ポリシーの設定、ネットワークポリシーの設定、ネットワークイベントのログ記録の有効化を行うことができます。このアプローチはEKS 自動モードl の自動運用モデルを維持しながら、ネットワークのカスタマイズで柔軟性が得られます。
`NodeClass` を使用して以下のことができます。
+ ノードのセキュリティグループを選択する
+ VPC サブネットにノードを配置する方法を制御する
+ ノード SNAT ポリシーを `random` または `disabled` に設定する
+ 以下を含む Kubernetes *ネットワークポリシー*を有効にする。
+ ネットワークポリシーを「デフォルトで拒否」または「デフォルトで許可」に設定する
+ ファイルへのネットワークイベントのログ記録を有効にする。
+ 異なるサブネットにポッドをアタッチして、ノードトラフィックからポッドトラフィックを分離する。
[Amazon EKS ノードクラス の作成](create-node-class.md)方法を参照してください。
### 考慮事項
EKS 自動モードl は以下をサポートしています：
+ EKS ネットワークポリシー。
+ Kubernetes ポッドの `HostPort` および `HostNetwork` オプション。
+ パブリックサブネットまたはプライベートサブネットのノードとポッド。
+ ノードでの DNS クエリキャッシュ。
EKS 自動モードl は以下をサポート**していません**：
+ ポッドあたりのセキュリティグループ (SGPP)。Auto Mode で個別のセキュリティグループをポッドトラフィックに適用するには、代わりに `NodeClass` で `podSecurityGroupSelectorTerms` を使用します。詳細については、「[ポッドのサブネットとセキュリティグループを分離する](create-node-class.md#pod-subnet-selector)」を参照してください。
+ `ENIConfig` のカスタムネットワーキング。ポッドを複数のサブネットに配置することも、[ポッドのサブネットとセキュリティグループを分離する](create-node-class.md#pod-subnet-selector) を使用してノードトラフィックから排他的に分離することもできます。
+ ウォーム IP、ウォームプレフィックス、ウォーム ENI 設定。
+ 最小 IP ターゲット設定。
+ オープンソース AWS VPC CNI でサポートされているその他の設定。
+ conntrack タイマーのカスタマイズなどのネットワークポリシー設定 (デフォルトは 300 秒)。
+ CloudWatch へのネットワークイベントログのエクスポート。
### ネットワークリソース管理
EKS Auto Mode では、NodeClass リソースのネットワーク設定をモニタリングすることで、プレフィックス、IP アドレス指定、ネットワークインターフェイス管理を処理します。このサービスでは、次のいくつかの主要なオペレーションが自動的に実行されます。
**プレフィックスの委任**
EKS 自動モードは、デフォルトでポッドネットワークにプレフィックス委任 (/28 プレフィックス) を使用し、IP リソースのウォームプールを事前定義されたとおりに維持し、スケジュールされたポッドの数に基づいてスケールします。ポッドサブネットの断片化が検出されると、自動モードはセカンダリ IP アドレス (/32) をプロビジョニングします。このデフォルトのポッドネットワークアルゴリズムにより、自動モードはインスタンスタイプごとにサポートされている ENI と IP の数に基づいてノードあたりの最大ポッド数を計算します (断片化の最悪のケースを想定)。インスタンスタイプあたりの ENI と IP の最大数の詳細については、「EC2 ユーザーガイド」の「[ネットワークインターフェイスあたりの最大 IP アドレス数](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)」を参照してください。新世代 (Nitro v6 以降) のインスタンスファミリーでは通常、インスタンスタイプあたりの ENI と IP の数が増加しており、自動モードはそれに応じて最大ポッド数の計算を調整します。
IPv6 クラスターの場合、プレフィックス委任のみが使用され、自動モードは常にノードあたりのポッド数を最大 110 に制限しています。
**クールダウン管理**
このサービスでは、使用されなくなったプレフィックスまたはセカンダリ IPv4 アドレスのクールダウンプールを実装します。クールダウン期間が終了すると、これらのリソースは VPC に解放されます。ただし、こうしたリソースは、クールダウン期間にポッドで再利用されると、クールダウンプールから復元されます。
**IPv6 のサポート**
IPv6 クラスターの EKS Auto Mode では、プライマリネットワークインターフェイスのノードごとに `/80` IPv6 プレフィックスをプロビジョニングします。`podSubnetSelectorTerms` を使用する場合、プレフィックスは代わりにポッドサブネットのセカンダリネットワークインターフェイスに割り当てられます。
また、すべてのネットワークインターフェイスの適切な管理とガベージコレクションを確実に行います。
## 負荷分散
EKS 自動モードl でプロビジョニングされた AWS 弾性ロードバランサー はサービスリソースとイングレスリソースの注釈を使用して設定します。
詳細については「[IngressClass を作成して Application Load Balancer を設定する](auto-configure-alb.md)」または「[サービス注釈を使用して Network Load Balancer を設定する](auto-configure-nlb.md)」を参照してください。
### EKS 自動モードl によるロードバランシングに関する考慮事項
+ デフォルトのターゲットモードは IP モードであり、インスタンスモードではありません。
+ EKS 自動モードl はネットワークロードバランサー のセキュリティグループモードのみをサポートします。
+ AWS はセルフマネージド AWS ロードバランサーコントローラー から EKS 自動モードl による管理へのロードバランサーの移行をサポートしていません。
+ `TargetGroupBinding` 仕様の `networking.ingress.ipBlock` フィールドはサポートされていません。
+ ワーカーノードがカスタムセキュリティグループ (`eks-cluster-sg- ` 命名パターンではない) を使用している場合、クラスターロールには追加の IAM アクセス許可が必要です。デフォルトの EKS マネージドポリシーではEKS による `eks-cluster-sg-` という名前のセキュリティグループの変更のみを許可します。カスタムセキュリティグループを変更する許可がないと、EKS は ALB/NLB トラフィックがポッドに到達できるようにするのに必要な進入ルールを追加できません。
#### CoreDNS に関する考慮事項
EKS 自動モードは、クラスター内で DNS を解決する場合に、従来の CoreDNS デプロイを使用しません。代わりに、自動モードノードが、各ノードでシステムサービスとして直接実行される CoreDNS を使用します。従来のクラスターを自動モードに移行する場合、ワークロードを自動モードノードに移動したら、クラスターから CoreDNS デプロイを削除できます。
**重要**
自動モードノードと非自動モードノードの両方でクラスターを維持する場合は、CoreDNS デプロイを保持する必要があります。非自動モードノードは、自動モードが備えるノードレベルの DNS サービスにアクセスできないため、従来の CoreDNS ポッドがないと DNS を解決できません。
# EKS Auto Mode のオブザーバビリティ
この章では、Amazon EKS Auto Mode クラスターのオブザーバビリティオプションについて説明します。
**Topics**
+ [EKS Auto の AWS マネージドコンポーネントログにアクセスする](auto-managed-component-logs.md)
# EKS Auto の AWS マネージドコンポーネントログにアクセスする
EKS Auto Mode から AWS マネージドコンポーネントログにアクセスして、クラスターオペレーションをより詳細に観察できます。EKS Auto Mode は、次のソースのログをサポートします。
+ コンピューティングの自動スケーリング – Karpenter
+ ブロックストレージ – EBS CSI
+ ロードバランシング – AWS Load Balancer Controller
+ ポッドネットワーク – VPC CNI IP アドレス管理
ログは、任意の[送信先](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)に配信できます。
EKS Auto クラスターを作成するときは、コントロールプレーンのログ記録 (API サーバー、監査、認証、コントローラーマネージャー、スケジューラ) を有効にするオプションがあります。EKS Auto マネージドコンポーネントログ (コンピューティング、ブロックストレージ、ロードバランシング、IPAM など) には、ログ配信による個別の設定が必要です。
## ログ配信の設定
EKS Auto Mode クラスターの AWS マネージドコンポーネントログ配信を設定するには、Amazon CloudWatch Logs API を使用します。詳細な設定手順については、「Amazon CloudWatch Logs ユーザーガイド」の「[Enabling logging from AWS services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)」を参照してください。各自動モード機能は、個々の CloudWatch Vended Logs 配信ソースとして設定でき、アクセスするログを選択できます。
EKS 自動モードでは次のログタイプがサポートされています。
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Amazon CloudWatch API の使用
ログ記録の設定には次の 3 つのステップが必要です。
1. CloudWatch PutDeliverySource API を使用して機能の配信ソースを作成する
1. PutDeliveryDestination を使用して送信先を作成する
1. CreateDelivery を使用して送信元と送信先を接続する配信を作成する
CloudWatch PutDeliveryDestination API の deliveryDestinationConfiguration オブジェクトを使用して、Auto Mode のログの送信先の詳細を設定できます。CloudWatch ロググループ、S3 バケット、または Kinesis Data Firehose 配信ストリームのいずれかの ARN を取得します。
複数の配信を作成することで、1 つの Auto Mode 機能 (配信ソース) から複数の送信先にログを送信するよう設定できます。あるいは複数の配信の作成により、複数の配信ソースから同じ送信先にログを送信するように設定することもできます。
### IAM アクセス許可
選択した送信先によっては、ログ配信が成功するように CloudWatch ロググループ、S3 バケット、および Kinesis Data Firehose の IAM ポリシーまたはロールを設定する必要がある場合があります。さらに、AWS アカウント間でログを送受信する場合は、PutDeliveryDestinationPolicy API を使用して、送信先への配信を許可する IAM ポリシーを設定する必要があります。詳細については、「[CloudWatch Vended Logs permissions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs)」のドキュメントを参照してください。
## ログの表示
ログ配信が設定されると、ログは指定された送信先に配信されます。ログにアクセスする方法は、選択した送信先タイプによって異なります。
+ **CloudWatch Logs** – CloudWatch Logs コンソールでログを表示する、AWS CLI コマンドを使用する、または CloudWatch Logs Insights でクエリを実行する
+ **Amazon S3** – S3 コンソール、AWS CLI、または Amazon Athena などの分析ツールを使用して、S3 バケット内のオブジェクトとしてログにアクセスする
+ **Amazon Data Firehose** – ログは、設定された Firehose ターゲット (S3、OpenSearch Service、Redshift など) にストリーミングされます。
## 料金
CloudWatch Vended Logs の料金は、選択した送信先に基づいてログの配信とストレージに適用されます。CloudWatch Vended Logs は、標準の CloudWatch Logs と比較して、組み込みの AWS 認証と認可により、信頼性が高く安全なログ配信を低価格で実現します。詳細については、「[CloudWatch 料金ページのVended Logs セクション](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
### 関連リソース
+ [Amazon EKS コントロールプレーンのログ記録](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ CloudWatch Logs API リファレンスの [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)
+ CloudWatch Logs API リファレンスの [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)
+ CloudWatch Logs API リファレンスの [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)
# EKS 自動モードl のトラブルシューティング
EKS 自動モードl ではAWS が AWS アカウント内の EC2 インスタンスに対してより多くの責任を負います。EKS はノード上のコンテナランタイム、ノード上のオペレーティングシステム、および特定のコントローラーに対して責任を負います。これにはブロックストレージコントローラー、ロードバランシングコントローラー、コンピューティングコントローラーなどがあります。
ノードのトラブルシューティングにはAWS API および Kubernetes API を使用する必要があります。次のようにできます：
+ Kubernetes `NodeDiagnostic` リソースを使用し、[ノードモニタリングエージェント](#auto-node-monitoring-agent)を使用することでノードログを取得します。詳細な手順については「[kubectl と S3 を使用してマネージドノードのノードログを取得する](auto-get-logs.md)」を参照してください。
+ AWS EC2 CLI コマンド `get-console-output` を使用して、ノードからコンソール出力を取得します。詳細な手順については「[AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する](#auto-node-console)」を参照してください。
+ Kubernetes *デバッグコンテナ*を使用してノードログを取得します。詳細な手順については「[*デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する](#auto-node-debug-logs)」を参照してください。
**注記**
EKS 自動モードl は EC2 マネージドインスタンスを使用します。SSH による場合を含め、EC2 マネージドインスタンスに直接アクセスすることはできません。
EKS Auto Mode コンポーネントに固有の解決策がある、次のような問題が発生する可能性があります。
+ Auto Mode ノードにスケジュールされていない Pod が `Pending` 状態でスタックする。解決策については、「[Auto Mode ノードにスケジュールできない Pod のトラブルシューティング](#auto-troubleshoot-schedule)」を参照してください。
+ EC2 マネージドインスタンスが Kubernetes ノードとしてクラスターに参加しない。解決策については、「[クラスターに参加しないノードのトラブルシューティング](#auto-troubleshoot-join)」を参照してください。
+ EKS Auto Mode に含まれているコントローラーを使用する `NodePools`、`PersistentVolumes`、`Services` に関するエラーと問題。解決策については、「[Auto Mode に含まれているコントローラーのトラブルシューティング](#auto-troubleshoot-controllers)」を参照してください。
+ 強化された Pod のセキュリティにより、Pod 間でボリュームを共有できない。解決策については、「[Pod 間でボリュームを共有する](#auto-troubleshoot-share-pod-volumes)」を参照してください。
EKS Auto Mode コンポーネントのトラブルシューティングには、次の方法を使用できます。
+ [AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する](#auto-node-console)
+ [*デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する](#auto-node-debug-logs)
+ [AWS コンソールで EKS 自動モードl に関連付けられたリソースを表示する](#auto-node-ec2-web)
+ [AWS アカウントの IAM エラーを表示します](#auto-node-iam)
+ [`VPC Reachability Analyzer` でノード接続の問題を検出する](#auto-node-reachability)
## ノードモニタリングエージェント
EKS 自動モードl には Amazon EKS ノードモニタリングエージェントが備わっています。このエージェントを使用して、ノードに関するトラブルシューティングとデバッグの情報を表示できます。ノードモニタリングエージェントはKubernetes `events` とノードの `conditions` を発行します。詳細については「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
## AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する
この手順はブートタイムまたはカーネルレベルの問題のトラブルシューティングに役立ちます。
まず、ワークロードに関連付けられたインスタンスの EC2 インスタンス ID を決定する必要があります。次に、AWS CLI を使用してコンソール出力を取得します。
1. `kubectl` がインストールされ、クラスターに接続されていることを確認します
1. (任意 Kubernetes デプロイの名前を使用して、関連するポッドを一覧表示します。
```
kubectl get pods -l app=
```
1. Kubernetes ポッドの名前を使用して、関連付けられたノードの EC2 インスタンス ID を決定します。
```
kubectl get pod -o wide
```
1. EC2 インスタンス ID を使用してコンソール出力を取得します。
```
aws ec2 get-console-output --instance-id --latest --output text
```
## *デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する
EKS Auto Mode ノードからログを取得するために推奨される方法は、`NodeDiagnostic` リソースを使用することです。手順については、「[kubectl と S3 を使用してマネージドノードのノードログを取得する](auto-get-logs.md)」を参照してください。
ただし、`kubectl debug node` コマンドを使用してインスタンスからログをライブストリーミングすることができます。このコマンドにより、デバッグするノードで新しい Pod が起動されて、インタラクティブに使用することができます。
1. デバッグコンテナを起動します。次のコマンドは、ノードのインスタンス ID に `i-01234567890123456` を使用し、インタラクティブな使用のために `-it` で `tty` を割り当てて `stdin` をアタッチし、kubeconfig ファイルの `sysadmin` プロファイルを使用します。
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
出力例は次のとおりです。
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. シェルから、`nsenter` コマンドを提供する `util-linux-core` をインストールできるようになりました。`nsenter` を使用してホスト上の PID 1 (`init`) のマウント名前空間を入力し、`journalctl` コマンドを実行して `kubelet` からログをストリーミングします。
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
セキュリティのため、Amazon Linux コンテナイメージはデフォルトでは多くのバイナリをインストールしません。`yum whatprovides` コマンドを使用して、特定のバイナリを提供するためにインストールする必要があるパッケージを識別できます。
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## AWS コンソールで EKS 自動モードl に関連付けられたリソースを表示する
AWS コンソールを使用して、EKS 自動モードl クラスターに関連付けられているリソースのステータスを表示できます。
+ [EBS ボリューム](https://console.aws.amazon.com/ec2/home#Volumes)
+ タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl ボリュームを表示します
+ [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl ロードバランサーを表示します
+ [EC2 インスタンス](https://console.aws.amazon.com/ec2/home#Instances)
+ タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl インスタンスを表示します
## AWS アカウントの IAM エラーを表示します
1. クラウドTrail コンソールに移動します
1. 左側のナビゲーションペインで [イベント履歴] を選択します
1. 次のエラーコードフィルターを適用します：
+ アクセス拒否
+ 不正操作
+ 無効なクライアントトークンID
EKS クラスターに関連するエラーを探します。エラーメッセージを使用して、EKS アクセスエントリ、クラスター IAM ロール、またはノード IAM ロールを更新します。EKS Auto Mode に対するアクセス許可が付与された状態で、これらのロールを新しいポリシーにアタッチすることが必要になる場合があります。
## Auto Mode ノードにスケジュールできない Pod のトラブルシューティング
ポッドが `Pending` 状態のままになり、Auto Mode ノードにスケジュールされない場合は、ポッドまたはデプロイマニフェストに `nodeSelector` が含まれているかどうかを確認します。`nodeSelector` が存在する場合は、EKS Auto Mode によって作成されたノードでスケジュールされる `eks.amazonaws.com/compute-type: auto` が使用されていることを確認します。EKS Auto Mode で使用されるノードラベルの詳細については、「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。
## クラスターに参加しないノードのトラブルシューティング
EKS Auto Mode は、クラスターエンドポイントやクラスター証明機関 (CA) などの、クラスターに参加するための正しい情報を使用して新しい EC2 インスタンスを自動的に設定します。しかし、それでもこれらのインスタンスがノードとして EKS クラスターに参加できない場合があります。次のコマンドを実行して、クラスターに参加しなかったインスタンスを特定します。
1. `kubectl get nodeclaim` を実行して、`NodeClaims` が `Ready = False` であるかどうかを確認します。
```
kubectl get nodeclaim
```
1. `kubectl describe nodeclaim ` を実行して、**[ステータス]** でノードがクラスターに参加できない問題を見つけます。
```
kubectl describe nodeclaim
```
**一般的なエラーメッセージ：**
`Error getting launch template configs`
デフォルトのクラスター IAM ロールのアクセス許可を使用して `NodeClass` でカスタムタグを設定する場合、このエラーが表示されることがあります。「[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)」を参照してください。
`Error creating fleet`
EC2 API から `RunInstances` コールを呼び出すと、認可の問題が発生する可能性があります。AWS CloudTrail でエラーを確認し、必要な IAM アクセス許可については「[Amazon EKS 自動モードl クラスター IAM ロール](auto-cluster-iam-role.md)」を参照してください。
### `VPC Reachability Analyzer` でノード接続の問題を検出する
**注記**
VPC Reachability Analyzer を実行する分析ごとに課金されます。料金の詳細については、「[Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/)」を参照してください。
インスタンスがクラスターに参加しない理由の 1 つは、API サーバーに到達できないネットワーク接続の問題です。この問題を診断するために、[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用して、クラスターに参加できないノードと API サーバー間の接続の分析を実行することができます。次の 2 つの情報が必要になります。
+ クラスターに参加できないノードの**インスタンス ID**
+ **Kubernetes API サーバーエンドポイント**の IP アドレス
**インスタンス ID** を取得するには、クラスターにワークロードを作成して、EKS Auto Mode で EC2 インスタンスを起動する必要があります。これにより、インスタンス ID を持つ `NodeClaim` オブジェクトもクラスター内に作成されます。`kubectl get nodeclaim -o yaml` を実行して、クラスター内のすべての `NodeClaims` を出力します。各 `NodeClaim` にはインスタンス ID がフィールドとして含まれ、providerID にも再度含まれています。
```
kubectl get nodeclaim -o yaml
```
出力例は次のとおりです。
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
**Kubernetes API サーバーエンドポイント**は、`kubectl get endpoint kubernetes -o yaml` を実行して判断できます。このアドレスは addresses フィールドにあります。
```
kubectl get endpoints kubernetes -o yaml
```
出力例は次のとおりです。
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
これら 2 つの情報を使用して分析を実行できます。まず、AWS マネジメントコンソールで VPC Reachability Analyzer に移動します。
1. [パスを作成および分析] をクリックします
1. 分析の名前を指定します (例: 「Node Join Failure」)
1. [ソースタイプ] には [インスタンス] を選択します
1. 障害が発生したノードのインスタンス ID を [ソース] として入力します
1. [パスの送信先] に [IP アドレス] を選択します
1. API サーバーの IP アドレスの 1 つを [送信先アドレス] として入力します
1. [追加のパケットヘッダーの設定セクション] を展開します
1. [送信先ポート] に 443 と入力します
1. まだ選択されていない場合は、[プロトコル] を [TCP] として選択します
1. [パスを作成および分析] をクリックします
1. 分析の完了には数分かかることがあります。分析結果で到達可能性の失敗が示された場合は、ネットワークパスのどこで障害が生じたかが示され、問題を解決することができます。
## Pod 間でボリュームを共有する
EKS Auto Mode ノードは、SELinux の強制モードで設定され、同じノードで実行されている Pod 間の分離を強化します。SELinux を有効にすると、特権のないほとんどのポッドに、独自のマルチカテゴリセキュリティ (MCS) ラベルが自動的に適用されます。この MCS ラベルは Pod ごとに一意であり、1 つの Pod のプロセスで他の Pod またはホストのプロセスを操作できないように設計されています。ラベル付き Pod がルートとして実行され、ホストファイルシステムにアクセスできる場合でも、ファイルの操作、ホストでの機密システムの呼び出し、コンテナランタイムへのアクセス、kubelet のシークレットキーマテリアルの取得を行うことはできません。
このため、Pod 間でデータを共有しようとすると問題が発生する可能性があります。例えば、アクセスモードが `ReadWriteOnce` の `PersistentVolumeClaim` でも、複数の Pod がボリュームに同時にアクセスすることはできません。
Pod 間でこの共有を有効にするには、Pod の `seLinuxOptions` を使用して、これらの Pod に同じ MCS ラベルを設定します。この例では、Pod に 3 つのカテゴリ (`c123,c456,c789`) を割り当てます。2 つのカテゴリが割り当てられるだけであるため、これによりノード上の Pod に自動的に割り当てられたカテゴリとの競合が発生することはありません。
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## コントロールプレーンログで Karpenter イベントを表示する
コントロールプレーンログが有効になっている EKS クラスターの場合、ログをクエリすることで Karpenter のアクションと意思決定プロセスに関するインサイトを得ることができます。これは、ノードのプロビジョニング、スケーリング、終了に関連する EKS オートモードの問題のトラブルシューティングに特に役立ちます。Karpenter 関連のイベントを表示するには、次の CloudWatch Logs Insights クエリを使用します。
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
このクエリは、kube-apiserver 監査ログ内の特定の [Karpenter 関連イベント](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)をフィルタリングします。イベントには、さまざまな中断状態、スケジュールの失敗、容量の問題、ノード関連の問題が含まれます。これらのログを分析することで、以下をよりよく理解できます。
+ Karpenter が特定のアクションを実行する理由。
+ ノードの適切なプロビジョニング、スケーリング、または終了を妨げる問題。
+ インスタンスタイプで発生する可能性のある容量または互換性の問題。
+ 中断、削除、終了などのノードのライフサイクルイベント。
このクエリを使用するには:
1. CloudWatch コンソールに移動する
1. 左のナビゲーションペインから、[Logs Insights] を選択する
1. EKS クラスターのコントロールプレーンログのロググループを選択する
1. クエリエディタにそのクエリを貼り付ける
1. 必要に応じて時間範囲を調整する
1. クエリを実行します
その結果、Karpenter 関連のイベントのタイムラインが表示され、問題のトラブルシューティングやクラスター内の EKS オートモードの動作の理解に役立ちます。特定のノードで Karpenter アクションを確認するには、前述のクエリにインスタンス ID を指定する以下の行フィルターを追加できます。
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**注記**
このクエリを使用するには、EKS クラスターでコントロールプレーンのログ記録を有効にする必要があります。これをまだ実行していない場合は、[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md) を参照してください。
## Auto Mode に含まれているコントローラーのトラブルシューティング
コントローラーに問題がある場合は以下について調べる必要があります：
+ そのコントローラーに関連付けられているリソースが適切にフォーマットされ、有効であるかどうか。
+ AWS IAM リソースおよび Kubernetes RBAC リソースがクラスター用に適切に設定されているかどうか。詳細については、「[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)」を参照してください。
## 関連リソース
高度なトラブルシューティング手順については、AWS re:Post の以下の記事を参照してください。
+ [EKS 自動モードでよくあるスケールの問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [Amazon EKS 自動モードでカスタムノードプールとノードクラスのプロビジョニングに関する問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [EKS 自動モードに組み込みのノードプールでステータスが不明になる問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# EKS Auto Mode のリリースノートを確認する
このページでは、Amazon EKS Auto Mode の更新について説明します。ここでは、機能、バグ修正、既知の問題、廃止された機能に関するお知らせを定期的に確認できます。
この特定のドキュメントページへのすべてのソースファイルの変更通知を受け取るには、RSS リーダーを使用して次の URL をサブスクライブできます。
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2026 年 2 月 2 日
**機能**: EKS Auto Mode IPv6 クラスター内の IPv6 ポッドからの v4Egress トラフィックを無効にできるサポートが追加されました。詳細については、「[IPv6 クラスター内の IPv6 ポッドからの IPv4 egress を無効にする。](create-node-class.md#enableV4Egress)」を参照してください。
## 2025 年 12 月 19 日
**機能**: Auto ノードにプレフィックスの代わりにセカンダリ IP アドレスをプロビジョニングするセカンダリ IP モードのサポートが追加されました。このモードは、1 つのセカンダリ IP を MinimalIPTarget として維持することで、セカンダリ IP またはプレフィックスをウォームアップする必要のないお客様の IP リソースを節約します。詳細については、「[ノードクラスの指定](create-node-class.md#auto-node-class-spec)」および「[ポッドのセカンダリ IP モード](create-node-class.md#secondary-IP-mode)」を参照してください。
## 2025 年 11 月 19 日
**機能**: ローカル NVMe ストレージにより、G、P、および Trn ファミリーインスタンスの Seekable OCI (SOCI) 並列プルと解凍を可能にしました。SOCI 並列プルと解凍は、これらのインスタンスファミリーが EKS 自動モードであれば常に使用されるため、わざわざ設定を変更しなくても有効になります。SOCI の詳細については、「[リリースブログ](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/)」を参照してください。
## 2025 年 11 月 19 日
**機能**: 静的キャパシティノードプールを新たにサポートして、決まった数のノードを維持できるようにしました。詳細については、「[EKS Auto Mode での静的キャパシティノードプール](auto-static-capacity.md)」を参照してください。
## 2025 年 10 月 23 日
**機能:** クラスターが米国リージョンにあるユーザーは、NodeClass 定義に `spec.advancedSecurity.fips` を指定することで、FIPS 互換 AMI の使用をリクエストできるようになりました。
## 2025 年 10 月 1 日
**機能:** EKS 自動モードで、AWS Local Zone へのノードのデプロイがサポートされるようになりました。詳細については、「[Local Zone に EKS 自動モードノードをデプロイする](auto-local-zone.md)」を参照してください。
## 2025 年 9 月 30 日
**機能:** `spec.role` フィールドから相互に排他的である NodeClass `spec.instanceProfile` に instanceProfile のサポートを追加しました。
## 2025 年 9 月 29 日
DRA は、現在 EKS 自動モードではサポートされていません。
## 2025 年 9 月 10 日
**内部改善:** 自動モードコンピューティングコントローラーから発生したイベントは、`karpenter` ではなく `eks-auto-mode/compute` という名前を使用するようになります。
## 2025 年 8 月 24 日
**バグ修正:** VPC に使用されている DHCP オプションセットでカスタムドメイン名に大文字が含まれていた場合、無効なホスト名が生成されてノードがクラスターに参加できませんでした。この問題を解決し、ドメイン名に大文字が含まれていても正しく機能するようになりました。
## 2025 年 8 月 15 日
**バグ修正:** Pod Identity Agent は、IPv4 EKS クラスター内の IPv4 リンクローカルアドレスのみをリッスンします。これにより、Pod が IPv6 アドレスに到達できないという問題を回避します。
## 2025 年 8 月 6 日
**機能:** EKS オートモードノードにパブリック IP アドレスが割り当てられないようにするための新しい設定を NodeClass `spec.advancedNetworking.associatePublicIPAddress` に追加しました。
## 2025 年 6 月 30 日
**機能:** Auto Mode NodeClass は設定されたカスタム KMS キーを使用して、読み取り/書き込みデータボリュームに加えて、インスタンスの読み取り専用ルートボリュームも暗号化するようになりました。以前、カスタム KMS キーはデータボリュームの暗号化にのみ使用されていました。
## 2025 年 6 月 20 日
**機能:** EC2 オンデマンドキャパシティ予約 (ODCR) へのワークロードのデプロイを制御するためのサポート。オプションのキー `capacityReservationSelectorTerms` が NodeClass に追加され、ワークロードが使用する ODCR を明示的に制御できます。詳細については、「[EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md)」を参照してください。
## 2025 年 6 月 13 日
**機能:** `NodeClass` での個別のポッドサブネットのサポート。これにより、オプションのキー ``podSubnetSelectorTerms` と `podSecurityGroupSelectorTerms` が追加され、ポッドのサブネットとセキュリティグループが設定されます。詳細については、「[ポッドのサブネットとセキュリティグループを分離する](create-node-class.md#pod-subnet-selector)」を参照してください。
## 2025 年 4 月 30 日
**機能:** `NodeClass` でのフォワードネットワークプロキシのサポート。これにより、HTTPS プロキシを設定するためのオプションキー `advancedNetworking` が追加されます。詳細については、「[ノードクラスの指定](create-node-class.md#auto-node-class-spec)」を参照してください。
## 2025 年 4 月 18 日
**機能:** ユニキャスト DNS を介したローカルドメイン (通常はマルチキャスト DNS 用に予約) の解決をサポートします。
## 2025 年 4 月 11 日
**機能:** `certificateBundles` と `ephemeralStorage.kmsKeyID` を `NodeClass` に追加しました。詳細については、「[ノードクラスの指定](create-node-class.md#auto-node-class-spec)」を参照してください。
**機能:** イメージのプル速度が向上しました。特に、高速なイメージ解凍を活用できるローカルインスタンスストレージを持つインスタンスタイプで、この効果を得られます。
**バグ修正:** FailedCreatePodSandBox のエラー原因である競合状態を解決しました。エラー詳細: Error while dialing: dial tcp 127.0.0.1:50051: connect: connection refused to sometimes occur for Pods scheduling to a Node immediately at startup
## 2025 年 4 月 4 日
**機能:** `registryPullQPS` を 5 から 25、`registryBurst` を 10 から 50 に増やして、クライアントで強制されるイメージプルスロットリングを減らします (`Failed to pull image xyz: pull QPS exceeded`)
## 2025 年 3 月 31 日
**バグ修正:** CoreDNS ポッドを Auto Mode ノードで実行している場合に、ノードのポッドからの DNS クエリがノードローカル DNS サーバーではなくその CoreDNS ポッドにヒットする問題を修正しました。Auto Mode ノードのポッドからの DNS クエリは、常にノードローカル DNS に送信されます。
## 2025 年 3 月 21 日
**バグ修正:** Auto Mode ノードは、クラスターに `kube-dns` サービスがインストールされていない場合にも `kube-dns.kube-system.svc.cluster.local` が正しく解決されるようになりました。GitHub の問題 [\$12546](https://github.com/aws/containers-roadmap/issues/2546) に対処します。
## 2025 年 3 月 14 日
**機能**: `IPv6` クラスターで `IPv4` egress が有効になりました。`IPv6` Auto Mode クラスターから送信される `IPv4` トラフィックは、ノードプライマリ ENI の `v4` アドレスに自動的に変換されるようになりました。