**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ノードを使用してコンピューティングリソースを管理する
Kubernetes ノードはコンテナ化されたアプリケーションを実行するマシンです。各ノードには以下のコンポーネントがあります：
+ **[コンテナランタイム](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)** - コンテナの実行を担当するソフトウェア。
+ **[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)** - コンテナが正常で、関連する Pod 内で実行されていることを確認します。
+ **[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)** - Pod との通信を許可するネットワークルールを維持します。
詳細については、Kubernetes ドキュメントの「[ノード](https://kubernetes.io/docs/concepts/architecture/nodes/)」を参照してください。
Amazon EKS クラスターは、任意の [EKS Auto Mode マネージド型ノード](automode.md)、[セルフマネージド型ノード](worker.md)、[Amazon EKS マネージド型ノードグループ](managed-node-groups.md)、[AWS Fargate](fargate.md)、[Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) を組み合わせて、Pod をスケジュールできます。クラスターにデプロイされているノードの詳細については[AWS マネジメントコンソール に Kubernetes リソースを表示する](view-kubernetes-resources.md)を参照してください。
**注記**
ハイブリッドノードを除くノードはクラスターの作成時に選択したサブネットと同じ VPC 内にある必要があります。ただし、ノードは同じサブネット内にある必要はありません。
## コンピューティングオプションの比較
次の表に、要件を満たすための最適なオプションを決定する際に、評価すべき基準をいくつか示します。セルフマネージド型ノードはリストされているすべての条件をサポートするもう 1 つのオプションですが、より多くの手動メンテナンスが必要です。詳細については、「[セルフマネージドノードでノードを自分自身で維持する](worker.md)」を参照してください。
**注記**
Bottlerocket には、この表の一般的な情報と特に異なる点がいくつかあります。詳しくは、GitHub 上で Bottlerocket の[ドキュメント](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md)を参照してください。
| 条件 | EKS マネージド型ノードグループ | EKS 自動モードl | アマゾン EKS ハイブリッドノード |
| --- | --- | --- | --- |
| [AWS アウトポスト](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) にデプロイ可能 | いいえ | いいえ | いいえ |
| [AWS ローカルゾーン](local-zones.md) にデプロイ可能 | はい | いいえ | いいえ |
| Windows を必要とするコンテナを実行できる | はい | いいえ | いいえ |
| Linux を必要とするコンテナを実行可能 | はい | あり | はい |
| インフェクエンティア チップを必要とするワークロードを実行可能 | [はい](inferentia-support.md) – アマゾンリナックス ノードのみ | はい | いいえ |
| GPU を必要とするワークロードを実行可能 | [はい](eks-optimized-ami.md#gpu-ami) – アマゾンリナックス ノードのみ | あり | あり |
| Arm プロセッサを必要とするワークロードを実行可能 | [あり](eks-optimized-ami.md#arm-ami) | あり | あり |
| AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) を実行可能 | あり | はい | いいえ |
| ポッドはCPU、メモリ、ストレージ、およびネットワークリソースを他のポッドと共有します。 | あり | あり | あり |
| Amazon EC2 インスタンスをデプロイおよび管理する必要がある | はい | いいえ - [EC2 マネージドインスタンス](automode-learn-instances.md)について説明します | はい - オンプレミスの物理マシンまたは仮想マシンは選択したツールで管理されます。 |
| Amazon EC2 インスタンスのオペレーティングシステムの保護、保守、パッチ適用を行う必要がある | はい | いいえ | はい – 物理マシンまたは仮想マシンで実行されているオペレーティングシステムは選択したツールで管理されます。 |
| ノードをデプロイする時に、追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数 などのブートストラップ引数を提供できます。 | はい – `eksctl`、またはカスタム AMI を含む[起動テンプレート](launch-templates.md)を使用します。 | いいえ - [`NodeClass` を使用してノードを設定します](create-node-class.md) | はい - nodeadm を使用してブートストラップ引数をカスタマイズできます。「[ハイブリッドノード `nodeadm` 参照](hybrid-nodes-nodeadm.md)」を参照してください。 |
| ノードに割り当てられた IP アドレスとは異なる CIDR ブロックから、IP アドレスを Pod に割り当てることができます。 | はい - カスタム AMI の起動テンプレートを使用します。詳細については「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。 | いいえ | はい - 「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。 |
| ノードに SSH 接続可能 | はい | いいえ — [ノードのトラブルシューティング方法について説明します](auto-troubleshoot.md) | はい |
| 独自のカスタム AMI をノードにデプロイ可能 | はい – [起動テンプレート](launch-templates.md)を使用します | いいえ | はい |
| 独自のカスタム CNI をノードにデプロイ可能 | はい – カスタム AMI の[起動テンプレート](launch-templates.md)を使用します | いいえ | はい |
| ノード AMI を自分で更新する必要がある | [はい](update-managed-node-group.md) - アマゾン EKS 最適化 AMI をデプロイした場合、更新が利用可能になると アマゾン EKS コンソールで通知されます。コンソールではワンクリックで更新を実行できます。カスタム AMI をデプロイした場合、更新が利用可能になっても アマゾン EKS コンソールに通知されません。更新は自分で実行する必要があります。 | いいえ | はい - 物理マシンまたは仮想マシンで実行されているオペレーティングシステムは選択したツールで管理されます。「[ハイブリッドノード用のオペレーティングシステムを準備する](hybrid-nodes-os.md)」を参照してください。 |
| ノードの Kubernetes バージョンを自分で更新する必要があります。 | [はい](update-managed-node-group.md) - アマゾン EKS 最適化 AMI をデプロイした場合、更新が利用可能になると アマゾン EKS コンソールで通知されます。コンソールではワンクリックで更新を実行できます。カスタム AMI をデプロイした場合、更新が利用可能になっても アマゾン EKS コンソールに通知されません。更新は自分で実行する必要があります。 | いいえ | はい - 独自のツールまたは `nodeadm` を使用して、ハイブリッドノードのアップグレードを管理します。「[クラスターのハイブリッドノードをアップグレードする](hybrid-nodes-upgrade.md)」を参照してください。 |
| Pod で Amazon EBS ストレージを使用可能 | [あり](ebs-csi.md) | はい。統合された機能として使用できます。[ストレージクラスを作成](create-storage-class.md)する方法について説明します。 | いいえ |
| Pod で Amazon EFS ストレージを使用可能 | [あり](efs-csi.md) | はい | いいえ |
| Pod で Amazon FSx for Lustre ストレージを使用可能 | [あり](fsx-csi.md) | はい | いいえ |
| Network Load Balancer をサービスに使用可能 | [あり](network-load-balancing.md) | あり | はい - ターゲットタイプ `ip` を使用する必要があります。 |
| ポッドはパブリックサブネットで実行可能 | はい | あり | いいえ - ポッドはオンプレミス環境で実行されます。 |
| それぞれの Pod に、異なる VPC セキュリティグループを割り当て可能 | [はい](security-groups-for-pods.md): Linux ノードのみ | いいえ | いいえ |
| Kubernetes DaemonSets を実行可能 | はい | あり | あり |
| Pod マニフェストで `HostPort` および `HostNetwork` をサポートします | はい | あり | あり |
| AWS が利用可能なリージョン | [すべての アマゾン EKS 対応リージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [すべての アマゾン EKS 対応リージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html) | AWS Govクラウド (米国) リージョンと中国リージョンを除く[Amazon EKS がサポートするすべてのリージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 |
| Amazon EC2 専有ホストでコンテナを実行できます | はい | いいえ | いいえ |
| 料金 | 複数の Pod を実行する Amazon EC2 インスタンスのコスト。詳細については[アマゾン EC2 料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。 | クラスターで EKS 自動モードl が有効になっている場合は自動モードl のコンピューティング機能を使用して起動されたインスタンスに対しては標準の EC2 インスタンス料金に加えて個別の料金がかかります。この金額は起動されたインスタンスタイプとクラスターが配置されている AWS リージョンによって異なります。詳細については「[アマゾン EKS の料金](https://aws.amazon.com/eks/pricing/)」を参照してください。 | ハイブリッドノードの vCPU の 1 時間あたりのコスト。詳細については「[アマゾン EKS の料金](https://aws.amazon.com/eks/pricing/)」を参照してください。 |
# マネージドノードグループを使用してノードライフサイクルを簡素化する
Amazon EKS マネージド型ノードグループは、Amazon EKS Kubernetes クラスターのノード (Amazon EC2 インスタンス) のプロビジョニングとライフサイクル管理を自動化します。
Amazon EKS マネージド型ノードグループでは、Kubernetes アプリケーションを実行するためのコンピューティング性能を提供する Amazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要はありません。1 回の操作で、クラスターのノードを作成、自動的に更新、または終了できます。ノードを更新し、終了させることで、ノードを自動的にドレーンし、アプリケーションを利用できる状態にしておきます。
すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。各ノードグループは、定義された複数のアベイラビリティーゾーンで実行できます。
マネージド型ノードグループは、ノードのヘルスを継続的にモニタリングするノード自動修復をオプションで利用することもできます。検出された問題に自動的に対応し、可能な場合はノードを置き換えます。これにより、最小限の手動操作でクラスターの全体的な可用性が向上します。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
Amazon EKS コンソール、`eksctl`、AWS CLI、AWS API、または AWS CloudFormation を含む Infrastructure as Code ツールを使用し、新規または既存のクラスターにマネージド型ノードグループを追加できます。マネージド型ノードグループの一部として起動されたノードは、自動的に Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) によって自動検出用にタグ付けされます。ノードグループを使用して、Kubernetes ラベルをノードに適用し、いつでも更新できます。
Amazon EKS マネージド型ノードグループの使用に追加料金はかかりません。お支払いいただくのはプロビジョニングした AWS リソースの分だけです。これには、Amazon EC2 インスタンス、Amazon EBS ボリューム、Amazon EKS クラスター時間、その他の AWS インフラストラクチャが含まれます。最低料金や前払いの義務は発生しません。
新しい Amazon EKS クラスターおよびマネージド型ノードグループの使用を開始するには、「[Amazon EKS の使用を開始する – AWS マネジメントコンソール と AWS CLI](getting-started-console.md)」を参照してください。
既存のクラスターにマネージド型ノードグループを追加するには、「[クラスターのマネージドノードグループを作成する](create-managed-node-group.md)」を参照してください。
## マネージド型ノードグループの概念
+ Amazon EKS マネージド型ノードグループは、Amazon EC2 インスタンスを作成し、管理します。
+ すべてのマネージド型ノードは、Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。さらに、Amazon EC2 インスタンスや Auto Scaling グループを含むすべてのリソースは、AWS アカウント内で実行されます。
+ マネージド型ノードグループの Auto Scaling グループは、グループの作成時に指定するすべてのサブネットにまたがります。
+ Amazon EKS は、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) の使用を設定するようにマネージド型ノードグループリソースをタグ付けします。
**重要**
Amazon EBS ボリュームによってバックアップされ、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、`--balance-similar-node-groups` 機能を有効にする必要があります。
+ カスタム起動テンプレートを使用すると、マネージド型ノードをデプロイするときに、柔軟性とカスタマイズのレベルを向上させることができます。例えば、追加の `kubelet` 引数を指定して、カスタム AMI を使用できます。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。マネージド型ノードグループを最初に作成するときにカスタム起動テンプレートを使用しない場合は、自動生成された起動テンプレートを使用できます。自動生成されたテンプレートを手動で変更しないでください。エラーが発生します。
+ Amazon EKS は、マネージド型ノードグループで CVE およびセキュリティパッチの責任共有モデルに従います。マネージド型ノードが Amazon EKS 最適化 AMI を実行する場合、バグや問題が報告されると、Amazon EKS が AMI のパッチ適用バージョンの構築を担当します。修正を公開できます。ただし、これらのパッチが適用された AMI バージョンのマネージド型ノードグループへのデプロイはユーザーが担当します。マネージド型ノードでカスタム AMI を実行する場合、バグや問題が報告され、AMI をデプロイする場合は、ユーザーがパッチ適用バージョンの構築を担当します。詳細については、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。
+ Amazon EKS マネージド型ノードグループは、パブリックサブネットとプライベートサブネットの両方で起動できます。2020 年 4月 22 日 以降にパブリックサブネットでマネージド型ノードグループを起動した場合、インスタンスがクラスターに正常に参加するには、サブネットで `MapPublicIpOnLaunch` を true に設定する必要があります。パブリックサブネットが `eksctl`、または 2020 年 3 月 26 日以降に [Amazon EKS が販売した AWS CloudFormation テンプレート](creating-a-vpc.md)を使用して作成された場合、この設定はすでに true に設定されています。パブリックサブネットが 2020 年 3 月 26 日 より前に作成されている場合は、設定を手動で変更する必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
+ マネージド型ノードグループをプライベートサブネットにデプロイする場合、Amazon ECR にアクセスしてコンテナイメージをプルできることを確認します。これを行うには、NAT ゲートウェイをサブネットのルートテーブルに接続するか、次の [AWS PrivateLink VPC エンドポイント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create)を追加します。
+ Amazon ECR API のエンドポイントインターフェイス — `com.amazonaws.region-code.ecr.api`
+ Amazon ECR Docker レジストリ API のエンドポイントインターフェイス — `com.amazonaws.region-code.ecr.dkr`
+ Amazon S3 ゲートウェイのエンドポイント - `com.amazonaws.region-code.s3`
その他の一般的に使用されるサービスとエンドポイントについては、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
+ マネージドノードグループは、[AWS Outposts](eks-outposts.md) または [AWS Wavelength](https://docs.aws.amazon.com/wavelength/) にはデプロイできません。マネージドノードグループは、[AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) で作成できます。詳細については、「[AWS Local Zones を使用して低レイテンシーの EKS クラスターを起動する](local-zones.md)」を参照してください。
+ 1 つのクラスター内に複数のマネージド型ノードグループを作成できます。例えば、一部のワークロード用に、標準 Amazon EKS 最適化 Amazon Linux AMI を使用するノードグループを作成し、GPU サポートを必要とするワークロード用に GPU バリアントを使用する別のノードグループを作成できます。
+ マネージド型ノードグループで [Amazon EC2 インスタンスのステータスチェック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html)に障害が発生した場合、Amazon EKS は問題の診断に役立つエラーコードを返します。詳細については、「[マネージド型ノードグループのエラー](troubleshooting.md#troubleshoot-managed-node-groups)」を参照してください。
+ Amazon EKS は、マネージド型ノードグループインスタンスに Kubernetes ラベルを追加します。これらの Amazon EKS 提供のラベルには、プレフィックス `eks.amazonaws.com` が付きます。
+ Amazon EKS は、終了または更新時に Kubernetes API を使用してノードを自動的にドレーンします。
+ `AZRebalance` を使用してノードを終了、または目的のノード数を減らす際には、ポッドの停止状態の予算は考慮されません。これらのアクションはノード内にある Pod を削除しようとします。ただし、15 分が経過すると、ノード内のすべての Pod が終了しているかどうかにかかわらず、ノードは終了します。ノードが終了するまでの期間を延長するには、Auto Scaling グループにライフサイクルフックを追加します。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[ライフサイクルフックの追加](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html)」を参照してください。
+ スポット中断通知またはキャパシティリバランス通知を受け取った後、ドレインプロセスを正しく実行するには、`CapacityRebalance` を `true` に設定する必要があります。
+ マネージドノードグループを更新すると、Pod に設定した Pod 中断予算が考慮されます。詳細については、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」を参照してください。
+ Amazon EKS マネージド型ノードグループの使用に、追加料金はかかりません。プロビジョニングした AWS リソースに対してのみ料金が発生します。
+ ノードの Amazon EBS ボリュームを暗号化する場合は、起動テンプレートを使用してノードをデプロイできます。起動テンプレートを使用せずに、暗号化された Amazon EBS ボリュームを持つマネージド型ノードをデプロイするには、アカウントに作成された新しい Amazon EBS ボリュームをすべて暗号化してください。詳細については、*「Amazon EC2 ユーザーガイド*」の「[Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default)」を参照してください。
## マネージド型ノードグループのキャパシティータイプ
マネージド型ノードグループを作成する場合、キャパシティータイプをオンデマンドまたはスポットのいずれかから選択できます。Amazon EKS は、Amazon EC2 Auto Scaling グループを使用して、マネージド型ノードグループをデプロイします。これにはオンデマンドのみか、Amazon EC2 スポットインスタンスのみが含まれます。単一の Kubernetes クラスター内で、耐障害性のあるアプリケーションの Pod をスポットのマネージド型ノードグループにスケジュールし、非フォールトトレラントなアプリケーションの Pod をオンデマンドのノードグループにスケジュールできます。デフォルトでは、マネージド型ノードグループはオンデマンド Amazon EC2 インスタンスをデプロイします。
### オンデマンド
オンデマンドインスタンスでは、長期契約なしで、コンピューティング性能に対して秒単位で支払います。
デフォルトでは、**キャパシティータイプ**を指定しない場合、マネージド型ノードグループはオンデマンドインスタンスでプロビジョニングされます。マネージド型ノードグループは、ユーザーの代わりに Amazon EC2 Auto Scaling グループを次のように設定します。
+ オンデマンドキャパシティーをプロビジョニングするための配分戦略は、`prioritized` に設定されます。マネージド型ノードグループは、API 内部で渡されたインスタンスタイプの優先度を使用して、オンデマンドキャパシティーを満たすときに最初に使用するインスタンスタイプを決定します。例えば、3 つのインスタンスタイプを `c5.large`、`c4.large`、`c3.large` の順序で指定するとします。オンデマンドインスタンスが起動されると、マネージド型ノードグループは `c5.large`、`c4.large`、`c3.large` の順でオンデマンドキャパシティーを満たします。詳しくは、*Amazon EC2 Auto Scaling ユーザーガイド*の [Amazon EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies)を参照してください。
+ Amazon EKS は、キャパシティータイプを `eks.amazonaws.com/capacityType: ON_DEMAND` に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用すると、オンデマンドノードで、ステートフルまたは非フォールトトレラントなアプリケーションをスケジュールできます。
### Spot
Amazon EC2 スポットインスタンスは、オンデマンドの料金から大きな割引で提供される、Amazon EC2 の予備容量です。Amazon EC2 スポットインスタンスは、EC2 から容量の返却を求められると 2 分間の中断通知をもって中断されることがあります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)」を参照してください。Amazon EC2 スポットインスタンスを使用してマネージド型ノードグループを構成し、Amazon EKS クラスターで実行されているコンピューティングノードのコストを最適化できます。
マネージド型ノードグループ内でスポットインスタンスを使用するには、キャパシティータイプを `spot` に設定してマネージド型ノードグループを作成してください。マネージド型ノードグループは、ユーザーの代わりに Amazon EC2 Auto Scaling グループを設定し、次のようなスポットベストプラクティスを適用します。
+ Spot ノードが最適な Spot キャパシティプールにプロビジョニングされるように、割り当て戦略を以下のいずれかに設定します。
+ `price-capacity-optimized` (PCO) – Kubernetes バージョン `1.28` 以降のクラスターに新しいノードグループを作成すると、割り当てストラテジーは `price-capacity-optimized` に設定されます。ただし、Amazon EKS マネージドノードグループが PCO をサポートし始める前に `capacity-optimized` で作成済みのノードグループの割り当て戦略は変更されません。
+ `capacity-optimized` (CO) – Kubernetes バージョン `1.27` 以前のクラスターに新しいノードグループを作成すると、割り当て戦略は `capacity-optimized` に設定されます。
容量を割り当てるために利用可能なスポットキャパシティープールの数を増やすには、複数のインスタンスタイプを使用するようにマネージド型ノードグループを設定します。
+ スポットノードが中断するリスクが高い場合に、Amazon EKS がスポットノードを適切にドレーンおよび再調整して、アプリケーションの中断を最小限に抑えられるように、Amazon EC2 Spot Capacity Rebalancing が有効化されています。詳細については、*Amazon EC2 Auto Scaling ユーザーガイド*の [Amazon EC2 Auto Scaling キャパシティーの再調整](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html)を参照してください。
+ スポットノードが再調整の推奨事項を受け取ると、Amazon EKS は自動的に新しい代替スポットノードの起動を試みます。
+ 代替スポットノードが `Ready` 状態になる前にスポットの 2 分間の中断通知が到着すると、Amazon EKS は再調整に関する推奨事項を受け取ったスポットノードのドレーンを開始します。Amazon EKS はベストエフォートベースでノードをドレインします。そのため、Amazon EKS が既存のノードをドレインする前に、代替ノードがクラスターに参加するのを待機するという保証はありません。
+ 代替スポットノードがブートストラップされ、Kubernetes 上で `Ready` 状態になると、Amazon EKS は再調整に関する推奨事項を受信したスポットノードを遮断し、ドレインします。スポットノードを遮断すると、サービスコントローラーがこのスポットノードに新しいリクエストを送信しないようにします。正常でアクティブなスポットノードのリストからも削除されます。スポットノードをドレインすると、実行中の Pod が適切に削除されます。
+ Amazon EKS は、キャパシティータイプを `eks.amazonaws.com/capacityType: SPOT` に指定しているマネージド型ノードグループ内のすべてのノードに、次の Kubernetes ラベルを追加します。このラベルを使用して、スポットノードで耐障害性のあるアプリケーションをスケジュールできます。
**重要**
EC2 は、スポットインスタンスを終了する 2 分前に[スポットの中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)を発行します。ただし、スポットノード上のポッドは、正常なシャットダウンのために 2 分間すべてを確保できない場合があります。EC2 が通知を発行すると、Amazon EKS がポッドのエビクションを開始するまでに遅延が発生します。エビクションは Kubernetes API サーバーを保護するために順次実行されるため、複数のスポット回収が同時に発生した場合、一部のポッドではエビクション通知の受信が遅れることがあります。特にポッド密度が高いノード上、同時回収中、または長い終了猶予期間を使用している場合、ポッドは終了シグナルを受信せずに強制終了される場合があります。スポットワークロードでは、中断耐性のあるアプリケーションを設計し、30 秒以下の終了猶予期間を使用し、長時間実行される preStop フックを回避し、ポッドエビクションメトリクスをモニタリングして、クラスターで実際に適用される猶予期間を把握することをお勧めします。正常な終了が保証される必要があるワークロードについては、代わりにオンデマンドキャパシティーを使用することをお勧めします。
オンデマンドキャパシティーとスポットキャパシティーのどちらでノードグループをデプロイするかを決定するときは、次の条件を考慮する必要があります。
+ スポットインスタンスは、ステートレスかつフォールトトレラントで、柔軟性の高いアプリケーションに適しています。これには、バッチトレーニングワークロード、機械学習トレーニングワークロード、Apache Spark などのビッグデータ ETL、キュー処理アプリケーション、ステートレス API エンドポイントなどがあります。スポットは Amazon EC2 の予備容量であり、時間の経過とともに変化する可能性があるため、中断されても問題ないワークロードには、スポットキャパシティーを使用することをお勧めします。具体的には、スポット容量は、必要な容量が使用できない期間を許容できるワークロードに適しています。
+ 非フォールトトレラントなアプリケーションには、オンデマンドを使用することをお勧めします。これには、モニタリングツールやオペレーションツールなどのクラスター管理ツール、`StatefulSets` を必要とするデプロイ、データベースなどのステートフルなアプリケーションなどが含まれます。
+ スポットインスタンスの使用中にアプリケーションの可用性を最大化するには、スポットのマネージド型ノードグループが複数のインスタンスタイプを使用するように構成することをお勧めします。複数のインスタンスタイプを使用する場合は、次のルールを適用することをお勧めします。
+ マネージド型ノードグループ内で [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合、同じサイズの vCPU とメモリリソースを持つインスタンスタイプを柔軟に組み合わせて使用することをお勧めします。これは、クラスター内のノードが期待どおりにスケールされるようにするためです。例えば、4 つの vCPU と 8 GiB のメモリが必要な場合は、`c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge`、またはその他の同等なインスタンスタイプを使用してください。
+ アプリケーションの可用性を高めるために、複数のスポットマネージド型ノードグループをデプロイすることをお勧めします。これを行うには、各グループが、同じ vCPU とメモリリソースを持つ、インスタンスタイプの柔軟な組み合わせを使用する必要があります。例えば、4 つの vCPU および 8 GiB のメモリが必要な場合は、`c3.xlarge`、`c4.xlarge`、`c5.xlarge`、`c5d.xlarge`、`c5a.xlarge`、`c5n.xlarge`、または他の同等なインスタンスタイプのマネージド型ノードグループを 1 つ作成し、`m3.xlarge`、`m4.xlarge`、`m5.xlarge`、`m5d.xlarge`、`m5a.xlarge`、`m5n.xlarge`、または他の同等なインスタンスタイプで 2 つ目のマネージド型ノードグループを作成することをお勧めします。
+ カスタム起動テンプレートを使用しているスポットキャパシティータイプでノードグループをデプロイする場合、API を使用して複数のインスタンスタイプを渡します。起動テンプレートを使って 1 つのインスタンスタイプを渡さないでください。起動テンプレートを使用したノードグループのデプロイについての詳細は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」をご覧ください。
# クラスターのマネージドノードグループを作成する
このトピックでは、Amazon EKS クラスターに登録しているノードの、Amazon EKS マネージド型ノードグループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。
Amazon EKS マネージド型ノードグループを初めて起動する場合は、[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従うことをお勧めします。このガイドでは、ノードを使用して Amazon EKS クラスターを作成するためのウォークスルーを説明します。
**重要**
Amazon EKS ノードは、標準の Amazon EC2 インスタンスです。通常の Amazon EC2 料金に基づいて請求されます。詳細については、[Amazon EC2 の料金表](https://aws.amazon.com/ec2/pricing/)を参照してください。
AWS Outposts または AWS Wavelength が有効になっている AWS リージョンでは、マネージドノードを作成できません。ユーザーは代わりに、セルフマネージド型ノードを作成できます。詳細については[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)、[セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md)、および[セルフマネージド Bottlerocket ノードの作成](launch-node-bottlerocket.md)を参照してください。また、Outpost に自己管理型 Amazon Linux ノードグループを作成することもできます。詳細については、「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。
Amazon EKS 最適化 Linux または Bottlerocket に含まれる `bootstrap.sh` ファイル用に [AMI ID を指定](launch-templates.md#launch-template-custom-ami)しない場合、マネージドノードグループは `maxPods` の値に最大数を適用します。vCPU が 30 未満のインスタンスの場合、最大数は `110` です。30 を超える vCPU を持つインスタンスの場合、最大数は `250` に跳ね上がります。この適用は、`maxPodsExpression` を含む他の `maxPods` 設定を上書きします。`maxPods` の決定方法とカスタマイズ方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
+ ノードが使用する既存の IAM ロール。作成する場合は「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。この役割に VPC CNI のポリシーがどちらも含まれていない場合、VPC CNI ポッドには以下の別の役割が必要です。
+ (オプションですが推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで構成された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
+ 「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」に記載されている考慮事項に精通していること。選択したインスタンスタイプによってはクラスターと VPC に関する追加の前提条件がある場合もあります。
+ Windows マネージドノードグループを追加するには、まずクラスターの Windows サポートを有効にする必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
マネージド型ノードグループを作成するには、以下のいずれかを使用します。
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [AWS マネジメントコンソール](#console_create_managed_nodegroup)
## `eksctl`
**eksctl を使用してマネージド型ノードグループを作成する**
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. (オプション) **[AmazonEKS\$1CNI\$1Policy]** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合は、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. カスタム起動テンプレートの有無にかかわらず、マネージド型ノードグループを作成します。起動テンプレートを手動で指定すると、ノードグループをより詳細にカスタマイズできます。たとえば、カスタム AMI をデプロイしたり、Amazon EKS 最適化 AMI の `boostrap.sh` スクリプトの引数を指定したりできます。すべての使用可能なオプションとデフォルト値の一覧を表示するには、次のコマンドを入力します。
```
eksctl create nodegroup --help
```
次のコマンドで、*my-cluster* をクラスターの名前に置き換え、*my-mng* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
**重要**
マネージド型ノードグループを最初に作成する際にカスタム起動テンプレートを使用しない場合は、後でノードグループに使用しないでください。カスタム起動テンプレートを指定しなかった場合、システムにより起動テンプレートが自動生成されます。これを手動で変更することはお勧めしません。自動生成された起動テンプレートを手動で変更すると、エラーが発生する場合があります。
**起動テンプレートなし**
`eksctl` は、デフォルトの Amazon EC2 起動テンプレートをアカウント内に作成し、指定したオプションに基づいて作成した起動テンプレートを使用してノードグループをデプロイします。`--node-type` の値を指定する前に「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
*ami-family* を許可されているキーワードに置き換えます。詳細については、「`eksctl` ドキュメント」の「[Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family)」(ノード AMI ファミリーの設定) を参照してください。*my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。
**注記**
Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。
Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
IMDS への Pod のアクセスをブロックするには、`--disable-pod-imds` オプションを次のコマンドに追加します。
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
ご使用のインスタンスでは、オプションで大量の IP アドレスをポッドに割り当てることや、インスタンスではなく CIDR ブロックから Pod に IP アドレスを割り当てることができます。また、そのインスタンスはインターネットにアクセスできないクラスターにデプロイすることも可能です。詳細については、追加オプションの[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)および [インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md) を参照して、前のコマンドに追加します。
マネージドノードグループは、インスタンスタイプに基づいて、ノードグループの各ノードで実行できる Pod の最大数に対して 1 つの値を計算して適用します。異なるインスタンスタイプを持つノードグループを作成する場合、すべてのインスタンスタイプで計算された最小値が、ノードグループ内のすべてのインスタンスタイプで実行できる Pod の最大数として適用されます。マネージドノードグループは、で参照するスクリプトを使用して値を計算します。
**起動テンプレートの使用**
起動テンプレートがすでに存在している必要があり、また、「[起動テンプレート設定の基本](launch-templates.md#launch-template-basics)」で指定されている要件を満たしている必要があります。次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
IMDS への Pod のアクセスをブロックするには、起動テンプレートで必要な設定を行います。
1. 次のコンテンツをデバイスにコピーします。サンプル値を置き換えたら、変更したコマンドを実行して `eks-nodegroup.yaml` ファイルを作成します。起動テンプレートなしでデプロイしたときに指定したいくつかの設定は、起動テンプレートに移動されます。`version` を指定しない場合は、テンプレートのデフォルトバージョンが使用されます。
```
cat >eks-nodegroup.yaml <
**AWS マネジメントコンソール を使用してマネージド型ノードグループを作成する**
1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。まだ `ACTIVE` ではないクラスターにはマネージド型ノードグループを作成できません。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. マネージド型ノードグループを作成するクラスターの名前を選択します。
1. **[コンピューティング]** タブを選択します。
1. **[ノードグループを追加]** を選択します。
1. **[ノードグループの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[名前]** – マネージド型ノードグループの一意の名前を入力します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ **[ノード IAM ロール]** – ノードグループで使用するノードインスタンスロールを選択します。詳細については、「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。
**重要**
クラスターの作成に使用したロールは使用できません。
セルフマネージド型ノードグループによって現在使用されていないロールを使用することをお勧めします。それ以外の場合は、新しいセルフマネージド型ノードグループで使用します。詳細については、「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」を参照してください。
+ **起動テンプレートを使用する** — (オプション) 既存の起動テンプレートを使用するかどうかを選択します。**[起動テンプレート名]** を選択します。次に、**[起動テンプレートのバージョン]** を選択します。バージョンを選択しない場合、Amazon EKS はテンプレートのデフォルトのバージョンを使用します。起動テンプレートを使用すると、ノードグループを詳細にカスタマイズできます。これにより、カスタム AMI のデプロイ、ポッドへの大量の IP アドレスの割り当て、インスタンスのブロックとは異なる CIDR ブロックからのポッドに対する IP アドレスの割り当て、さらにアウトバウンドのインターネットアクセスのないクラスターに対するノードのデプロイが可能になります。詳細については[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)、[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)、および[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)を参照してください。
起動テンプレート は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」の要件を満たしている必要があります。独自の起動テンプレートを使用しない場合、Amazon EKS API はデフォルトの Amazon EC2 起動テンプレートをアカウントに作成し、デフォルトの起動テンプレートを使用してノードグループをデプロイします。
[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を実装する場合は、AWS サービスへのアクセス許可を必要とするすべての Pod に必要なアクセス許可を直接割り当て、クラスター内の Pod が、現在の AWS リージョンを取得するなどの理由で IMDS にアクセスしないようにします。また、起動テンプレートでホストネットワークを使用しないポッドの、IMDS へのアクセスを無効にすることもできます。詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
+ [**Kubernetes ラベル**]: (オプション) マネージド型ノードグループ内のノードに Kubernetes ラベルを適用するように選択できます。
+ **Kubernetes テイント** - (オプション) 管理対象ノードグループ内のノードに Kubernetes テイントを適用することを選択できます。**[効果]** メニューでの利用可能なオプションは ` NoSchedule `、` NoExecute `、および ` PreferNoSchedule ` です。詳細については、「[レシピ: 特定のノードでポッドがスケジュールされないようにする](node-taints-managed-node-groups.md)」を参照してください。
+ **[タグ]** – (オプション) Amazon EKS マネージド型ノードグループにタグを付けることを選択できます。これらのタグは、Auto Scaling グループやインスタンスなど、ノードグループ内の他のリソースには伝達されません。詳細については、「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。
1. **[コンピューティング構成とスケーリングの設定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[AMI タイプ]** – AMI タイプを選択します。Arm インスタンスをデプロイする場合は、デプロイする前に「[Amazon EKS optimized Arm Amazon Linux AMIs](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。
前のページで起動テンプレートを指定し、起動テンプレートで AMI を指定した場合は、値を選択できません。テンプレートの値が表示されます。テンプレートで指定された AMI は、「[AMI の指定](launch-templates.md#launch-template-custom-ami)」の要件を満たしている必要があります。
+ **[キャパシティータイプ]** – キャパシティタイプを選択します。キャパシティータイプの選択の詳細については、「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。同じノードグループ内で、異なるキャパシティータイプを混在させることはできません。両方のキャパシティータイプを使用したい場合は、キャパシティータイプとインスタンスタイプをそれぞれに持つ、別々のノードグループを作成します。GPU アクセラレーテッドワーカーノードのプロビジョニングとスケーリングについては、「[マネージドノードグループの GPU を予約する](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html)」を参照してください。
+ **[インスタンスタイプ]** – デフォルトで 1 つまたは複数のインスタンスタイプが指定されています。デフォルトのインスタンスタイプを削除するには、インスタンスタイプの右側にある `X` を選択します。マネージド型ノードグループで使用するインスタンスタイプを選択します。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
コンソールには、一般的に使用されるインスタンスタイプのセットが表示されます。表示されてないインスタンスタイプを持つマネージド型ノードグループの作成が必要な場合は、`eksctl`、AWS CLI、AWS CloudFormation、または SDK を使用して、ノードグループを作成します。前のページで起動テンプレートを指定した場合、起動テンプレートでインスタンスタイプを指定する必要があるため、値を選択できません。起動テンプレートの値が表示されます。[**キャパシティータイプ**] で [**スポット**] を選択した場合は、可用性を高めるために、複数のインスタンスタイプを指定することをお勧めします。
+ **[ディスクサイズ]** – ノードのルートボリュームに使用するディスクサイズ (GiB 単位) を入力します。
前のページで起動テンプレートを指定した場合は、値を起動テンプレートで指定する必要があるため、値を選択できません。
+ **[必要なサイズ]** – マネージド型ノードグループが起動時に保持する必要があるノードの現在の数を指定します。
**注記**
Amazon EKS は、ノードグループを自動的にスケールインまたはスケールアウトしません。ただし、これを行うように Kubernetes Cluster Autoscaler を設定することはできます。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)」を参照してください。
+ **[最小サイズ]** – マネージド型ノードグループがスケールインできるノードの最小数を指定します。
+ **[最大サイズ]** – マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。
+ **ノードグループの更新設定** – (オプション) 並行して更新するノードの数または割合を選択できます。これらのノードは、更新中は使用できません。**[使用できない最大値]** で、次のいずれかのオプションを選択し、その **[値]** を指定します:
+ **[数値]** – 並行して更新できるノードグループ内のノード数を選択して指定します。
+ **[パーセンテージ]** – 並行して更新できるノードグループ内のノードの割合を選択して指定します。ノードグループに多数のノードがある場合に便利です。
+ **ノードの自動修復設定** – (オプション) **[ノードの自動修復を有効にする]** チェックボックスを有効にすると、Amazon EKS は検出された問題が発生したときにノードを自動的に置き換えます。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
1. **[ネットワーキングを指定]** ページで、必要に応じてパラメータを指定し、**[次へ]** を選択します。
+ **[サブネット]**: マネージド型ノードを起動するサブネットを選択します。
**重要**
Amazon EBS ボリュームによってバックアップされ、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、`--balance-similar-node-groups` 機能を有効にする必要があります。
**重要**
パブリックサブネットを選択し、クラスターでパブリック API サーバーのエンドポイントのみが有効になっている場合は、サブネットの `MapPublicIPOnLaunch` に `true` をセットして、インスタンスがクラスターに正常に参加できるようにします。サブネットが 2020 年 3 月 26 日以降に `eksctl` または [Amazon EKS で発行された AWS CloudFormation テンプレート](creating-a-vpc.md)を使用して作成された場合は、この設定はすでに `true` に設定されています。サブネットが 2020 年 3 月 26 日より前に `eksctl` または AWS CloudFormation テンプレートを使用して作成されている場合は、設定を手動で変更する必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
起動テンプレートを使用しており、複数のネットワークインターフェイスを指定している場合には、たとえ `MapPublicIpOnLaunch` が `true` に設定されていても、Amazon EC2 はパブリック `IPv4` アドレスの自動的な割り当てを行いません。このシナリオでノードがクラスターに参加するには、クラスターのプライベート API サーバーエンドポイントを有効にするか、NAT ゲートウェイなどの別の方法によってアウトバウンドインターネットアクセスを提供する、プライベートサブネットでノードを起動する必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスの IP アドレス指定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)」を参照してください。
+ **ノードへの SSH アクセスの設定** (オプション)。SSH を有効にすることにより、インスタンスに接続し、問題がある場合に診断情報を収集できます。ノードグループを作成するときは、リモートアクセスを有効にすることを強くお勧めします。ノードグループの作成後にリモートアクセスを有効にすることはできません。
起動テンプレートの使用を選択した場合、このオプションは表示されません。ノードへのリモートアクセスを有効にするには、起動テンプレートでキーペアを指定し、起動テンプレートで指定したセキュリティグループのノードに対して適切なポートが開いていることを確認します。詳細については、「[カスタムセキュリティグループを使用する](launch-templates.md#launch-template-security-groups)」を参照してください。
**注記**
Windows の場合、このコマンドは SSH を有効にしません。代わりに Amazon EC2 キーペアをインスタンスに関連付け、インスタンスに RDP できるようにします。
+ **[SSH キーペア]** (オプション) の場合は、使用する Amazon EC2 SSH キーを選択します。Linux の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。Windows の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。起動テンプレートを使用することを選択した場合、選択することはできません。Bottlerocket AMI を使用するノードグループに Amazon EC2 SSH キーが提供されると、管理コンテナも有効になります。詳細については、GitHub の [Admin container](https://github.com/bottlerocket-os/bottlerocket#admin-container) を参照してください。
+ **[次からの SSH リモートアクセスを許可する]** の場合、特定のインスタンスへのアクセスを制限するには、それらのインスタンスに関連付けられているセキュリティグループを選択します。特定のセキュリティグループを選択しないと、インターネット上のどの場所 (`0.0.0.0/0`) からでも SSH アクセスが許可されます。
1. **[確認と作成]** ページで、マネージド型ノードグループの設定を確認し、**[作成]** を選択してください。
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
1. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化高速 AMI を選択した場合は、クラスター上の DaemonSet として [Kubernetes 用の NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)を適用する必要があります。次のコマンドを実行する前に、*vX.X.X* を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
## Kubernetes アドオンをインストールする
ノードが関連付けられた Amazon EKS クラスターが実行中になったところで、Kubernetes アドオンのインストールとクラスターへのアプリケーションのデプロイを開始できます。以下のトピックはクラスターの機能を拡張するのに役立ちます。
+ クラスターを作成した [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)は、`kubectl` または AWS マネジメントコンソール を使用して Kubernetes API サーバーを呼び出すことができる唯一のプリンシパルです。他の IAM プリンシパルがクラスターにアクセスできるようにする場合はそれらを追加する必要があります。詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」および「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
+ 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
+ ノードグループ内のノード数を自動的に調整するように Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を設定します。
+ [サンプルアプリケーション](sample-deployment.md)をクラスターにデプロイします。
+ クラスターを管理するための重要なツールを使用して、[クラスターリソースを整理およびモニタリング](eks-managing.md)します。
# クラスターのためにマネージドノードグループを更新する
マネージド型ノードグループの更新を開始すると、Amazon EKS はノードを自動的に更新し、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」でリストされた手順を完了します。Amazon EKS 最適化 AMI を使用している場合、Amazon EKS は最新のセキュリティパッチとオペレーティングシステムの更新を、最新の AMI リリースバージョンの一部として自動的にノードに適用します。
いくつかのシナリオでは、Amazon EKS マネージド型ノードグループのバージョンや設定を更新すると便利です。
+ Amazon EKS クラスターの Kubernetes バージョンを更新し、同じ Kubernetes バージョンを使用するようにノードを更新する場合。
+ マネージド型ノードグループでは、新しい AMI リリースバージョンを使用できます。AMI バージョンの詳細については、次のセクションを参照してください。
+ [Amazon Linux AMI のバージョン情報を取得する](eks-linux-ami-versions.md)
+ [最適化された Bottlerocket AMI を使用してノードを作成する](eks-optimized-ami-bottlerocket.md)
+ [Windows AMI バージョンに関する情報を取得する](eks-ami-versions-windows.md)
+ マネージド型ノードグループ内のインスタンスの最小数、最大数、または必要な数を調整する場合。
+ マネージド型ノードグループのインスタンスで Kubernetes ラベルを追加または削除する場合。
+ マネージド型ノードグループに AWS タグを追加または削除する場合。
+ カスタム AMI の更新などの設定の変更を伴う、新しいバージョンの起動テンプレートをデプロイする必要があります。
+ Amazon VPC CNI アドオンのバージョン `1.9.0` 以降をデプロイし、プレフィックス委任用のアドオンを有効にし、ノードグループ内の新しい AWS Nitro System インスタンスで大幅に増加した Pod の数をサポートしたい場合。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
+ Windows ノードの IP プレフィックスの委任を有効にし、ノードグループ内の新しい AWS Nitro System インスタンスで、大幅に増加したポッドをサポートした場合。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
マネージドノードグループの Kubernetes バージョンに対して、新しい AMI リリースバージョンがある場合は、ノードグループのバージョンを更新して、新しい AMI バージョンを使用することができます。同様に、クラスターがノードグループより新しい Kubernetes バージョンを実行している場合、クラスターの Kubernetes バージョンに一致する最新の AMI リリースバージョンを使用するようにノードグループを更新できます。
スケーリングオペレーションまたは更新によってマネージドノードグループ内のノードが終了すると、そのノードの Pod が最初にドレインされます。詳細については、「[ノードの更新の各フェーズを理解する](managed-node-update-behavior.md)」を参照してください。
## ノードグループバージョンの更新
ノードグループのバージョンは、次のいずれかを使用して更新できます。
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [AWS マネジメントコンソール](#console_update_managed_nodegroup)
更新するバージョンは、コントロールプレーンバージョンよりも新しいバージョンにすることはできません。
## `eksctl`
**`eksctl` を使用してマネージドノードグループを更新する**
次のコマンドを使用して、マネージドノードグループを、ノードに現在デプロイされているのと同じ Kubernetes バージョンの最新 AMI リリースに更新します。各*サンプル値*は独自の値に置き換えます。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**注記**
起動テンプレートでデプロイされたノードグループを、新しい起動テンプレートのバージョンにアップグレードする場合は、上記のコマンドに `--launch-template-version version-number ` を追加します。起動テンプレート は、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」に記載されている要件を満たしている必要があります。起動テンプレートにカスタム AMI が含まれている場合、AMI は「[Specifying an AMI](launch-templates.md#launch-template-custom-ami)」(AMI の指定) の要件を満たしている必要があります。ノードグループを新しいバージョンの起動テンプレートにアップグレードすると、指定した起動テンプレートバージョンの新しい設定と一致するように、すべてのノードがリサイクルされます。
起動テンプレートなしでデプロイしたノードグループを、新しい起動テンプレートバージョンに直接アップグレードすることはできません。代わりに、起動テンプレートを使用して新しいノードグループをデプロイし、新しい起動テンプレートバージョンにノードグループを更新する必要があります。
コントロールプレーンの Kubernetes バージョンと同じバージョンにノードグループをアップグレードできます。例えば、Kubernetes `1.35` を実行しているクラスターがある場合、次のコマンドを使用して、現在 Kubernetes `1.34` を実行しているノードをバージョン `1.35` にアップグレードできます。
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## AWS マネジメントコンソール
**AWS マネジメントコンソール を使用してマネージドノードグループを更新する**
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 更新するノードグループを含むクラスターを選択します。
1. 少なくとも 1 つのノードグループに利用可能な更新がある場合、ページの上部に利用可能な更新について通知するボックスが表示されます。**[Compute]** (コンピューティング) タブを選択すると、利用可能な更新があるノードグループの **[Node Groups]** (ノードグループ) 表の、**[AMI release version]** (AMI リリースバージョン) 列に、**[Update now]** (今すぐ更新) が表示されます。ノードグループを更新するには、**[Update now]** (今すぐ更新) を選択します。
カスタム AMI でデプロイされたノードグループの通知は表示されません。ノードがカスタム AMI でデプロイされている場合は、次の手順を実行して、新しく更新されたカスタム AMI をデプロイします。
1. AMI の新しいバージョンを作成します。
1. 新しい AMI ID を使用して、新しい起動テンプレートのバージョンを作成します。
1. 起動テンプレートの新しいバージョンにノードを更新する
1. **[Update node group version]** (ノードグループバージョンの更新) ダイアログボックスで、次のオプションを有効または無効にします。
+ **[Update node group version]** (ノードグループのバージョンの更新) - カスタム AMI をデプロイした場合、あるいは Amazon EKS に最適化された AMI が現在のクラスターで最新のバージョンである場合には、このオプションは利用できません。
+ **[Change launch template version]** (起動テンプレートバージョンの変更) - ノードグループがカスタムの起動テンプレートを使用せずにデプロイされている場合、このオプションは利用できません。カスタム起動テンプレートを使用してデプロイされたノードグループの、起動テンプレートのバージョンのみ更新できます。ノードグループを更新する **[Launch template version]** (起動テンプレートバージョン) を選択します。ノードグループがカスタム AMI で設定されている場合は、選択するバージョンも AMI を指定する必要があります。新しいバージョンの起動テンプレートにアップグレードすると、指定した起動テンプレートバージョンの新しい設定と一致するように、すべてのノードがリサイクルされます。
1. **[Update strategy]** (更新戦略) で、次のいずれかのオプションを選択します。
+ **[ローリング更新]**: このオプションは、クラスターの Pod の中断予算を尊重します。Pod 中断予算の問題により、Amazon EKS がこのノードグループで実行されている Pod を正常にドレインできない場合、更新が失敗します。
+ **[強制更新]**: このオプションは Pod の中断予算を尊重しません。ノードの再起動を強制的に実行することにより、Pod の中断予算の問題に関係なく更新が行われます。
1. **[更新]** を選択します。
## ノードグループ設定の編集
マネージド型ノードグループの設定の一部を変更できます。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 編集するノードグループを含むクラスターを選択します。
1. **[Compute]** (コンピューティング) タブを選択します。
1. 編集するノードグループを選択し、次に **[Edit]** (編集) を選択します。
1. (オプション) **[Edit Node Group]** (ノードグループの編集) ページで以下を実行します。
1. **ノードグループのスケーリング設定**を編集します。
+ **[Desired size]** (必要なサイズ) - マネージド型ノードグループが保持する必要があるノードの現在の数を指定します。
+ **[最小サイズ]** – マネージド型ノードグループがスケールインできるノードの最小数を指定します。
+ [**最大サイズ**]: マネージド型ノードグループがスケールアウトできるノードの最大数を指定します。ノードグループでサポートされるノードの最大数については、「[Amazon EKS と Fargate Service Quotas を表示して管理する](service-quotas.md)」を参照してください。
1. (オプション) ノードグループ内のノードに **[Kubernetes ラベル]** を追加または削除します。ここに示すラベルは、Amazon EKS で適用したラベルのみです。ここには表示されていない他のラベルがノードに存在する可能性があります。
1. (オプション) ノードグループ内のノードに **[Kubernetes テイント]** を追加または削除します。追加されたテイントは、` NoSchedule `、` NoExecute `、または ` PreferNoSchedule ` の影響があります。詳細については、「[レシピ: 特定のノードでポッドがスケジュールされないようにする](node-taints-managed-node-groups.md)」を参照してください。
1. (オプション) ノードグループリソースに**[Tags]** (タグ) を追加または削除します。これらのタグは、Amazon EKS ノードグループにのみ適用されます。これらは、Amazon EC2 インスタンスやサブネットなど、ノードグループの他のリソースには伝達されません。
1. (オプション) **ノードグループの更新設定**を編集します。**[Number]** (数値) または **[Percentage]** (パーセンテージ) のいずれかを選択します。
+ **[数値]**: 並行して更新できるノードグループ内のノード数を選択して指定します。これらのノードは、更新中は使用できません。
+ **[パーセンテージ]**: 並行して更新できるノードグループ内のノードの割合を選択して指定します。これらのノードは、更新中は使用できません。ノードグループに多数のノードがある場合に便利です。
1. 編集が終了したら、**[変更の保存]** を選択します。
**重要**
ノードグループ設定を更新する場合、[https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html) を変更しても Pod 中断予算 (PDB) は考慮されません。[ノードグループの更新](managed-node-update-behavior.md)プロセス (アップグレードフェーズ中にノードをドレインし、PDB を考慮する) とは異なり、スケーリング設定を更新すると、Auto Scaling グループ (ASG) スケールダウンコールによってノードがすぐに終了します。これは、スケールダウン先のターゲットサイズに関係なく、PDB を考慮せずに発生します。つまり、Amazon EKS マネージドノードグループの `desiredSize` を減らすと、ノードが終了するとすぐに、PDB を尊重せずに Pod が削除されます。
# ノードの更新の各フェーズを理解する
Amazon EKS マネージド型ワーカーノードのアップグレード戦略には、次のセクションで説明する 4 つの異なるフェーズがあります。
## セットアップフェーズ
セットアップフェーズには、次の手順があります。
1. ノードグループに関連付けられた Auto Scaling グループ用に新しい Amazon EC2 起動テンプレートバージョンを作成します。新しい起動テンプレートバージョンでは、ターゲットの AMI またはカスタム起動テンプレートバージョンを更新に使用します。
1. 最新の起動テンプレートバージョンを使用するように、Auto Scaling グループを更新します。
1. ノードグループの `updateConfig` プロパティを使用して、並列でアップグレードするノードの最大数を決定します。使用不可の最大値には、クォータとして 100 ノードがあります。デフォルト値は 1 ノードです。詳細については、Amazon EKS API リファレンス内の [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) プロパティを参照してください。
## スケールアップフェーズ
マネージド型ノードグループ内のノードをアップグレードするとき、アップグレードされたノードは、アップグレードされているノードと同じアベイラビリティーゾーンで起動されます。この配置を保証するために、Amazon EC2 のアベイラビリティーゾーンの再調整を使用します。詳細については、[Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)の*アベイラビリティーゾーンの再調整*を参照してください。この要件を満たすために、マネージド型ノードグループのアベイラビリティーゾーンごとに最大 2 つのインスタンスを起動できます。
スケールアップフェーズには、次の手順があります。
1. Auto Scaling グループの最大サイズと希望のサイズを、次のうちいずれか大きい方だけ増加させます。
+ Auto Scaling グループがデプロイされているアベイラビリティーゾーン数の最大 2 倍。
+ アップグレードができない最大値。
たとえば、ノードグループのアベイラビリティーゾーンが 5 つで、`maxUnavailable` が 1 である場合、アップグレードプロセスで最大 10 個のノードを起動できます。しかし、`maxUnavailable` が 20 (または 10 より大きいいずれかの値) である場合、プロセスにより起動される新しいノードは 20 個です。
1. Auto Scaling グループのスケーリング後、最新の設定を使用するノードがノードグループに存在するかどうかをチェックします。この手順は、次の基準を満たす場合にのみ成功します。
+ ノードが存在するすべてのアベイラビリティーゾーンで、少なくとも 1 つの新しいノードが起動されます。
+ 新しいノードはすべて、`Ready` 状態である必要があります。
+ 新しいノードには Amazon EKS 適用ラベルが必要です。
これは、通常のノードグループのワーカーノード上の Amazon EKS 適用ラベルです。
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
これは、カスタム起動テンプレートまたは AMI ノードグループのワーカーノード上の Amazon EKS 適用ラベルです。
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. 新しい Pod がスケジュールされないように、ノードをスケジュール不可としてマークします。古いノードを終了する前にロードバランサーからノードを削除するため、ノードに `node.kubernetes.io/exclude-from-external-load-balancers=true` のラベルを付けます。
このフェーズで `NodeCreationFailure` エラーが発生する既知の原因を次に示します。
**アベイラビリティーゾーンの容量が不十分です**
アベイラビリティーゾーンに、リクエストされたインスタンスタイプの容量がない可能性があります。マネージド型ノードグループを作成するときは、複数のインスタンスタイプを設定することをお勧めします。
**アカウント内の EC2 インスタンス制限**
Service Quotas を使用してアカウントが同時に実行できる Amazon EC2 インスタンスの数を増やす必要がある場合があります。詳細については、*Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイド*の [EC2 の Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) を参照してください。
**カスタムユーザーデータ**
カスタムユーザーデータは、ブートストラッププロセスを中断することがあります。このシナリオでは、ノードで `kubelet` が起動しないか、ノードで想定される Amazon EKS ラベルが取得されない可能性があります。詳細については、「[AMI を指定する](launch-templates.md#launch-template-custom-ami)」を参照してください。
**ノードを異常な状態または準備ができていない状態にする変更**
ノードのディスク負荷、メモリ負荷、および同様の条件により、ノードが `Ready` 状態にならない可能性があります。
**各ノードのブートストラップにかかる時間は通常 15 分以内**
ブートストラップしてクラスターに加わるまでに 15 分以上かかるノードがあると、アップグレードがタイムアウトします。この時間は、新しいノードが必要になってからクラスターに加わるまで、新しいノードのブートストラップに要した合計時間です。マネージドノードグループをアップグレードする場合は、Auto Scaling グループのサイズが大きくなると、すぐに時間の測定が始まります。
## アップグレードフェーズ
アップグレードフェーズの動作には 2 通りの方法があり、*更新戦略*によって異なります。**デフォルト**と**最小**という 2 つの更新戦略があります。
通常は、デフォルト戦略をお勧めします。古いノードを終了する前に新しいノードを作成するという戦略で、アップグレードフェーズ中も使用可能な容量が維持されます。最小は、リソースやコスト (例えば、GPU などのハードウェアアクセラレーター) が限られている場合に便利な戦略です。新しいノードを作成する前に古いノードを終了するため、合計容量が設定しておいた数量を超えることはありません。
*デフォルト*更新戦略のステップは次のとおりです。
1. Auto Scaling グループ内のノード数を (必要な数だけ) 増やして、ノードグループに追加でノードを作成します。
1. ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
1. ノードから Pod をドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、`PodEvictionFailure` というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、`update-nodegroup-version` リクエストで強制フラグを適用して Pod を削除できます。
1. すべての Pod が削除されたらノードを遮断し、60 秒間待機します。これは、サービスコントローラーがこのノードに新しくリクエストを送信しないようにするためと、アクティブなノードのリストからこのノードを削除するために行われます。
1. 遮断されたノードの Auto Scaling グループに終了リクエストを送信します。
1. 以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。
*最小*更新戦略のステップは次のとおりです。
1. ノードグループのすべてのノードを最初に遮断して、サービスコントローラーがこれらのノードに新しいリクエストを送信しないようにします。
1. ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
1. 選択したノードからポッドをドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、`PodEvictionFailure` というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、`update-nodegroup-version` リクエストで強制フラグを適用して Pod を削除できます。
1. すべてのポッドを削除し 60 秒間待機すると、終了リクエストが、選択したノードの Auto Scaling グループに送信されます。Auto Scaling グループは、不足分の容量を補うために (選択したノードと同数の) 新しいノードを作成します。
1. 以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。
### アップグレードフェーズ中の `PodEvictionFailure` エラー
このフェーズで `PodEvictionFailure` エラーが発生する既知の原因を次に示します。
**アグレッシブ PDB**
Pod にアグレッシブ PDB が定義されているか、同じ Pod を指す複数の PDB が存在します。
**すべてのテイントを許容するデプロイ**
すべての Pod が削除されたら、前のステップでノードが[テイント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)されているため、ノードは空になるはずです。ただし、デプロイがすべてのテイントを許容する場合、ノードが空でない可能性が高くなり、Pod のエビクションが失敗します。
## スケールダウンフェーズ
スケールダウンフェーズでは、Auto Scaling グループの最大サイズと希望するサイズが 1 ずつ減り、更新が開始される前の値に戻ります。
ワークフローのスケールダウンフェーズ中に Cluster Autoscaler がノードグループをスケールアップしているとアップグレードワークフローが判断した場合、ノードグループを元のサイズに戻すことなく、すぐに終了します。
# 起動テンプレートを使用してマネージドノードをカスタマイズする
このページの手順に基づいて自分の起動テンプレートを使用することで、マネージド型ノードをデプロイでき、最高レベルのカスタマイズを実現できます。起動テンプレートを使用すると、ノードのデプロイ中にブートストラップ引数 (追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数など) を指定したり、ノードに割り当てられた IP アドレスとは異なる CIDR ブロックからポッドに IP アドレスを割り当てたり、独自のカスタム AMI をノードにデプロイしたり、独自のカスタム CNI をノードにデプロイしたりできます。
最初にマネージドノードグループを作成するときに独自の起動テンプレートを指定する場合にも、後で高い柔軟性を得ることができます。自分の起動テンプレートを使用してマネージド型ノードグループをデプロイする限り、同じ起動テンプレートの異なるバージョンとして繰り返し更新できます。ノードグループを別のバージョンの起動テンプレートに更新すると、指定した起動テンプレートバージョンの新しい設定と一致するように、グループ内のすべてのノードがリサイクルされます。
マネージド型ノードグループは常に アマゾン EC2 自動スケーリング グループで使用する起動テンプレートでデプロイされます。起動テンプレートを指定しない場合、アマゾン EKS API はアカウントのデフォルト値を使用して起動テンプレートを自動的に作成します。ただし、自動生成された起動テンプレートを変更することは推奨しません。さらに、カスタム起動テンプレートを使用していない既存のノードグループは直接更新できません。代わりに、カスタム起動テンプレートを使用して、新しいノードグループを作成する必要があります。
## 起動テンプレート設定の基本
AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用して、アマゾン EC2 自動スケーリング 起動テンプレートを作成できます。詳細については*「アマゾン EC2 自動スケーリング ユーザーガイド」*の「[自動スケーリング グループの起動テンプレートを作成する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)」を参照してください。起動テンプレートの一部の設定はマネージド型ノードで使われている設定と似ています。起動テンプレートを使用してノードグループをデプロイまたは更新する場合、一部の設定はノードグループ設定または起動テンプレートのいずれかで指定する必要があります。両方の場所で設定を指定しないでください。存在してはいけない場所に設定が存在する場合、ノードグループの作成や更新などの操作は失敗します。
次の表に、起動テンプレートで禁止されている設定を示します。また、マネージド型ノードグループの設定に必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK では類似するが異なる名前がある場合があります。
| 起動テンプレート — 禁止 | アマゾン EKS ノードグループ設定 |
| --- | --- |
| [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**]) の下の [**サブネット**] | **[Specify networking]** (ネットワーキングを指定) ページの **[Node group network configuration]** (ノードグループのネットワーク設定) の下の **[Subnets]** (サブネット) |
| [**高度な詳細**] の下の [**IAM インスタンスプロファイル**] | **[Configure Node group]** (ノードグループを設定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[Node IAM role]** (ノード IAM 役割) |
| [**高度な詳細**] の下の [**シャットダウン動作**] および [**停止 – 休止動作**]。起動テンプレートのどちらの設定でも、[**起動テンプレート設定に含めない**] のデフォルトを保持します。 | 同等のものはありません。アマゾン EKS は自動スケーリング グループではなく、インスタンスのライフサイクルを管理する必要があります。 |
次の表に、マネージド型ノードグループ構成で禁止される設定を示します。また、起動テンプレートで必要な同様の設定がある場合はその設定も示します。リスト化されている設定はコンソールに表示される設定です。AWS CLI と SDK とで名前が似ている場合があります。
| アマゾン EKS ノードグループ設定 — 禁止 | 起動テンプレート |
| --- | --- |
| (起動テンプレートでカスタム AMI を指定した場合のみ) **[コンピューティングとスケーリングの設定を実行]** ページの **[ノードグループのコンピューティング設定]** の下の **[AMI タイプ]** — **[起動テンプレートで指定]** と、指定した AMI ID がコンソールに表示されます。 起動テンプレートで **[アプリ and OS Images (アマゾン Machine Image)]** (アプリケーションと OS のイメージ (アマゾン マシンイメージ)) が指定されていない場合はノードグループ設定で AMI を選択できます。 | **[Launch template contents]** (起動テンプレートのコンテンツ) での **[Application and OS Images (Amazon Machine Image)]** (アプリケーションと OS のイメージ (Amazon マシンイメージ)) - 次のいずれかの要件がある場合はID を指定する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/launch-templates.html) |
| **[Set compute and scaling configuration]** (コンピューティングとスケーリングの設定を実行) ページの **[Node Group compute configuration]** (ノードグループのコンピューティング設定) の下の **[Disk size]** (ディスクサイズ) — **[Specified in launch template]** (起動テンプレートで指定) がコンソールに表示されます。 | [**ストレージ (ボリューム)**] ([**新しいボリュームの追加**]) の下の [**サイズ**]。これを起動テンプレートで指定する必要があります。 |
| **[Specify Networking]** (ネットワーキングを指定) ページの **[Node group configuration]** (ノードグループ設定) の下の **[SSH key pair]** (SSH キーペア) — コンソールに起動テンプレートで指定したキーまたは **[Not specified in launch template]** (起動テンプレートで指定されていません) が表示されます。 | [**キーペア (ログイン)**] の下の [**キーペア名**]。 |
| 起動テンプレートを使用する場合はリモートアクセスを許可するソースセキュリティグループを指定できません。 | インスタンスの場合、[**ネットワーク設定**] の下の [**セキュリティグループ**]、または [**ネットワークインターフェイス**] ([**ネットワークインターフェイスを追加**])の下の [**セキュリティグループ**]。両方設定することはできません。詳細については「[カスタムセキュリティグループを使用する](#launch-template-security-groups)」を参照してください。 |
**注記**
起動テンプレートを使用してノードグループをデプロイする場合は起動テンプレート内の **[起動テンプレートのコンテンツ]** で 0 または 1 の **[インスタンスタイプ]** を指定します。またはコンソールの **[コンピューティングとスケーリングの構成を設定する]** ページにある **[インスタンスタイプ]** で 0 から 20 までのインスタンスタイプを指定できます。またはアマゾン EKS API を使用する他のツールを使用して行うこともできます。起動テンプレートでインスタンスタイプを指定し、その起動テンプレートを使用してノードグループをデプロイする場合、コンソールや、アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定することはできません。起動テンプレートやコンソール、または アマゾン EKS API を使用する他のツールを使用してインスタンスタイプを指定しない場合は`t3.medium` インスタンスタイプが使用されます。ノードグループがスポットキャパシティータイプを使用している場合はコンソールを使用して複数のインスタンスタイプを指定することをお勧めします。詳細については「[マネージド型ノードグループのキャパシティータイプ](managed-node-groups.md#managed-node-group-capacity-types)」を参照してください。
ノードグループにデプロイするコンテナが、インスタンスメタデータサービスバージョン 2 を使用している場合は起動テンプレートの **[メタデータレスポンスのホップ制限]** を `2` に設定してください。詳細については*「アマゾン EC2 ユーザーガイド」*の「[Instance metadata and user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」(インスタンスメタデータとユーザーデータ) を参照してください。
起動テンプレートでは、インスタンスタイプを柔軟に選択できるようにする `InstanceRequirements` 機能はサポートされていません。
## アマゾン EC2 インスタンスへのタグ付け
起動テンプレートの `TagSpecification` パラメータを使用して、ノードグループの アマゾン EC2 インスタンスに適用するタグを指定します。`CreateNodegroup` または `UpdateNodegroupVersion` API を呼び出す IAM エンティティには`ec2:RunInstances` および `ec2:CreateTags` へのアクセス許可が必要です。また、起動テンプレートにタグが追加される必要があります。
## カスタムセキュリティグループを使用する
起動テンプレートでカスタムの アマゾン EC2 [セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)を指定し、ノードグループ内のインスタンスに適用できます。これはインスタンスレベルのセキュリティグループのパラメータ内か、ネットワークインターフェイス設定のパラメータの一部として指定できます。しかし、インスタンスレベルとネットワークインタフェイス、両方のセキュリティグループを指定して、起動テンプレートを作成することはできません。マネージドノード型グループでカスタムセキュリティグループを使用する際に適用される、次の条件を考慮してください。
+ AWS マネジメントコンソール を使用する場合、アマゾン EKS では単一のネットワークインターフェイス仕様の起動テンプレートのみ使用できます。
+ デフォルトではAmazon EKS は[クラスターセキュリティグループ](sec-group-reqs.md)をノードグループ内のインスタンスに追加して、ノードとコントロールプレーンとの間の通信を容易にします。前述のいずれかのオプションを使用して、起動テンプレートでカスタムセキュリティグループを指定した場合、アマゾン EKS はクラスターセキュリティグループを追加しません。したがって、セキュリティグループのインバウンドルールとアウトバウンドルールで、クラスターのエンドポイントとの通信が有効になっていることを確認する必要があります。セキュリティグループのルールが正しくない場合、ワーカーノードはクラスターに参加できません。セキュリティグループルールの詳細については[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。
+ ノードグループ内のインスタンスへの SSH アクセスが必要な場合はそのアクセスを許可するセキュリティグループを含めてください。
## アマゾン EC2 ユーザーデータ
起動テンプレートにはカスタムユーザーデータのセクションが含まれています。このセクションでは、個々のカスタム AMI を手動で作成しなくても、ノードグループの構成設定を指定できます。Bottlerocket で使用できる設定の詳細については、GitHub で [Using user data](https://github.com/bottlerocket-os/bottlerocket#using-user-data) を参照してください。
`cloud-init` を使用すると、インスタンス起動時に起動テンプレート内の Amazon EC2 ユーザーデータを提供できます。詳細については「[cloud-init ドキュメント](https://cloudinit.readthedocs.io/en/latest/index.html)」を参照してください。ユーザーデータを使用すると、一般的な設定操作を実行できます。これには次の操作が含まれます。
+ [ユーザーまたはグループを含む](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [パッケージのインストール](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
マネージド型ノードグループで使用される起動テンプレートの Amazon EC2 ユーザーデータは、Amazon Linux AMI の場合は、[MIME マルチパートアーカイブ](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive)、Bottlerocket AMI の場合は TOML の形式であることが必要です。これはユーザーデータが、ノードがクラスターに参加するために必要な Amazon EKS ユーザーデータにマージされるためです。`kubelet` を起動または変更するコマンドをユーザーデータに指定しないでください。これは アマゾン EKS によってマージされたユーザーデータの一部として実行されます。ノードへのラベル設定などの一部の `kubelet` パラメータはマネージド型ノードグループ API 経由で直接設定できます。
**注記**
手動での起動や、カスタムの設定パラメータの受け渡しなど、高度な `kubelet` のカスタマイズについては[AMI を指定する](#launch-template-custom-ami)を参照してください。起動テンプレートでカスタム AMI ID が指定されている場合、アマゾン EKS はユーザーデータをマージしません。
次の詳細はユーザーデータセクションについて説明しています。
**アマゾン リナックス 2 ユーザーデータ**
複数のユーザーデータブロックと単一の MIME マルチパートファイルを組み合わせることができます。例えば、カスタムパッケージをインストールするユーザーデータのシェルスクリプトを、Docker デーモンを設定するクラウドブートフックに組み合わせることができます。MIME マルチパートファイルには次のコンポーネントが含まれます。
+ コンテンツタイプとパートバウンダリの宣言: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ MIME バージョンの宣言: `MIME-Version: 1.0`
+ 次のコンポーネントを含む 1 つ以上のユーザーデータブロック:
+ ユーザーデータブロックの始まりを示す開始境界:`--==MYBOUNDARY==`
+ ブロックのコンテンツの種類の宣言: `Content-Type: text/cloud-config; charset="us-ascii"`。コンテンツタイプの詳細については[cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html) のドキュメントを参照してください。
+ ユーザーデータのコンテンツ (例えば、シェルコマンドや `cloud-init` ディレクティブのリスト)。
+ MIME マルチパートファイルの終わりを示す、終了境界: `--==MYBOUNDARY==--`
自分で MIME マルチパートファイルを作成するときに使用できる例は次の通りです。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**アマゾン リナックス 2023 ユーザーデータ**
アマゾン リナックス 2023 (AL2023) ではYAML 設定スキーマを使用する新しいノード初期化プロセス `nodeadm` が導入されています。セルフマネージド型ノードグループまたは起動テンプレートを持つ AMI を使用している場合は新しいノードグループの作成時に追加のクラスターメタデータを明示的に指定する必要があります。最低限必要なパラメータの[例](https://awslabs.github.io/amazon-eks-ami/nodeadm/)を以下に示します。ここで、`apiServerEndpoint`、`certificateAuthority`、サービスの `cidr` が必要になります。
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
通常、この設定はユーザーデータにそのまま設定するか、MIME マルチパートドキュメントに埋め込まれます。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
AL2 ではこれらのパラメータからのメタデータは アマゾン EKS `DescribeCluster` API コールから検出されていました。AL2023 ではノードの大規模なスケールアップ中に API コールによってスロットリングが発生するリスクがあるため、この動作が変更されました。この変更は起動テンプレートのないマネージド型ノードグループを使用している場合や、Karpenter を使用している場合には影響しません。`certificateAuthority` とサービス `cidr` の詳細については、「*Amazon EKS API リファレンス*」の「[https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)」を参照してください。
次に、AL2023 ユーザーデータの詳しい例を示します。ノードをカスタマイズするシェルスクリプト (パッケージのインストールやコンテナイメージの事前キャッシュなど) を必要な `nodeadm` 設定と結合しています。この例では、よく使用されるカスタマイズを示しています。\$1 追加でシステムパッケージをインストールする \$1 コンテナイメージを事前キャッシュしてポッドの起動時間を改善する \$1 HTTP プロキシ設定を設定する \$1 ノードのラベル付けに関する `kubelet` フラグを設定する
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Bottlerocket ユーザーデータ**
Bottlerocket はユーザーデータを TOML 形式で構造化しています。Amazon EKS が提供するユーザーデータとマージするユーザーデータを提供できます。たとえば、追加の `kubelet` 設定を指定できます。
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
サポートされる設定について詳しくは[Bottlerocket のドキュメント](https://github.com/bottlerocket-os/bottlerocket)を参照してください。ユーザーデータにノードラベルと[テイント](node-taints-managed-node-groups.md)を設定できます。ただし、代わりにノードグループ内にこれらを設定することをお勧めします。この場合、アマゾン EKS によりこれらの設定が適用されます。
ユーザーデータをマージしても、書式設定は保持されませんが、コンテンツは同じままです。ユーザーデータに指定した設定はアマゾン EKS によって構成された設定よりも優先されます。したがって、`settings.kubernetes.max-pods` または `settings.kubernetes.cluster-dns-ip` を設定した場合、ユーザーデータのこれらの値がノードに適用されます。
アマゾン EKS で、有効な TOML がすべてサポートされるわけではありません。以下はサポートされていない既知の形式の一覧です。
+ 引用符で囲まれたキー内の引用符: `'quoted "value"' = "value"`
+ 値内のエスケープされた引用符: `str = "I’m a string. \"You can quote me\""`
+ 浮動小数点と整数の混在: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ 配列内の混合型: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ 引用符付きキーを含む括弧で囲まれたヘッダー: `[foo."bar.baz"]`
**Windows ユーザーデータ**
Windows ユーザーデータでは、PowerShell コマンドを使用します。マネージド型ノードグループを作成すると、カスタムユーザーデータが Amazon EKS マネージドユーザーデータと結合されます。まず PowerShell コマンドが表示され、その後にマネージドユーザーデータコマンドが続きます。そのいずれも 1 つの `` タグ内にあります。
Windows ノードグループを作成すると、Amazon EKS は Linux ベースのノードがクラスターに参加できるように `aws-auth` `ConfigMap` を更新します。このサービスは、Windows AMI に対するアクセス許可を自動的には設定しません。Windows ノードを使用している場合は、アクセスエントリ API を利用するか、`aws-auth` `ConfigMap` を直接更新することで、アクセスを管理する必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
起動テンプレートに AMI ID が指定されていない場合はユーザーデータで Windows Amazon EKS ブートストラップスクリプトを使用して Amazon EKS を設定しないでください。
ユーザーデータの例は次のとおりです。
```
Write-Host "Running custom user data script"
```
## AMI を指定する
以下のいずれかの要件がある場合は起動テンプレートの `ImageId` フィールドで AMI ID を指定します。追加情報については要件を選択してください。
### Amazon EKS に最適化された Linux/Bottlerocket AMI に含まれる `bootstrap.sh` ファイルに引数を渡すためのユーザーデータを提供する
ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。例えば、ブートストラップでは追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数を使用できます。起動テンプレートを指定せずに、`eksctl` を使用して引数を `bootstrap.sh` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。
**起動テンプレートを指定しない eksctl**
*my-nodegroup.yaml* という名前のファイルを以下の内容で作成します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ `ami-1234567890abcdef0 ` に最適化された AMI ID を取得するには、次のセクションを参照してください。
+ [推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)
+ [推奨 Bottlerocket AMI ID を取得する](retrieve-ami-id-bottlerocket.md)
+ [推奨 Microsoft Windows AMI ID を取得する](retrieve-windows-ami-id.md)
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
利用可能な `eksctl` `config` ファイルオプションについては「`eksctl` ドキュメント」の「[Config file schema](https://eksctl.io/usage/schema/)」(Config ファイルスキーマ) を参照してください。`eksctl` ユーティリティは引き続き起動テンプレートを作成し、`config` ファイルに提供したデータを使用してユーザーデータを設定します。
次のコマンドを使用して、ノードグループを作成します。
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**起動テンプレートのユーザーデータ**
起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`--apiserver-endpoint`、`--b64-cluster-ca`、および `--dns-cluster-ip` 引数はオプションです。しかし、これらを定義すると、`bootstrap.sh` スクリプトによる `describeCluster` 呼び出しを避けることができます。これはプライベートクラスターのセットアップや、ノードを頻繁にスケールインおよびスケールアウトするクラスターで役立ちます。`bootstrap.sh` スクリプトの詳細については、GitHub で「[bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)」ファイルを参照してください。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ この例ではカスタムの `max-pods` 値を設定するために `kubelet` 引数を指定します。その際、Amazon EKS 最適化 AMI に含まれている `bootstrap.sh` スクリプトを使用します。*my-max-pods-value* を選択する方法については「」を参照してください。マネージド型ノードグループを使用する場合の `maxPods` の決定方法の詳細については、「[maxPods の決定方法](choosing-instance-type.md#max-pods-precedence)」を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Amazon EKS に最適化された Windows AMI に含まれる `Start-EKSBootstrap.ps1` ファイルに引数を渡すためのユーザーデータを提供する
ブートストラップとはインスタンスの起動時に実行できるコマンドの追加を表す用語です。起動テンプレートを指定せずに、`eksctl` を使用して引数を `Start-EKSBootstrap.ps1` スクリプトに渡すことができます。または起動テンプレートのユーザーデータセクションに情報を指定することでこれを行うことができます。
カスタム Windows AMI ID を指定する場合は、次の考慮事項に留意してください。
+ 起動テンプレートを使用し、必要なブートストラップコマンドをユーザーデータセクションに入力する必要があります。目的の Windows ID を取得するには、「[最適化された Windows AMI を使用してノードを作成する](eks-optimized-windows-ami.md)」のテーブルを使用できます。
+ いくつかの制限と条件があります。例えば、`eks:kube-proxy-windows` を AWS IAM 認証 設定マップに追加する必要があります。詳細については「[AMI ID を指定する場合の制限と条件](#mng-ami-id-conditions)」を参照してください。
起動テンプレートのユーザーデータセクションで次の情報を指定します。各*サンプル値*は独自の値に置き換えます。`-APIServerEndpoint`、`-Base64ClusterCA`、および `-DNSClusterIP` 引数はオプションです。しかし、これらを定義すると、`Start-EKSBootstrap.ps1` スクリプトによる `describeCluster` 呼び出しを避けることができます。
+ 必須となる引数はクラスター名 (*マイクラスター*) のみです。
+ クラスターの *認証機関* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ クラスターの *api-server-endpoint* を取得するには次のコマンドを実行してください。
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ 最終的に、`--dns-cluster-ip` の値はサービス CIDR を示す `.10` となります。クラスターの *service-cidr* を取得するには次のコマンドを実行してください。例えば、戻り値が `ipv4 10.100.0.0/16` であれば、自分の値は *10.100.0.10* です。
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ その他の引数については「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
**注記**
カスタムサービス CIDR を使用している場合は`-ServiceCIDR` パラメータを使用して指定する必要があります。そうしないと、クラスター内の Pod の DNS 解決が失敗します。
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### 特定のセキュリティ、コンプライアンス、または社内的なポリシー要件のために、カスタム AMI を実行する
詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)」を参照してください。Amazon EKS AMI ビルド仕様にはAmazon Linux をベースにしたカスタム Amazon EKS AMI を構築するためのリソースと設定スクリプトが含まれています。詳細については、GitHubの「[Amazon EKS AMI ビルド仕様](https://github.com/awslabs/amazon-eks-ami/)」を参照してください。他のオペレーティングシステムがインストールされたカスタム AMI を作成するには、GitHubの「[Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis)」を参照してください。
マネージドノードグループで使用される起動テンプレートで AMI ID に動的パラメータ参照を使用することはできません。
**重要**
AMI を指定する場合、Amazon EKS はクラスターのコントロールプレーンバージョンに対して AMI に埋め込まれた Kubernetes バージョンを検証しません。ユーザーは、カスタム AMI の Kubernetes バージョンが以下の [Kubernetes バージョンスキューポリシー](https://kubernetes.io/releases/version-skew-policy)に準拠していることを確認する責任があります。
ノード上の `kubelet` バージョンはクラスターバージョンより新しいものであってはならない
ノード上の `kubelet` バージョンは、お使いのクラスターバージョン (Kubernetes バージョン `1.28` およびそれ以降) から最大 マイナーバージョン 3 つ前まで、またはクラスターバージョン (Kubernetes バージョン `1.27` およびそれ以前) から最大 マイナーバージョン 2 つ前までである必要がある
バージョンスキューポリシーに違反したマネージド型ノードグループを作成すると、次の結果になる可能性があります。
ノードをクラスターに結合できない
未定義の動作または API の非互換性
クラスターの不安定性またはワークロード障害
AMI を指定する際、Amazon EKS ではユーザーデータをマージしません。代わりに、ノードのクラスターへの参加に必要な `bootstrap` コマンドを、ユーザーが提供する必要があります。ノードがクラスターに参加できない場合、アマゾン EKS `CreateNodegroup` および `UpdateNodegroupVersion` アクションも失敗します。
## AMI ID を指定する場合の制限と条件
以下に、マネージド型ノードグループで AMI ID を指定する際の制限と条件を示します。
+ 起動テンプレートで AMI ID を指定する場合と、AMI ID を指定しない場合は新しいノードグループを作成して切り替える必要があります。
+ 新しい AMI バージョンが利用可能になっても、コンソールでは通知を表示しません。ノードグループを新しい AMI バージョンに更新するには更新された AMI ID で新しいバージョンの起動テンプレートを作成する必要があります。次に、新しい起動テンプレートバージョンでノードグループを更新する必要があります。
+ AMI ID を指定した場合はAPI の次のフィールドを設定することはできません。
+ `amiType`
+ `releaseVersion`
+ `version`
+ AMI ID を指定する場合、API で設定されたすべての `taints` は非同期に適用されます。ノードがクラスターに参加する前にテイントを適用するには`--register-with-taints` コマンドラインフラグを使用してユーザーデータ内の `kubelet` にテイントを渡す必要があります。詳細については、Kubernetes ドキュメントの「[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)」を参照してください。
+ Windows マネージド型ノードグループのカスタム AMI ID を指定するときは、AWS IAM オーセンティケーター設定マップに `eks:kube-proxy-windows` を追加します。これはDNS が正しく機能するために必要です。
1. AWS IAM 認証 設定マップを編集用に開きます。
```
kubectl edit -n kube-system cm aws-auth
```
1. このエントリを、Windows ノードに関連付けられた各 `rolearn` の下にある `groups` リストに追加します。設定マップは [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)に似ているはずです。
```
- eks:kube-proxy-windows
```
1. ファイルを保存し、テキストエディタを終了します。
+ カスタム起動テンプレートを使用する AMI の場合、マネージドノードグループのデフォルト `HttpPutResponseHopLimit` は `2` に設定されます。
# クラスターからマネージドノードグループを削除する
このトピックでは、Amazon EKS マネージド型ノードグループを削除する方法について説明します。マネージド型ノードグループを削除すると、まず Amazon EKS が Auto Scaling グループの最小サイズ、最大サイズ、および必要なサイズをゼロに設定します。これにより、ノードグループがスケールダウンされます。
各インスタンスが終了する前に、Amazon EKS はそのノードを排出するシグナルを送信します。排出プロセス中、Kubernetes はノード上の各ポッドに対して、設定されている `preStop` ライフサイクルフックを実行し、コンテナに `SIGTERM` シグナルを送信してから、正常なシャットダウンのために `terminationGracePeriodSeconds` の間待機します。5 分後もノードが排出されない場合、Amazon EKS は自動スケーリングにインスタンスの強制終了を続行させます。すべてのインスタンスが終了すると、Auto Scaling グループは削除されます。
**重要**
クラスター内の、他のマネージド型ノードグループで使用されていないノード IAM ロールを使用している、マネージド型ノードグループを削除すると、そのロールは `aws-auth` `ConfigMap` から削除されます。クラスター内のいずれかのセルフマネージド型ノードグループが同じノード IAM ロールを使用している場合、セルフマネージド型ノードは `NotReady` ステータスに移行します。さらに、クラスター操作も中断されます。クラスターのプラットフォームバージョンが「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」の前提条件セクションに記載されている最低バージョン以上である場合、セルフマネージドノードグループにのみ使用しているロールのマッピングを追加するには、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。プラットフォームバージョンがアクセスエントリに必要な最小バージョンより前の場合は、エントリを `aws-auth` `ConfigMap` に追加し直すことができます。詳細については、ターミナルに `eksctl create iamidentitymapping --help` を入力してください。
マネージド型ノードグループを削除するには、以下を使用します。
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [AWS マネジメントコンソール](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**マネージド型ノードグループを `eksctl` を使用して削除する**
次のコマンドを入力します。`` をすべて自分の値に置き換えてください。
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
その他のオプションについては、`eksctl` ドキュメントの「[ノードグループの削除と排出](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups)」を参照してください。
## AWS マネジメントコンソール
**マネージド型ノードグループを AWS マネジメントコンソール を使用して削除する**
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[クラスター]** ページで、削除するノードグループを含むクラスターを選択します。
1. 選択したクラスターページで、**[コンピューティング]** タブを選択します。
1. **[Node groups]** (ノードグループ) セクションで、削除するノードグループを選択してください。その後、**[削除]** をクリックします。
1. **[ノードグループの削除]** 確認ダイアログボックスで、ノードグループの名前を入力します。その後、**[削除]** をクリックします。
## AWS CLI
**マネージド型ノードグループを AWS CLI を使用して削除する**
1. 次のコマンドを入力します。`` をすべて自分の値に置き換えてください。
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. CLI 設定で `cli_pager=` が設定されている場合は、キーボードの矢印キーを使用して、応答出力をスクロールします。終了したら `q` キーを押します。
その他のオプションについては、「*AWS CLI コマンドリファレンス*」の ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` コマンドを参照してください。
# セルフマネージドノードでノードを自分自身で維持する
クラスターには、Pod がスケジュールされている Amazon EC2 ノードが 1 つ以上含まれています。Amazon EKS ノードは AWS アカウントで実行され、クラスター API サーバーエンドポイントを介してクラスターのコントロールプレーンに接続します。Amazon EC2 料金に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
クラスターには、複数のノードグループを含めることができます。各ノードグループには、[Amazon EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)にデプロイされる 1 つ以上のノードが含まれます。グループ内のノードのインスタンスタイプは、[Karpenter](https://karpenter.sh/) による[属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)を使用するときなどに、異なる場合があります。ノードグループ内のすべてのインスタンスは、[Amazon EKS ノードの IAM ロール](create-node-role.md)を使用する必要があります。
Amazon EKS は、Amazon EKS 最適化 AMI と呼ばれる特殊な Amazon マシンイメージ (AMI) を提供します。AMI は Amazon EKS と連携するように設定されています。そのコンポーネントには `containerd`、`kubelet`、および AWS IAM Authenticator が含まれます。また、AMI にはクラスターのコントロールプレーンを自動的に検出して接続を許可する、特別な[ブートストラップスクリプト](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)も含まれます。
CIDR ブロックを使用してクラスターのパブリックエンドポイントへのアクセスを制限する場合は、プライベートエンドポイントアクセスも有効にすることをお勧めします。これは、ノードがクラスターと通信できるようにするためです。プライベートエンドポイントが有効になっていない場合、パブリックアクセスに指定する CIDR ブロックに、VPC からの出力ソースを含める必要があります。詳細については、「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
Amazon EKS クラスターにセルフマネージド型ノードを追加するには、次のトピックを参照してください。セルフマネージドノードを手動で起動する場合は、各ノードに次のタグを追加すると共に、`` がクラスターに一致することを確認します。詳細については、「[個々のリソースでのタグの追加と削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags)」を参照してください。このガイドの手順に従うと、必要なタグがノードに自動的に追加されます。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/` | `owned` |
**重要**
Amazon EC2 インスタンスメタデータサービス (IMDS) のタグは、EKS ノードと互換性がありません。インスタンスメタデータタグを有効にすると、タグ値でのスラッシュ (「/」) の使用が防止されます。この制限により、特に Karpenter や Cluster Autoscaler などのノード管理ツールを使用する場合、インスタンスの起動が失敗する可能性があります。これらのサービスは、スラッシュを含むタグに依存して適切に機能しているためです。
Kubernetes の一般的な視点から見たノードの詳細については、Kubernetes のドキュメントの「[Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/)」を参照してください。
**Topics**
+ [セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)
+ [セルフマネージド Bottlerocket ノードの作成](launch-node-bottlerocket.md)
+ [セルフマネージド Microsoft Windows ノードの作成](launch-windows-workers.md)
+ [セルフマネージドの Ubuntu Linux ノードを作成する](launch-node-ubuntu.md)
+ [クラスターのためにセルフマネージドノードを更新する](update-workers.md)
# セルフマネージド Amazon Linux ノードを作成する
このトピックでは、Amazon EKS クラスターに登録されている Linux ノードの Auto Scaling グループを起動する方法を説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。`eksctl` または AWS マネジメントコンソールを使用して、セルフマネージド型の Amazon Linux ノードを起動することもできます。AWS アウトポスト でノードを起動する必要がある場合は「[AWS Outposts で Amazon Linux ノードを作成する](eks-outposts-self-managed-nodes.md)」を参照してください。
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS アウトポスト、AWS 波長、または AWS ローカルゾーンs が有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。
+ ノードが使用する既存の IAM 役割。作成する場合は「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。この役割に VPC CNI のポリシーがどちらも含まれていない場合、VPC CNI ポッドには以下の別の役割が必要です。
+ (オプションですが推奨) 必要な IAM ポリシーがアタッチされた独自の IAM ロールで構成された Amazon VPC CNI plugin for Kubernetes アドオン。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
+ 「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」に記載されている考慮事項に精通していること。選択したインスタンスタイプによってはクラスターと VPC に関する追加の前提条件がある場合もあります。
セルフマネージド Linux ノードは次のいずれかを使用して起動できます。
+ [`eksctl`](#eksctl_create_managed_amazon_linux)
+ [AWS マネジメントコンソール](#console_create_managed_amazon_linux)
## `eksctl`
**`eksctl` を使用してセルフマネージド型の Linux ノードを起動する**
1. デバイスまたは AWS クラウドシェル にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降をインストールします。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. (オプション) **[AmazonEKS\$1CNI\$1Policy]** マネージド IAM ポリシーが [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合は、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. 次のコマンドは既存のクラスターにノードグループを作成します。*al-nodes* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。残りの*サンプル値*は独自の値に置き換えます。デフォルトでは、ノードはコントロールプレーンと同じ Kubernetes バージョンで作成されます。
`--node-type` の値を選択する前に、[「最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を確認してください。
*my-key* を Amazon EC2 キーペアまたはパブリックキーの名前に置き換えます。このキーは起動後のノードに SSH 接続するために使用されます。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
次のコマンドを使用して、ノードグループを作成します。
**重要**
ノードグループを AWS アウトポスト、波長、または ローカルゾーンs サブネットにデプロイする場合、追加の考慮事項があります。
クラスターを作成したときに、サブネットが渡されていない必要があります。
ノードグループはサブネットと ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` を指定する設定ファイルを使用して作成する必要があります。詳細については「`eksctl` ドキュメント」の「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。
```
eksctl create nodegroup \
--cluster my-cluster \
--name al-nodes \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access \
--managed=false \
--ssh-public-key my-key
```
次のノードグループをデプロイするには
+ デフォルト設定よりもはるかに多くの IP アドレスを Pod に割り当てることができるノードグループについては、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
+ インスタンスのブロックとは異なる CIDR ブロックから `IPv4` アドレスを Pod に割り当てることができるノードグループについては、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
+ Pod とサービスに `IPv6` アドレスを割り当てることができるノードグループについては、「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ アウトバウンドインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
すべての使用可能なオプションとデフォルト値の一覧を表示するには次のコマンドを入力してください。
```
eksctl create nodegroup --help
```
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。
1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
## AWS マネジメントコンソール
**ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の リナックス ノードを起動する**`
1. AWS クラウドフォーメーション テンプレートの最新バージョンをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
```
1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動する必要があります。
1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. **[スタックの作成]** を選択し、**[新しいリソースを使用 (標準)]** を選択してください。
1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択し、**[ファイルを選択]** を選択してください。
1. ダウンロードした `amazon-eks-nodegroup.yaml` ファイルを選択してください。
1. **[次へ]** を選択してください。
1. **[スタックの詳細の指定]** ページで、必要に応じて次のパラメータを入力し、**[次へ]** を選択してください。
+ **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、*マイクラスター-nodes* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。この名前はクラスター名と同じにする必要があります。同じでない場合、ノードはクラスターに参加できません。
+ [**クラスター制御プレーンセキュリティグループ**]: [VPC](creating-a-vpc.md) の作成時に生成した AWS クラウドフォーメーション 出力の [**セキュリティグループs**] 値を選択してください。
次のステップでは該当するグループを取得する 1 つのオペレーションを説明します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターの名前を選択してください。
1. **[ネットワーキング]** タブを選択してください。
1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。
+ **[ApiServerEndpoint]**: EKS クラスターの API サーバーエンドポイントを入力します。これは EKS クラスターコンソールの [詳細] セクションにあります。
+ **[CertificateAuthorityData]**: base64 でエンコードされた認証機関データを入力します。これは、EKS クラスターコンソールの [詳細] セクションにもあります。
+ **[ServiceCidr]**: クラスター内の Kubernetes サービスに IP アドレスを割り当てるために使用される CIDR 範囲を入力します。これは、EKS クラスターコンソールの [ネットワーク] タブにあります。
+ **[AuthenticationMode]**: EKS クラスターコンソール内の [アクセス] タブを確認して、EKS クラスターで使用されている認証モードを選択します。
+ **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。
+ **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。
+ **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。
+ **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
+ **[NodeImageIdSSMParam]**: 最新の Amazon EKS 最適化 Amazon Linux 2023 AMI の Amazon EC2 Systems Manager のパラメータが、可変 Kubernetes バージョン用に事前設定されています。Amazon EKS でサポートされている別の Kubernetes マイナーバージョンを使用するには、*1.XX* を別の[サポートされているバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。クラスターと同じ Kubernetes バージョンを指定することをお勧めします。
*アマゾンリナックス-2023* を別の AMI タイプに置き換えることもできます。詳細については、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。
**注記**
Amazon EKS ノード AMI は Amazon リナックス をベースとしています。[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/alas2023.html)で Amazon Linux 2023 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する [RSS フィード](https://alas.aws.amazon.com/AL2023/alas.rss)をサブスクライブします。セキュリティおよびプライバシーイベントには問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。
+ **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。ここで値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。
+ **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。
+ **[ノードボリューム型]**: ノードのルートボリュームタイプを指定します。
+ **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
+ **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を入力してください。
+ **[Subnets]**: VPC 用に作成したサブネットを選択してください。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」で説明されている手順で VPC を作成した場合は起動するノードの VPC 内のプライベートサブネットのみを指定します。クラスターの **[ネットワーキング]** タブから、各サブネットリンクを開き、プライベートのサブネットを確認できます。
**重要**
いずれかのサブネットがパブリックサブネットである場合はパブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、[Amazon EKS AWS クラウドフォーメーション VPC テンプレート](creating-a-vpc.md)を使用して、または `eksctl` を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については「[サブネットのパブリック IPv4 アドレス属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。
サブネットにインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」の考慮事項と追加の手順を確認してください。
AWS アウトポスト、波長、または ローカルゾーンs サブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。
1. **[スタックオプションの設定]** ページで、希望する設定を選択し、**[次へ]** を選択してください。
1. **[AWS クラウドフォーメーション が IAM リソースを作成する可能性を認識しています]** の左にあるチェックボックスを選択して、**[スタックの作成]** を選択してください。
1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。`EKS API` または `EKS API and ConfigMap` 認証モードを使用している場合は、これが最後のステップです。
1. `ConfigMap` 認証モードを使用している場合は、作成されたノードグループの **NodeInstanceRole** を記録します。
**ステップ 2: ノードを有効にしてクラスターに参加する**
**注記**
次の 2 つのステップは、EKS クラスター内で Configmap 認証モードを使用している場合にのみ必要です。さらに、アウトバウンドのインターネットアクセスのないプライベート VPC でノードを起動する場合はノードが VPC 内からクラスターに参加できるようにしてください。
1. `aws-auth` `ConfigMap` がすでにあるかどうかを確認します。
```
kubectl describe configmap -n kube-system aws-auth
```
1. `aws-auth` `ConfigMap` が表示されている場合は必要に応じて更新してください。
1. 編集する `ConfigMap` を開きます。
```
kubectl edit -n kube-system configmap/aws-auth
```
1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** 値に設定します。
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. ファイルを保存し、テキストエディタを終了します。
1. 「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示されたら、ストック `ConfigMap` を適用してください。
1. 設定マップをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. `aws-auth-cm.yaml` ファイルで、`rolearn` 値を前の手順で記録した **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、*マイノードインスタンス役割* を置き換えて次のコマンドを実行してください。
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。
```
kubectl apply -f aws-auth-cm.yaml
```
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
`Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。
**注記**
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
1. (GPU ノードのみ) GPU インスタンスタイプと Amazon EKS 最適化アクセラレーション AMI を選択した場合はクラスター上の DaemonSet として [Kubernetes 用の NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin)を適用する必要があります。次のコマンドを実行する前に、*vX.X.X* を必要となる [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
**ステップ 3: その他のアクション**
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Linux ノードをテストします。
1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
# セルフマネージド Bottlerocket ノードの作成
**注記**
マネージド型ノードグループでは、ユースケースにいくつかの利点がある場合があります。詳細については、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。
このトピックでは、Amazon EKS クラスターに登録する [Bottlerocket](https://aws.amazon.com/bottlerocket/) ノードの Auto Scaling グループを起動する方法について説明します。Bottlerocket は AWS が提供する Linux ベースのオープンソースのオペレーティングシステムで、仮想マシンやベアメタルホスト上でコンテナを実行するために使用できます。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。Botttlerocket の詳細については、GitHub の [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) と `eksctl` ドキュメント内の [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。
インプレースアップグレードについて詳しくは、GitHub の [Bottlerocket Update Operator](https://github.com/bottlerocket-os/bottlerocket-update-operator) を参照してください。
**重要**
Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Bottlerocket ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。
`x86` または Arm プロセッサを使用して Amazon EC2 インスタンスにデプロイできます。ただし、Inferentia チップがあるインスタンスにデプロイすることはできません。
Bottlerocket は、AWS CloudFormation と互換性があります。ただし、Amazon EKS の Bottlerocket ノードをデプロイするためにコピーできる公式の CloudFormation テンプレートはありません。
Bottlerocket のイメージには、SSH サーバーやシェルは付属していません。SSH で管理者コンテナを有効にし、ユーザーデータとともにブートストラップの設定ステップを渡すために、帯域外のアクセス方式を使用できます。詳細については、GitHub の「[bottleRocket readme.md](https://github.com/bottlerocket-os/bottlerocket)」のセクションを参照してください。
[探査](https://github.com/bottlerocket-os/bottlerocket#exploration)
[管理者コンテナ](https://github.com/bottlerocket-os/bottlerocket#admin-container)
[Kubernetes 設定](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings)
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、 `eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。注意: この手順は、`eksctl` で作成されたクラスターでのみ機能します。
1. 次のコンテンツをデバイスにコピーします。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-bottlerocket* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Arm インスタンスにデプロイするには、*m5.large* を Arm インスタンスタイプに置き換えます。*my-ec2-keypair-name* を、起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前に置き換えます。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。残りのサンプル値はすべて独自の値に置き換えます。置き換えが完了したら、変更したコマンドを実行して `bottlerocket.yaml` ファイルを作成します。
Arm Amazon EC2 インスタンスタイプを指定する場合は、デプロイする前に「[Amazon EKS 最適化 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。カスタム AMI を使用したデプロイの手順については、GitHub の [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) と、`eksctl` ドキュメントの [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。マネージド型ノードグループをデプロイするには、起動テンプレートを使用してカスタム AMI をデプロイします。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。
**重要**
ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットは渡さないでください。次の例では、サブネットを指定する必要があります。詳細については、`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[Config ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。*region-code* を、クラスターのある AWS リージョンに置き換えます。
```
cat >bottlerocket.yaml <
このトピックでは、Amazon EKS クラスターに登録されている Windows ノードの Auto Scaling グループの起動方法について説明します。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。
**重要**
Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Windows ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。
クラスターに対して Windows サポートを有効にします。Windows ノードグループを起動する前に、重要な考慮事項を確認することをお勧めします。詳細については、「[Windows サポートを有効にする](windows-support.md#enable-windows-support)」を参照してください。
次のいずれかを使用して、セルフマネージド型の Windows ノードを起動できます。
+ [`eksctl`](#eksctl_create_windows_nodes)
+ [AWS マネジメントコンソール](#console_create_windows_nodes)
## `eksctl`
**`eksctl` <2> を使用して自己管理型 Windows ノードを起動します。**
この手順では`eksctl` をインストール済みで、お使いの `eksctl` バージョンが `0.215.0` 以上であることが必要です。お使いのバージョンは以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
**注記**
この手順は`eksctl` で作成されたクラスターに対してのみ機能します。
1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. この手順では既存のクラスターがあることを前提としています。Windows ノードグループの追加先となる Amazon EKS クラスターと Amazon Linux ノードグループがまだ存在しない場合は、[Amazon EKS – `eksctl` の使用を開始する](getting-started-eksctl.md) に従うことをお勧めします。このガイドはAmazon Linux ノードで Amazon EKS クラスターを作成する方法についての完全なチュートリアルを提供します。
次のコマンドを使用して、ノードグループを作成します。*地域コード* を、クラスターのある AWS リージョンに置き換えます。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前はクラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-windows* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*2019* を `2022` に置き換えて Windows Server 2022 を使用するか、もしくは `2025` に置き換えて Windows Server 2025 を使用できます。残りのサンプル値は独自の値に置き換えます。
**重要**
ノードグループを AWS Outposts、AWS 波長、または AWS ローカルゾーン サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、波長、または ローカルゾーン サブネットは渡さないでください。AWS Outposts、波長、または ローカルゾーンサブネットを指定した設定ファイルを使用して、ノードグループを作成します。詳細については`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[設定ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。
```
eksctl create nodegroup \
--region region-code \
--cluster my-cluster \
--name ng-windows \
--node-type t2.large \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false \
--node-ami-family WindowsServer2019FullContainer
```
**注記**
ノードがクラスターに参加できない場合はトラブルシューティングガイドの「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
`eksctl` コマンドで使用可能なオプションを表示するには次のコマンドを入力してください。
```
eksctl command -help
```
出力例は次のとおりです。ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Windows ノードをテストします。
1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については、「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
## AWS マネジメントコンソール
**前提条件**
+ 既存の Amazon EKS クラスターと Linux ノードグループ。これらのリソースがない場合は[Amazon EKS の使用を開始する](getting-started.md) のガイドのいずれかに従って作成することをお勧めします。これらのガイドでは、Linux ノードで Amazon EKS クラスターを作成する方法について説明しています。
+ Amazon EKS クラスターの要件を満たす、既存の VPC およびセキュリティグループ。詳細については[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)および[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)を参照してください。[Amazon EKS の使用を開始する](getting-started.md) のガイドでは要件を満たす VPC を作成します。または「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」に従って手動で作成することもできます。
+ Amazon EKS クラスターの要件を満たす VPC およびセキュリティグループを使用している、既存の Amazon EKS クラスター。詳細については「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。AWS Outposts、AWS 波長、または AWS ローカルゾーンが有効になっている AWS リージョンにサブネットがある場合はクラスターの作成時にそれらのサブネットが渡されるべきではありません。
**ステップ 1: AWS マネジメントコンソール を使用してセルフマネージド型の Windows ノードを起動する**
1. クラスターステータスが `ACTIVE` と表示されるまで待ちます。クラスターがアクティブになる前にノードを起動した場合、ノードはクラスターへの登録に失敗し、再起動が必要になります。
1. [AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation/)を開きます
1. **[スタックの作成]** を選択してください。
1. **[テンプレートを指定]** で、**[Amazon S3 URL]** を選択してください。
1. 次の URL をコピーして、**[Amazon S3 URL]** に貼り付けます。
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
```
1. **[次へ]** を 2 回選択してください。
1. **[スタックのクイック作成]** ページで、必要に応じて以下のパラメータを入力してください。
+ **スタック名**: AWS クラウドフォーメーション スタックのスタック名を選択してください。例えば、`my-cluster-nodes` という名前にすることができます。
+ **[クラスター名]**: Amazon EKS クラスターの作成時に使用した名前を入力してください。
**重要**
この名前は「[ステップ 1: Amazon EKS クラスターを作成する](getting-started-console.md#eks-create-cluster)」で使用した名前と完全に一致する必要があります。そうしないと、ノードはクラスターに参加できません。
+ **クラスター制御プレーンセキュリティグループ**: [VPC](creating-a-vpc.md) を作成する際に生成した AWS クラウドフォーメーション 出力からセキュリティグループを選択してください。次のステップでは該当するグループを取得する 1 つの方法を説明します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターの名前を選択してください。
1. **[ネットワーキング]** タブを選択してください。
1. **[クラスター制御プレーンセキュリティグループ]** ドロップダウンリストから選択する場合は**[追加のセキュリティグループ]** の値をリファレンスとして使用します。
+ **[ノードグループ名]**: ノードグループの名前を入力してください。この名前はノードに対して作成される自動スケーリングノードグループを識別するために後で使用できます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ **[ノードオートスケーリンググループ最小サイズ]**: ノードの 自動スケーリング グループがスケールインできる最小ノード数を入力してください。
+ **ノード自動スケーリンググループ希望容量**: スタック作成時にスケーリングする必要のあるノード数を入力してください。
+ **[NodeAutoScalingGroupMaxSize]**: ノードの 自動スケーリング グループがスケールアウトできる最大ノード数を入力してください。
+ **[ノードインスタンス型]**: ノードのインスタンスタイプを選択してください。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
**注記**
最新バージョンの [Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) でサポートされているインスタンスタイプは、GitHub 上の [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) にリストされています。サポートされている最新のインスタンスタイプを利用するには、CNI のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
+ **[NodeImageIdSSMParam]**: 現在推奨されている Amazon EKS 最適化 Windows Core AMI ID の Amazon EC2 Systems Manager パラメータが事前設定されています。Windows の通常版を使用する場合は、*Core* を `Full` に置き換えます。
+ **ノードイメージId**: (オプション) (Amazon EKS 最適化 AMI の代わりに) 独自のカスタム AMI を使用している場合はAWS リージョンのノード AMI ID を入力してください。このフィールドに値を指定すると、**[ノードイメージIdSSMParam]** フィールドの値はすべて上書きされます。
+ **[ノードボリュームサイズ]**: ノードのルートボリュームのサイズを GiB 単位で指定します。
+ **[キー名]**: 起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力してください。Amazon EC2 キーペアをまだ持っていない場合はAWS マネジメントコンソール で作成できます。詳細については「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)」を参照してください。
**注記**
ここでキーペアを指定しないと、AWS クラウドフォーメーション スタックの作成は失敗します。
+ [**ブートストラップ引数**]: `kubelet` を使用して、`-KubeletExtraArgs` の追加引数など、ノードブートストラップスクリプトに渡すオプションの引数を指定します。
+ **[無効IMDSv1]**: 各ノードはデフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。IMDSv1 は無効にできます。今後ノードグループのノードおよび Pod が MDSv1 を使用しないようにするには、**DisableIMDSv1** を **true** に設定します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。
+ **[VpcId]**: 作成した [VPC](creating-a-vpc.md) の ID を選択します。
+ **[NodeSecurityGroups]**: [VPC](creating-a-vpc.md) の作成時に Linux ノードグループ用に作成したセキュリティグループを選択します。Linux ノードに複数のセキュリティグループがアタッチされている場合、それらのすべてを指定します。これは、たとえば、Linux ノードグループが `eksctl` を使用して作成された場合に行います。
+ **[Subnets]**: 作成したサブネットを選択してください。「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」で説明されている手順で VPC を作成した場合は起動するノードの VPC 内のプライベートサブネットのみを指定します。
**重要**
いずれかのサブネットがパブリックサブネットである場合はパブリック IP アドレスの自動割り当て設定を有効にする必要があります。この設定がパブリックサブネットに対して有効になっていない場合、そのパブリックサブネットにデプロイするノードにはパブリック IP アドレスが割り当てられず、クラスターやその他の AWS のサービスと通信できなくなります。2020 年 3 月 26 日以前に、[Amazon EKS AWS クラウドフォーメーション VPC テンプレート](creating-a-vpc.md)を使用して、または `eksctl` を使用してサブネットがデプロイされた場合、パブリックサブネットではパブリック IP アドレスの自動割り当てが無効になります。サブネットのパブリック IP アドレス割り当てを有効にする方法については「[サブネットのパブリック IPv4 アドレス属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。ノードがプライベートサブネットにデプロイされている場合、NAT ゲートウェイを介してクラスターや他の AWS のサービスと通信できます。
サブネットにインターネットアクセスがない場合は「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」の考慮事項と追加の手順を確認してください
AWS Outposts、波長、またはローカルゾーンサブネット を選択する場合はクラスターの作成時にサブネットを渡さないようにします。
1. スタックが IAM リソースを作成する可能性があることを確認し、**[スタックの作成]** を選択してください。
1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。
1. 作成されたノードグループの [**NodeInstanceRole**] を記録します。これは、Amazon EKS Windows ノードを設定するときに必要になります。
**ステップ 2: ノードを有効にしてクラスターに参加する**
1. `aws-auth` `ConfigMap` がすでにあるかどうかを確認します。
```
kubectl describe configmap -n kube-system aws-auth
```
1. `aws-auth` `ConfigMap` が表示されている場合は必要に応じて更新してください。
1. 編集する `ConfigMap` を開きます。
```
kubectl edit -n kube-system configmap/aws-auth
```
1. 必要に応じて新しい `mapRoles` エントリを追加します。`rolearn` 値を、前の手順で記録した **[ノードインスタンス役割]** の値に設定します。
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows
[...]
```
1. ファイルを保存し、テキストエディタを終了します。
1. 「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示されたら、ストック `ConfigMap` を適用してください。
1. 設定マップをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
```
1. `aws-auth-cm-windows.yaml` ファイルで、`rolearn` 値を、前の手順で記録した該当する **[ノードインスタンス役割]** 値に設定します。これを行うにはテキストエディタを使用するか、このサンプル値を置き換えて次のコマンドを実行してください。
```
sed -i.bak -e 's||my-node-linux-instance-role|' \
-e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml
```
**重要**
このファイルの他の行は変更しないでください。
Windows ノードと Linux ノードの両方に同じ IAM ロールを使用しないでください。
1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。
```
kubectl apply -f aws-auth-cm-windows.yaml
```
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
`Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。
**注記**
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
ノードがクラスターに参加できない場合はトラブルシューティングの章にある「[ノードをクラスターに結合できません](troubleshooting.md#worker-node-fail)」を参照してください。
**ステップ 3: その他のアクション**
1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、クラスターと Windows ノードをテストします。
1. (オプション) **AmazonEKS\$1CNI\$1Policy** マネージド IAM ポリシー (`IPv4` クラスターがある場合) または *AmazonEKS\$1CNI\$1IPv6\$1Policy* (`IPv6` クラスターがある場合には[ユーザー自身が作成した](cni-iam-role.md#cni-iam-role-create-ipv6-policy)もの) が [Amazon EKS ノードの IAM ロール](create-node-role.md)にアタッチされている場合、代わりに Kubernetes `aws-node` サービスアカウントに関連付けた IAM ロールに割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
# セルフマネージドの Ubuntu Linux ノードを作成する
**注記**
マネージド型ノードグループでは、ユースケースにいくつかの利点がある場合があります。詳細については、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。
このトピックでは、[Amazon Elastic Kubernetes Service (EKS) ノード上で Ubuntu](https://cloud-images.ubuntu.com/aws-eks/) の Auto Scaling グループを起動するか、あるいは Amazon EKS クラスターに登録される [Amazon Elastic Kubernetes Service (EKS) ノード上で Ubuntu Pro](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) の Auto Scaling グループを起動する方法について説明します。EKS で動作する Ubuntu と Ubuntu Pro は、公式の Ubuntu Minimal LTS に基づいており、AWS と共同で開発されているカスタム AWS カーネルを搭載し、これまで特に EKS 向けに構築されています。Ubuntu Pro は、EKS 延長サポート期間、カーネルライブパッチ、FIPS の遵守、および無制限の Pro コンテナを実行する機能をサポートすることで、さらなるセキュリティの強化も図っています。
ノードがクラスターに参加したら、それらのノードにコンテナ化したアプリケーションをデプロイできるようになります。詳細については、「[Ubuntu on AWS](https://documentation.ubuntu.com/aws/en/latest/)」のドキュメントおよび `eksctl` ドキュメントの「[Custom AMI support](https://eksctl.io/usage/custom-ami-support/)」を参照してください。
**重要**
Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Ubuntu ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。
`x86` または Arm プロセッサを使用して Amazon EC2 インスタンスにデプロイできます。ただし、インスタンスに Inferentia チップがある場合は、先に [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) をインストールしておく必要があります。
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、 `eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。注意: この手順は、`eksctl` で作成されたクラスターでのみ機能します。
1. 次のコンテンツをデバイスにコピーします。`my-cluster` を自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字はアルファベット文字である必要があります。また、100 文字より長くすることはできません。`ng-ubuntu` をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Arm インスタンスにデプロイするには、`m5.large` を Arm インスタンスタイプに置き換えます。`my-ec2-keypair-name` を、起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前に置き換えます。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。残りのサンプル値はすべて独自の値に置き換えます。置き換えが完了したら、変更したコマンドを実行して `ubuntu.yaml` ファイルを作成します。
**重要**
ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットは渡さないでください。次の例では、サブネットを指定する必要があります。詳細については、`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[Config ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。*region-code* を、クラスターのある AWS リージョンに置き換えます。
```
cat >ubuntu.yaml <
Amazon EKS に最適化された最新の AMI がリリースされたら、セフルマネージド型ノードグループのノードを新しい AMI に置き換えることを検討してください。同様に、Amazon EKS クラスターの Kubernetes バージョンを更新した場合は、ノードを更新して、同じ Kubernetes バージョンのノードを使用します。
**重要**
このトピックでは、セルフマネージド型ノードのノードの更新について説明します。[マネージドノードグループ](managed-node-groups.md)を使用している場合は、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。
クラスター内のセルフマネージド型ノードグループを更新して新しい AMI を使用するには、2 つの基本的な方法があります。
**[アプリケーションを新しいノードグループに移行する](migrate-stack.md)**
新しいノードグループを作成し、Pod をそのグループに移行します。新しいノードグループへの移行は、既存の AWS CloudFormation スタックで AMI ID を単に更新するよりも適切です。これは、移行プロセスが古いノードグループを `NoSchedule` として[テイント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)に設定し、新しいスタックが既存の Pod ワークロードを受け入れる準備ができた後にそのノードをドレインするためです。
**[AWS CloudFormation ノードスタックを更新する](update-stack.md)**
既存のノードグループの AWS CloudFormation スタックを更新して、新しい AMI が使用されるようにします。この方法は、`eksctl` を使用して作成されたノードグループではサポートされていません。
# アプリケーションを新しいノードグループに移行する
このトピックは、新しいノードグループを作成し、既存のアプリケーションを新しいグループに適切に移行し、クラスターから古いノードグループを削除する方法について説明します。新しいノードグループに移行するには、`eksctl` または AWS マネジメントコンソール を使用します。
+ [`eksctl`](#eksctl_migrate_apps)
+ [AWS マネジメントコンソール および AWS CLI](#console_migrate_apps)
## `eksctl`
**`eksctl` を使用してアプリケーションを新しいノードグループに移行する**
eksctl を移行に使用する方法の詳細については、`eksctl` ドキュメントの「[管理対象外のノードグループ](https://eksctl.io/usage/nodegroup-unmanaged/)」を参照してください。
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
**注記**
この手順は、`eksctl` で作成されたクラスターとノードグループに対してのみ機能します。
1. *my-cluster* をクラスター名に置き換えて、既存のノードグループの名前を取得します。
```
eksctl get nodegroups --cluster=my-cluster
```
出力例は次のとおりです。
```
CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12
```
1. 次のコマンドを使用して、`eksctl` で新しいノードグループを起動します。コマンドのすべての*サンプル値*を独自の値に置き換えます。バージョン番号をお使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。
次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
+ IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
+ クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。
詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
Pod から IMDS へのアクセスをブロックするには、次のコマンドに `--disable-pod-imds` オプションを追加します。
**注記**
使用可能なフラグとその説明については、「https://eksctl.io/」を参照してください。
```
eksctl create nodegroup \
--cluster my-cluster \
--version 1.35 \
--name standard-nodes-new \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--managed=false
```
1. 前のコマンドが完了したら、次のコマンドを使用して、すべてのノードが `Ready` 状態になったことを確認します。
```
kubectl get nodes
```
1. 次のコマンドを使用して、元のノードグループを削除します。このコマンドで、すべての*サンプル値*を自分のクラスター名とノードグループ名に置き換えます。
```
eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
```
## AWS マネジメントコンソール および AWS CLI
**AWS マネジメントコンソール と AWS CLI を使用してアプリケーションを新しいノードグループに移行する**
1. 新しいノードグループを起動するには、「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」で説明されている手順に従います。
1. スタックの作成が完了したら、コンソールで選択し、**[出力]** を選択してください。
1. 作成されたノードグループの **NodeInstanceRole** を記録します。Amazon EKS ノードをクラスターに追加するには、これが必要です。
**注記**
追加の IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合は、この同じポリシーを新しいノードグループの IAM ロールにアタッチして、新しいグループでその機能を管理します。これは、たとえば、Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) のアクセス許可を追加した場合に適用されます。
1. 相互通信できるように、両方のノードグループのセキュリティグループを更新します。詳細については、「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。
1. 両方のノードグループのセキュリティグループ ID を記録します。これは、AWS CloudFormation スタックからの出力に、**NodeSecurityGroup** の値として表示されます。
次の AWS CLI コマンドを使用して、スタック名からセキュリティグループ ID を取得します。これらのコマンドで、`oldNodes` は、古いノードスタックの AWS CloudFormation スタック名、`newNodes` は、移行先のスタックの名前です。各*サンプル値*は独自の値に置き換えます。
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
```
1. 互いにトラフィックを受け入れるように、各ノードのセキュリティグループに進入ルールを追加します。
以下の AWS CLI コマンドでは、他のセキュリティグループからのすべてのプロトコルのトラフィックをすべて許可するインバウンドルールを各セキュリティグループに追加します。この設定により、ワークロードを新しいグループに移行している際に、各ノードグループ内の Pod が相互に通信できるようになります。
```
aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. `aws-auth` configmap を編集して、新しいノードインスタンスロールを RBAC にマッピングします。
```
kubectl edit configmap -n kube-system aws-auth
```
新しいノードグループの新しい `mapRoles` エントリを追加します。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: ARN of instance role (not instance profile)
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
- rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
```
*インスタンスロールの ARN (インスタンスプロファイルではない)* スニペットを、[前の手順](#node-instance-role-step)で記録した **NodeInstanceRole** の値に置き換えます。次に、更新された configmap を適用するには、ファイルを保存して閉じます。
1. ノードのステータスを監視し、新しいノードがクラスターに結合され、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
1. (オプション) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) を使用している場合は、スケーリングアクションの競合を回避するために、デプロイをゼロ (0) レプリカにスケールダウンします。
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. 以下のコマンドを使用して、`NoSchedule` で削除する各ノードをテイントに設定します。その目的は、ノードを置き換えたときにそのノードで新しい Pod がスケジュールまたは再スケジュールされないようにすることです。詳細については、Kubernetes ドキュメントの「[テイントと容認](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。
```
kubectl taint nodes node_name key=value:NoSchedule
```
ノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は `1.33`) のすべてのノードを識別してテイントに設定できます。バージョン番号をお使いのコントロールプレーンの Kubernetes バージョンよりも新しいものにすることはできません。また、コントロールプレーンの Kubernetes バージョンより 3 つ以上前のマイナーなバージョンにすることもできません。コントロールプレーンと同じバージョンを使用することをお勧めします。
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Tainting $node"
kubectl taint nodes $node key=value:NoSchedule
done
```
1. クラスターの DNS プロバイダーを決定します。
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
出力例は次のとおりです。このクラスターでは、DNS 解決に CoreDNS を使用していますが、クラスターからは `kube-dns` が返される場合もあります。
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. 現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドの出力が kubedns を返していた場合は、*coredns* を `kubedns` に置き換えます。
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. 次のコマンドを使用して、クラスターから削除する各ノードをドレーンします。
```
kubectl drain node_name --ignore-daemonsets --delete-local-data
```
ノードを新しい Kubernetes バージョンにアップグレードする場合は、次のコードスニペットを使用して、特定の Kubernetes バージョン (この場合は *1.33*) のすべてのノードを識別してドレインします。
```
K8S_VERSION=1.33
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
echo "Draining $node"
kubectl drain $node --ignore-daemonsets --delete-local-data
done
```
1. 古いノードのドレーンが完了したら、以前承認したセキュリティグループのインバウンドルールを取り消します。次に、AWS CloudFormation スタックを削除してインスタンスを終了してください。
**注記**
さらに IAM ポリシーを古いノードグループの IAM ロールにアタッチした場合 ([Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) に対するアクセス許可を追加する場合など) は、ロールからその追加ポリシーをデタッチしてから、AWS CloudFormation スタックを削除できます。
1. 先ほどノードのセキュリティグループ用に作成したインバウンドルールを取り消します。これらのコマンドで、`oldNodes` は、古いノードスタックの AWS CloudFormation スタック名、`newNodes` は、移行先のスタックの名前です。
```
oldNodes="old_node_CFN_stack_name"
newNodes="new_node_CFN_stack_name"
oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
--query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
--output text)
aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
--source-group $newSecGroup --protocol -1
aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
--source-group $oldSecGroup --protocol -1
```
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. 古いノードスタックを選択します。
1. **[削除]** を選択します。
1. **[スタックの削除]** 確認ダイアログボックスで、**[スタックを削除]** をクリックします。
1. `aws-auth` configmap を編集して、RBAC から古いノードインスタンスロールを削除します。
```
kubectl edit configmap -n kube-system aws-auth
```
古いノードグループの `mapRoles` エントリを削除します。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes>
```
更新された configmap を適用するには、ファイルを保存して閉じます。
1. (オプション) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) を使用している場合は、デプロイのスケーリングを 1 レプリカに戻します。
**注記**
必要に応じて、新しい Auto Scaling グループにタグ (`k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster` など) を付け、新しくタグ付けした Auto Scaling グループを参照するように、Cluster Autoscaler デプロイのコマンドを更新する必要があります。詳細については、「[AWS の Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws)」を参照してください。
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (オプション) 最新バージョンの [Amazon VPC CNI Plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するにはCNI のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
1. クラスターが DNS 解決 ([[migrate-determine-dns-step]](#migrate-determine-dns-step) を参照) に `kube-dns` を使用している場合は、`kube-dns` デプロイを 1 レプリカにスケールインします。
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
# AWS CloudFormation ノードスタックを更新する
このトピックは、新しい AMI を使用して既存の AWS CloudFormation セルフマネージド型ノードスタックを更新する方法について説明します。この手順を使用して、クラスターの更新後にノードを新しいバージョンの Kubernetes に更新することができます。それ以外の場合は、Kubernetes の既存バージョン用の Amazon EKS に最適化された最新の AMI に更新することができます。
**重要**
このトピックでは、セルフマネージド型ノードのノードの更新について説明します。「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」方法の詳細については、「[クラスターのためにマネージドノードグループを更新する](update-managed-node-group.md)」を参照してください。
最新のデフォルトの Amazon EKS ノード AWS CloudFormation テンプレートは、古い AMI を一度に 1 つずつ削除する前に、新しい AMI を使用してインスタンスをクラスターに起動するように設定されています。この設定により、ローリング更新中にクラスター内で Auto Scaling グループのアクティブなインスタンスが常に必要数確保されるようになります。
**注記**
この方法は、`eksctl` を使用して作成されたノードグループではサポートされていません。`eksctl` を使用してクラスターまたはノードグループを作成した場合は、「[アプリケーションを新しいノードグループに移行する](migrate-stack.md)」を参照してください。
1. クラスターの DNS プロバイダーを決定します。
```
kubectl get deployments -l k8s-app=kube-dns -n kube-system
```
出力例は次のとおりです。このクラスターでは、DNS 解決に CoreDNS を使用していますが、クラスターからは `kube-dns` が返される場合があります。使用しているバージョンの `kubectl` によって、出力が異なる場合があります。
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
coredns 1 1 1 1 31m
```
1. 現在のデプロイメントで実行しているレプリカが 2 つ未満の場合は、そのデプロイメントを 2 つのレプリカにスケールアウトします。前のコマンドの出力が kubedns を返していた場合は、*coredns* を `kube-dns` に置き換えます。
```
kubectl scale deployments/coredns --replicas=2 -n kube-system
```
1. (オプション) [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合は、スケーリングアクションの競合を回避するために、デプロイをゼロ (0) レプリカにスケールダウンします。
```
kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
```
1. 現在のノードグループのインスタンスタイプと必要なインスタンス数を決定します。グループの AWS CloudFormation テンプレートを更新する場合は、後でこれらの値を入力します。
1. Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
1. 左ナビゲーションペインの **[Launch Configurations]** (起動設定) を選択し、既存のノードの起動設定のインスタンスタイプを書き留めます。
1. 左ナビゲーションペインの **[Auto Scaling]** (グループ) を選択し、既存の Auto Scaling グループのノードの、インスタンスの **[Desired]** (必要) 数を書き留めます。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. ノードグループスタックを選択し、[**更新**] を選択します。
1. **[Replace current template]** (現在のテンプレートを置き換える) を選択し、**Amazon S3 URL** を選択します。
1. **Amazon S3 URL** で、ノードの AWS CloudFormation テンプレートの最新バージョンを使用していることを確認するために以下の URL をテキストエリアに貼り付けます。続いて、**[次へ]** を選択します。
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
```
1. **[Specify stack details]** (スタックの詳細の指定) ページで、以下のパラメータを指定し、**[Next]** (次へ) を選択します。
+ **[NodeAutoScalingGroupDesiredCapacity]** – [前のステップ](#existing-worker-settings-step)で記録した必要なインスタンス数を入力します。または、スタック更新時にスケーリングする必要のある新しいノード数を入力します。
+ **NodeAutoScalingGroupMaxSize** - ノードの Auto Scaling グループがスケールアウトする最大ノード数を入力します。この値は、必要な容量よりも少なくとも 1 ノード多い必要があります。これは、更新時にノード数を減らさずにノードのローリング更新を実行できるようにするためです。
+ **NodeInstanceType** — [前のステップ](#existing-worker-settings-step)で記録したインスタンスタイプを選択します。または、ノードに別のインスタンスタイプを選択します。異なるインスタンスタイプを選択する前に、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を確認してください。各 Amazon EC2 インスタンスタイプは最大数の Elastic Network Interface (ネットワークインターフェイス) をサポートし、各ネットワークインターフェイスは最大数の IP アドレスをサポートします。ワーカーノードと Pod には、それぞれ IP アドレスが割り当てられています。そのため、各 Amazon EC2 ノードで実行する Pod の最大数をサポートするインスタンスタイプを選択することが重要です。インスタンスタイプごとにサポートされるネットワークインターフェイスと IP アドレスのリストについては、「[各インスタンスタイプのネットワークインターフェイスごとの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。例えば、`m5.large` インスタンスタイプは、ワーカーノードと Pod に対して最大 30 の IP アドレスをサポートします。
**注記**
最新バージョンの [Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) でサポートされているインスタンスタイプは、GitHub 上の [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) に示されています。サポートされている最新のインスタンスタイプを利用するには、Amazon VPC CNI Plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
**重要**
AWS リージョンによっては利用できないインスタンスタイプがあります。
+ [**NodeImageIdSSMParam**]: 更新する AMI ID の Amazon EC2 Systems Manager パラメータです。次の値では、Kubernetes バージョン `1.35` 用の最新の Amazon EKS 最適化 AMI が使用されています。
```
/aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
```
*1.35* は、同一の [platform-version](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) に置き換えることができます。または、コントロールプレーンで実行されている Kubernetes バージョンより 1 つ前までのバージョンである必要があります。ノードは、コントロールプレーンと同じバージョンにしておくことをお勧めします。*amazon-linux-2* を別の AMI タイプに置き換えることもできます。詳細については、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。
**注記**
Amazon EC2 Systems Manager パラメータを使用すると、AMI ID を検索して指定することなく、後でノードを更新できます。AWS CloudFormation スタックがこの値を使用している場合、スタックの更新によって常に、指定された Kubernetes バージョンで推奨される最新の Amazon EKS 最適化 AMI が起動されます。これは、テンプレートの値を変更しない場合も同様です。
+ **NodeImageId** - 独自のカスタム AMI を使用するには、使用する AMI の ID を入力します。
**重要**
この値は、**NodeImageIdSSMParam** に指定されたすべての値を上書きします。**NodeImageIdSSMParam** 値を使用する場合は、 **NodeImageId** の値が空白であることを確認します。
+ **[DisableIMDSv1]** – 各ノードは、デフォルトでインスタンスメタデータサービスバージョン 1 (IMDSv1) および IMDSv2 をサポートします。ただし、IMDSv1 を無効にできます。ノードグループでスケジュールされているノードまたは Pod で IMDSv1 を使用しない場合は、**[true]** を選択します。IDMS の詳細については「[インスタンスメタデータサービスの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」を参照してください。サービスアカウントの IAM ロールを実装した場合は、AWS のサービスへのアクセスを必要とするすべての Pod に対し、必要なアクセス許可を直接割り当てます。これにより、クラスター内の Pod は、現在の AWS リージョンの取得など、その他の理由で IMDS へのアクセスを必要としません。次に、ホストネットワークを使用しない Pod の IMDSv2 へのアクセスを無効にすることもできます。詳細については、[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) を参照してください。
1. (オプション) **オプション** ページで、スタックリソースをタグ付けします。[**次へ**] を選択します。
1. [**確認**] ページで情報を確認し、スタックで IAM リソースを作成することを承認して、[**スタックの更新**] を選択します。
**注記**
クラスター内の各ノードの更新には数分かかります。すべてのノードの更新が完了するのを待ってから、次の手順を実行します。
1. クラスターの DNS プロバイダーが `kube-dns` の場合は、`kube-dns` デプロイを 1 レプリカにスケールインします。
```
kubectl scale deployments/kube-dns --replicas=1 -n kube-system
```
1. (オプション) Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) を使用している場合は、デプロイのスケーリングを目的のレプリカ数に戻します。
```
kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
```
1. (オプション) 最新バージョンの [Amazon VPC CNI Plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) を使用していることを確認します。サポートされている最新のインスタンスタイプを利用するには、Amazon VPC CNI Plugin for Kubernetes のバージョンを更新することが必要になる場合があります。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
# AWS Fargate を使用してコンピューティング管理を簡素化する
このトピックでは、Amazon EKS を使用して AWS Fargate で Kubernetes Pod を実行する方法について説明します。Fargate は、[コンテナ](https://aws.amazon.com/what-are-containers)に適切なサイズのコンピューティング能力をオンデマンドで提供するテクノロジーです。Fargate を使用すると、コンテナを実行するために仮想マシンのグループをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、ノードグループをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
Fargate で起動する Pod と、[Fargate プロファイル](fargate-profile.md)での実行方法を制御できます。Fargate プロファイルは Amazon EKS クラスターの一部として定義されています。Amazon EKS は、Kubernetes が提供するアップストリームの拡張可能なモデルを使用して AWS により構築されたコントローラーを使用して、Kubernetes と Fargate を統合します。これらのコントローラーは、Amazon EKS マネージド Kubernetes コントロールプレーンの一部として実行され、ネイティブ Kubernetes Pod を Fargate にスケジューリングします。Fargate コントローラーには、いくつかの変更と検証アドミッションコントローラーに加えて、デフォルトの Kubernetes スケジューラーとともに実行される新しいスケジューラが含まれています。Fargate で実行する条件を満たす Pod を起動すると、クラスターで実行されている Fargate コントローラーは Pod を認識し、更新し、Fargate にスケジューリングします。
このトピックでは、Fargate で実行されている Pod のさまざまなコンポーネントについて説明し、Amazon EKS で Fargate を使用する際の特別な考慮事項を示します。
## AWS Fargate 考慮事項
Amazon EKS での Fargate の使用についての考慮事項を以下に示します。
+ Fargate で実行される各 Pod には、独自のコンピューティング境界があります。基本となるカーネル、CPU リソース、メモリリソース、または Elastic Network Interface を別のPod と共有しません。
+ Network Load Balancer と Application Load Balancer (ALBs) は、IPターゲットでのみ Fargate で使用できます。詳細については、「[ネットワークロードバランサーを作成する](network-load-balancing.md#network-load-balancer)」および「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」を参照してください。
+ Fargate 公開サービスは、ターゲットタイプの IP モードでのみ実行され、ノード IP モードでは実行されません。マネージド型ノードで実行されているサービスと Fargate で実行されているサービスからの接続を確認するためのおすすめの方法は、サービス名を使用して接続することです。
+ Fargate で実行するには、ポッドがスケジューリングされた時点で Fargate プロファイルと一致する必要があります。Fargate プロファイルに一致しない Pod は `Pending` としてスタックする可能性があります。一致する Fargate プロファイルが存在する場合、Fargate に再スケジューリングするために作成した保留中の Pod を削除できます。
+ デーモンセットは Fargate ではサポートされていません。アプリケーションにデーモンが必要な場合は、そのデーモンを Pod のサイドカーコンテナとして実行するように再設定します。
+ 特権を持つコンテナは Fargate ではサポートされていません。
+ Fargate で実行されている Pod は、`HostPort` または `HostNetwork` を Pod マニフェストに指定できません。
+ Fargate Pod の場合、デフォルトの `nofile` および `nproc` のソフトリミットは 1024、ハードリミットは 65535 です。
+ GPU は現在、Fargate では使用できません。
+ Fargate で実行されているポッドは、プライベートサブネットでのみサポートされています (AWS のサービスへの NAT ゲートウェイアクセスができますが、インターネットゲートウェイへの直接ルーティングはできません)。そのため、クラスターの VPC ではプライベートサブネットを使用できるようにする必要があります。アウトバウンドインターネットアクセスのないクラスターについては、「」を参照してください[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)
+ 「[Vertical Pod Autoscaler でポッドリソースを調整する](vertical-pod-autoscaler.md)」を使用して Fargate Pod の CPU とメモリの適切な初期サイズを設定し、「[Horizontal Pod Autoscaler を使用してポッドデプロイをスケールする](horizontal-pod-autoscaler.md)」を使用してそれらの Pod をスケールできます。Vertical Pod Autoscaler で、より大きい CPU とメモリの組み合わせを持つ Fargate に Pod を自動的に再デプロイする場合は、正しい機能を確保するため、Vertical Pod Autoscaler のモードを `Auto` または `Recreate` に設定します。詳細については、GitHub で [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) のドキュメントを参照してください。
+ VPC で DNS 解決と DNS ホスト名を有効にする必要があります。詳細については、「[VPC の DNS サポートを更新する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)」を参照してください。
+ Amazon EKS Fargate は、仮想マシン (VM) 内の各ポッドを分離することで、Kubernetes アプリケーションの多重防御を追加します。この VM 境界は、コンテナエスケープが発生した場合に他のポッドが使用するホストベースのリソースへのアクセスを防ぎます。これは、コンテナ化されたアプリケーションを攻撃し、コンテナ外のリソースにアクセスする一般的な方法です。
Amazon EKS を使用しても、[責任共有モデル](security.md)に基づくお客様の責任は変わりません。クラスターのセキュリティとガバナンスのコントロールの設定について、慎重に検討する必要があります。アプリケーションを分離する最も安全な方法は、常に別のクラスターで実行することです。
+ Fargate プロファイルでは、VPC セカンダリ CIDR ブロックからのサブネットの指定がサポートされています。セカンダリ CIDR ブロックを指定することもできます。サブネットの使用できる IP アドレスの数は限られています。結果的に、クラスター内に作成できる Pod の数も制限されます。Pod に別のサブネットを使用することで、使用可能な IP アドレスの数を増やすことができます。詳細については、「[IPv4 CIDR ブロックの VPC への追加](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize)」を参照してください。
+ Amazon EC2 インスタンスメタデータサービス (IMDS) は、Fargate ノードにデプロイされた Pod では使用できません。IAM 認証情報を必要とする Fargate にデプロイされた Pod がある場合は、[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用して Pod に割り当てます。Pod が IMDS を通じて利用可能な他の情報にアクセスする必要がある場合は、この情報を Pod 仕様にハードコーディングする必要があります。これには、Pod がデプロイされる AWS リージョンまたはアベイラビリティーゾーンが含まれます。
+ AWS Outposts、AWS Wavelength、または AWS Local Zones に Fargate Pod をデプロイすることはできません。
+ Amazon EKS は定期的に Fargate Pod にパッチを適用して安全に保つ必要があります。影響を軽減する方法で更新を試みますが、Pod のエビクションが正常に行われなかった場合、Pod を削除しなければならない場合があります。中断を最小限に抑えるために行えるアクションがいくつかあります。詳細については、「[AWS Fargate OS パッチ適用イベントのアクションを設定する](fargate-pod-patching.md)」を参照してください。
+ [Amazon VPC CNI plugin for Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) は、Fargate ノードにインストールされています。Fargate ノードでは [Amazon EKS クラスターの代替 CNI プラグイン](alternate-cni-plugins.md)を使用することはできません。
+ Fargate 上で実行される Pod は、ドライバーの手動インストールステップなしで、Amazon EFS ファイルシステムを自動的にマウントします。Fargate ノードでは動的永続ボリュームプロビジョニングを使用できませんが、静的プロビジョニングを使用することはできます。
+ Amazon EKS は Fargate Spot をサポートしていません。
+ Amazon EBS ボリュームを Fargate Pod にマウントすることはできません。
+ Amazon EBS CSI コントローラーは Fargate ノードで実行できますが、Amazon EBS CSI ノード DaemonSet は Amazon EC2 インスタンスでのみ実行できます。
+ [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) が `Completed` または `Failed` とマークされた後も、Job が作成した Pod は通常存在し続けます。この動作によりログと結果を表示できますが、Fargate を使用する場合、その後 Job をクリーンアップしないとコストが発生します。
Job が完了または失敗した後に、関連する Pod を自動的に削除するには、有効期限 (TTL) コントローラーを使用して期間を指定できます。次の例では、Job マニフェストで `.spec.ttlSecondsAfterFinished` を指定する方法を示しています。
```
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "sleep 10"]
restartPolicy: Never
ttlSecondsAfterFinished: 60 # <-- TTL controller
```
## Fargate 比較テーブル
| 条件 | AWS Fargate |
| --- | --- |
| [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) にデプロイ可能 | いいえ |
| [AWS Local Zone](local-zones.md) にデプロイ可能 | いいえ |
| Windows を必要とするコンテナを実行できる | いいえ |
| Linux を必要とするコンテナを実行可能 | はい |
| インフェクエンティア チップを必要とするワークロードを実行可能 | いいえ |
| GPU を必要とするワークロードを実行可能 | いいえ |
| Arm プロセッサを必要とするワークロードを実行可能 | いいえ |
| AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) を実行可能 | いいえ |
| Pod は、カーネルランタイム環境を他の Pod と共有します。 | いいえ: 各 Pod には専用のカーネルがあります。 |
| ポッドはCPU、メモリ、ストレージ、およびネットワークリソースを他のポッドと共有します。 | いいえ — 各 Pod には専用のリソースがあり、リソース使用率を最大化するために個別にサイズ設定できます。 |
| Pod 仕様で要求されているよりも多くのハードウェアとメモリを、Pod が使用できます。 | いいえ: より大きな vCPU およびメモリー設定を使用して、Pod を再デプロイできます。 |
| Amazon EC2 インスタンスをデプロイおよび管理する必要がある | いいえ |
| Amazon EC2 インスタンスのオペレーティングシステムの保護、保守、パッチ適用を行う必要がある | いいえ |
| ノードをデプロイする時に、追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数 などのブートストラップ引数を提供できます。 | いいえ |
| ノードに割り当てられた IP アドレスとは異なる CIDR ブロックから、IP アドレスを Pod に割り当てることができます。 | いいえ |
| ノードに SSH 接続可能 | いいえ – SSH 接続を行うノードホストオペレーティングシステムはありません。 |
| 独自のカスタム AMI をノードにデプロイ可能 | いいえ |
| 独自のカスタム CNI をノードにデプロイ可能 | いいえ |
| ノード AMI を自分で更新する必要がある | いいえ |
| ノードの Kubernetes バージョンを自分で更新する必要があります。 | いいえ: ノードを管理しません。 |
| Pod で Amazon EBS ストレージを使用可能 | いいえ |
| Pod で Amazon EFS ストレージを使用可能 | [あり](efs-csi.md) |
| Pod で Amazon FSx for Lustre ストレージを使用可能 | いいえ |
| Network Load Balancer をサービスに使用可能 | はい、「[Network Load Balancer を作成する](network-load-balancing.md#network-load-balancer)」を使用する場合 |
| ポッドはパブリックサブネットで実行可能 | いいえ |
| それぞれの Pod に、異なる VPC セキュリティグループを割り当て可能 | はい |
| Kubernetes DaemonSets を実行可能 | いいえ |
| Pod マニフェストで `HostPort` および `HostNetwork` をサポートします | いいえ |
| AWS が利用可能なリージョン | [一部の Amazon EKS 対応リージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html) |
| Amazon EC2 専有ホストでコンテナを実行できます | いいえ |
| 料金 | 個々のFargate メモリとCPU構成のコスト。各 Pod には、独自のコストがあります。詳細については、「[AWS Fargate の料金](https://aws.amazon.com/fargate/pricing/)」を参照してください。 |
# クラスターの AWS Fargate の使用を開始する
このトピックでは、Amazon EKS クラスターを使用して AWS Fargate で Pod の実行を開始する方法について説明します。
CIDR ブロックを使用してクラスターのパブリックエンドポイントへのアクセスを制限する場合は、プライベートエンドポイントアクセスも有効にすることをお勧めします。こうすることで、Fargate Pod がクラスターと通信できるようになります。プライベートエンドポイントが有効になっていない場合、パブリックアクセスに指定する CIDR ブロックに、VPC からのアウトバウンドソースを含める必要があります。詳細については、「[クラスター API サーバーエンドポイント](cluster-endpoint.md)」を参照してください。
**前提条件**
既存のクラスター。既存の Amazon EKS クラスターがなければ、[Amazon EKS の使用を開始する](getting-started.md) を参照してください。
## ステップ 1: 既存のノードが Fargate Pod と通信できることを確認する
ノードのない新しいクラスター、またはマネージド型ノードグループ ([マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md) を参照) のみを持つクラスターを使用している場合は、「[ステップ 2: Fargate Pod 実行ロールを作成する](#fargate-sg-pod-execution-role)」に進みます。
既にそれに関連付けられているノードがある既存のクラスターで作業していると仮定します。これらのノードの Pod が Fargate で実行されている Pod と自由に通信できることを確認する必要があります。Fargate で実行されている Pod は、関連付けられているクラスターのクラスターセキュリティグループを使用するように自動的に設定されます。クラスター内の既存のノードが、クラスターセキュリティグループとの間でトラフィックを送受信できることを確認します。マネージドノードグループもクラスターセキュリティグループを使用するように自動的に設定されるため、この互換性を変更または確認する必要はありません (「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照)。
`eksctl` または Amazon EKS マネージド型 AWS CloudFormation テンプレートで作成された既存のノードグループの場合、クラスターセキュリティグループをノードに手動で追加できます。または、ノードグループの Auto Scaling グループ起動テンプレートを変更して、クラスターセキュリティグループをインスタンスにアタッチすることもできます。詳細については、Amazon VPC ユーザーガイドの[インスタンスのセキュリティグループを変更する](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership)を参照してください。
AWS マネジメントコンソール で、クラスターの **[Networking]** (ネットワーク) セクションでクラスターのクラスターセキュリティグループを確認できます。これを行うには、次の AWS CLI コマンドを実行します。このコマンドを使用する場合は、`` を自分のクラスター名に置き換えます。
```
aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
## ステップ 2: Fargate Pod 実行ロールを作成する
クラスターが AWS Fargate で Pod を作成する場合、Fargate インフラストラクチャで実行されるコンポーネントは、ユーザーに代わって AWS API を呼び出す必要があります。Amazon EKS の Pod 実行ロールにより、これらを行うための IAM アクセス許可が付与されます。AWS Fargate Pod 実行ロールを作成するには、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
**注記**
`--fargate` オプションを使用して `eksctl` でクラスターを作成した場合は、クラスターに Pod 実行ロールが既にあり、これは `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL` というパターンで IAM コンソールに表示されます。同様に、`eksctl` を使用して Fargate プロファイルを作成する場合、`eksctl` では Pod 実行ロールを作成します (まだ存在しない場合)。
## ステップ 3: クラスターの Fargate プロファイルを作成する
クラスターの Fargate で実行されている Pod をスケジューリングする前に、起動時に Fargate を使用する Pod を指定する Fargate プロファイルを定義する必要があります。詳細については、「[起動時にどの Pod が AWS Fargate を使用するのかを定義する](fargate-profile.md)」を参照してください。
**注記**
`--fargate` オプションを使用して `eksctl` でクラスターを作成した場合、クラスターの Fargate プロファイルは、`kube-system` と `default` の名前空間のすべての Pod のセレクターを使用して既に作成されています。Fargate で使用するその他の名前空間の Fargate プロファイルを作成するには、以下の手順に従います。
Fargate プロファイルを作成するには、次のツールのいずれかを使用します。
+ [`eksctl`](#eksctl_fargate_profile_create)
+ [AWS マネジメントコンソール](#console_fargate_profile_create)
### `eksctl`
この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。
```
eksctl version
```
`eksctl` のインストールまたはアップグレードの手順については、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
** で、Fargate プロファイルを作成するには`eksctl`**
以下の `eksctl` コマンドで Fargate プロファイルを作成し、すべての `` を自分の値に置き換えます。名前空間を指定する必要があります。ただし、`--labels` オプションは必須ではありません。
```
eksctl create fargateprofile \
--cluster \
--name \
--namespace \
--labels
```
`` および `` ラベルには、特定のワイルドカードを使用できます。詳細については、「[Fargate プロファイルのワイルドカード](fargate-profile.md#fargate-profile-wildcards)」を参照してください。
### AWS マネジメントコンソール
** で、Fargate プロファイルを作成するにはAWS マネジメントコンソール**
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. Fargate プロファイルを作成するクラスターを選択します。
1. **[コンピューティング]** タブを開きます。
1. **[Fargate プロファイル]** で、**[Fargate プロファイルを追加]** を選択します。
1. **[Fargate プロファイルを設定]** ページで、次の操作を行います。
1. **[名前]** に Fargate プロファイルの名前を入力します。名前は一意である必要があります。
1. **[Pod 実行ロール]** で、Fargate プロファイルで使用する Pod 実行ロールを選択します。`eks-fargate-pods.amazonaws.com` サービスプリンシパルを持つ IAM ロールのみが表示されます。ここにロールが表示されない場合は、ロールを作成する必要があります。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
1. 選択した **[サブネット]** を必要に応じて変更します。
**注記**
Fargate で実行される Pod では、プライベートサブネットのみがサポートされます。
1. **[Tags]** (タグ) では、オプションで Fargate プロファイルにタグを付けることができます。これらのタグは、Pod など、プロファイルに関連付けられた他のリソースには伝達されません。
1. [**次へ**] を選択します。
1. **[Pod の選択を設定]** ページで、次の操作を行います。
1. **[名前空間]** に、Pod と照合する名前空間を入力します。
+ `kube-system` または `default` など、特定の名前空間を使用して照合できます。
+ 特定のワイルドカード (例: `prod-*`) を使用して、複数の名前空間 (例: `prod-deployment` および `prod-test`) と照合することができます。詳細については、「[Fargate プロファイルのワイルドカード](fargate-profile.md#fargate-profile-wildcards)」を参照してください。
1. (オプション) セレクタに Kubernetes ラベルを追加します。特に、指定された名前空間内の Pod が一致する必要があるものにそれらを追加します。
+ ラベル `infrastructure: fargate` をセレクターに追加して、`infrastructure: fargate` Kubernetes ラベルも持つ指定された名前空間の Pod のみがセレクターと一致するようにすることができます。
+ 特定のワイルドカード (例: `key?: value?`) を使用して、複数の名前空間 (例: `keya: valuea` および `keyb: valueb`) と照合することができます。詳細については、「[Fargate プロファイルのワイルドカード](fargate-profile.md#fargate-profile-wildcards)」を参照してください。
1. **[Next]** (次へ) を選択します。
1. **[確認と作成]** ページで、Fargate プロファイルの情報を確認し、**[作成]** を選択します。
## ステップ 4: CoreDNS を更新する
デフォルトでは、CoreDNS は Amazon EKS クラスターの Amazon EC2 インフラストラクチャで実行するように設定されています。クラスター内で Fargate で*のみ* Pod を実行する場合は、次の手順を実行します。
**注記**
`--fargate` オプションを使用して `eksctl` でクラスターを作成した場合は、[次のステップ](#fargate-gs-next-steps) にスキップできます。
1. 次のコマンドを使用して、CoreDNS の Fargate プロファイルを作成します。`` をクラスター名、`<111122223333>` をアカウント ID、`` をポッド実行ロール名に置き換え、また、`<000000000000000a>`、`<000000000000000b>`、`<000000000000000c>` をプライベートサブネットの ID に置き換えます。Pod 実行ロールがない場合は、最初に作成する必要があります (「[ステップ 2: Fargate Pod 実行ロールを作成する](#fargate-sg-pod-execution-role)」を参照)。
**重要**
ロール ARN に `/` 以外の[パス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names)を含めることはできません。例えば、ロールの名前が `development/apps/AmazonEKSFargatePodExecutionRole` の場合、ロールの ARN を指定するときに `AmazonEKSFargatePodExecutionRole` に変更する必要があります。ロール ARN の形式は ` arn:aws:iam::<111122223333>:role/` であることが必要です。
```
aws eks create-fargate-profile \
--fargate-profile-name coredns \
--cluster-name \
--pod-execution-role-arn arn:aws:iam::<111122223333>:role/ \
--selectors namespace=kube-system,labels={k8s-app=kube-dns} \
--subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c>
```
1. `coredns` デプロイのロールアウトをトリガーします。
```
kubectl rollout restart -n kube-system deployment coredns
```
## 次のステップ
+ 以下のワークフローを使用すると、Fargate で実行するために既存のアプリケーションの移行を開始できます。
1. アプリケーションの Kubernetes 名前空間と Kubernetes ラベルに一致する [Fargate プロファイルの作成](fargate-profile.md#create-fargate-profile)。
1. 既存のいずれかの Pod を削除および再作成し、Fargate でスケジューリングされるようにします。`` と `` を変更して、特定のポッドを更新します。
```
kubectl rollout restart -n deployment
```
+ [Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md) をデプロイして、Fargate で実行されている Pod が Ingress オブジェクトを使用できるようにします。
+ [Vertical Pod Autoscaler を使用してポッドリソースを調整する](vertical-pod-autoscaler.md) を使用して Fargate Pod の CPU とメモリの適切な初期サイズを設定し、[Horizontal Pod Autoscaler を使用してポッドデプロイをスケールする](horizontal-pod-autoscaler.md) を使用してそれらの Pod をスケールできます。Vertical Pod Autoscaler で、より上位の CPU とメモリの組み合わせを持つ Fargate に Pod を自動的に再デプロイする場合は、Vertical Pod Autoscaler のモードを `Auto` または `Recreate` に設定します。これは、正しい機能を保証するためです。詳細については、GitHub で [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) のドキュメントを参照してください。
+ [これらの手順](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html)に従って、アプリケーションをモニタリングするための [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel) (ADOT) コレクターをセットアップします。
# 起動時にどの Pod が AWS Fargate を使用するのかを定義する
クラスターの Fargate で Pod をスケジューリングする前に、起動時に Fargate を使用するPod を指定する Fargate プロファイルを少なくとも 1 つ定義する必要があります。
管理者は、Fargate プロファイルを使用してどの Pod が Fargate で実行されるかを宣言できます。これはプロファイルのセレクターを介して行うことができます。1 つのプロファイルに最大 5 つのセレクターを追加できます。各セレクターには名前空間が含まれている必要があります。セレクターにはラベルを含めることもできます。ラベルフィールドは、複数のオプションのキーと値のペアで構成されます。セレクターに一致するポッドは Fargate でスケジュールされます。ポッドは、セレクターで指定された名前空間とラベルを使用して照合されます。名前空間セレクターがラベルなしで定義されている場合、Amazon EKS は、プロファイルを使用して、その名前空間で実行されるすべての Pod を Fargate にスケジュールしようとします。スケジューリングされる Pod が Fargate プロファイル内のいずれかのセレクターと一致する場合、その Pod は Fargate でスケジューリングされます。
Pod が複数の Fargate プロファイルと一致する場合、次の Kubernetes ラベルを Pod 仕様に追加することで、Pod がどのプロファイルを使用するかを指定することができます: `eks.amazonaws.com/fargate-profile: my-fargate-profile`。Pod を Fargate にスケジューリングするには、そのプロファイル内のセレクターと一致する必要があります。Kubernetes アフィニティ/アンチアフィニティルールは適用されないため、Amazon EKS Fargate Pod では必要ありません。
Fargate プロファイルを作成する際は、Pod 実行ロールを指定する必要があります。この実行ロールは、プロファイルを使用して Fargate インフラストラクチャで実行される Amazon EKS コンポーネントのためのものです。承認のためにクラスターの Kubernetes [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) に追加されます。これにより、Fargate インフラストラクチャで実行されている `kubelet` が Amazon EKS クラスターに登録され、クラスター内でノードとして表示されるようになります。Pod 実行ロールは、Amazon ECR イメージリポジトリへの読み取りアクセスを許可するために、Fargate インフラストラクチャへの IAM アクセス許可も提供します。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
Fargate プロファイルは変更できません。ただし、新しい更新されたプロファイルを作成して既存のプロファイルを置き換え、その後元のプロファイルを削除することはできます。
**注記**
Fargate プロファイルを使用して実行中の Pod は、プロファイルが削除されると停止され、保留状態になります。
クラスターのいずれかの Fargate プロファイルが `DELETING` ステータスである場合は、Fargate プロファイルの削除が完了するのを待ってから、そのクラスターに他のプロファイルを作成する必要があります。
**注記**
Fargate は現在 Kubernetes [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) をサポートしていません。
Amazon EKS と Fargate は、Fargate プロファイルで定義されている各サブネットに Pod を分散させます。ただし、分散が偏ってしまう場合があります。均等な分散が必要な場合は、2 つの Fargate プロファイルを使用してください。2 つのレプリカをデプロイし、ダウンタイムを発生させたくないシナリオでは、均等な分散が重要になります。各プロファイルにはサブネットを 1 つだけ含めることをお勧めします。
## Fargate プロファイルのコンポーネント
Fargate プロファイルには、次のコンポーネントが含まれています。
**ポッド実行ロール**
クラスターが AWS Fargate で Pod を作成するとき、Fargate インフラストラクチャ上で実行されている `kubelet` は、ユーザーに代わって AWS API を呼び出す必要があります。例えば、Amazon ECR からコンテナイメージを取得するためのコールを行う必要があります。Amazon EKS の Pod 実行ロールにより、これらを行うための IAM アクセス許可が付与されます。
Fargate プロファイルを作成する際は、Pod で使用する Pod 実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) に追加されます。これにより、Fargate インフラストラクチャで実行されている `kubelet` が Amazon EKS クラスターに登録され、クラスター内でノードとして表示されるようになります。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
**サブネット**
このプロファイルを使用する Pod を起動するサブネットの ID。現時点では、Fargate で実行されている Pod にはパブリック IP アドレスが割り当てられていません。したがって、このパラメータには、プライベートサブネット (インターネットゲートウェイへの直接ルートなし) のみが受け入れられます。
**セレクター**
この Fargate プロファイルを使用するために Pod に一致するセレクター。1 つの Fargate プロファイルに最大 5 つのセレクターを指定できます。セレクターには次のコンポーネントがあります:
+ **名前空間** – セレクターの名前空間を指定する必要があります。セレクターはこの名前空間で作成された Pod のみを照合します。ただし、複数のセレクターを作成して複数の名前空間をターゲットにすることはできます。
+ **ラベル** – オプションで、セレクターに一致する Kubernetes ラベルを指定できます。セレクターは、セレクターで指定されているすべてのラベルを持つ Pod のみに一致します。
## Fargate プロファイルのワイルドカード
名前空間、ラベルキー、およびラベル値のセレクター基準では、Kubernetes で許可されている文字に加えて、`*` および `?` の使用が許可されています。
+ `*` は、文字なし、1 文字、または複数の文字を表します。例: `prod*` は `prod` および `prod-metrics` を表します。
+ `?` は 1 文字を表します (例: `value?` は `valuea` を表します)。しかし、`value` および `value-a` を表すことはできません。`?` は厳密に 1 文字だけを表すためです。
これらのワイルドカード文字は、任意の位置や組み合わせで使用できます (例: `prod*`、`*dev`、および `frontend*?`)。正規表現など、他のワイルドカードやパターンマッチング形式はサポートされていません。
Pod 仕様内の名前空間とラベルに一致するプロファイルが複数ある場合、Fargate はプロファイル名による英数字ソートに基づいてプロファイルを選択します。例えば、(`beta-workload` という名前の) プロファイル A と (`prod-workload` という名前の) プロファイル B の両方に、起動する Pod に一致するセレクターがある場合、Fargate は Pod にプロファイル A (`beta-workload`) を選択します。Pod には、プロファイル A のラベルが付いています (例: `eks.amazonaws.com/fargate-profile=beta-workload`)。
ワイルドカードを使用する新しいプロファイルに既存の Fargate Pod を移行するには、次の 2 つの方法があります。
+ 一致するセレクターを持つ新しいプロファイルを作成し、古いプロファイルを削除します。古いプロファイルでラベル付けされたポッドは、一致する新しいプロファイルに再スケジュールされます。
+ ワークロードを移行したいものの、各 Fargate Pod にどの Fargate ラベルが付いているかわからない場合は、次の方法を使用できます。新しいプロファイルを作成し、同じクラスター上のプロファイルの中でアルファベット順で最初に並べられる名前を付けます。次に、新しいプロファイルに移行する必要がある Fargate Pod をリサイクルします。
## Fargate プロファイルの作成
このセクションでは、Fargate プロファイルを作成する方法について説明します。また、Fargate プロファイルに使用する Pod 実行ロールを作成しておく必要があります。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。Fargate で実行されている Pod は、プライベートサブネットでのみサポートされています (AWS サービスへの [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)アクセスはできますが、インターネットゲートウェイへの直接ルーティングはできません)。これは、クラスターの VPC がプライベートサブネットを使用できるようにするためです。
プロファイルは以下を使用して作成できます。
+ [`eksctl`](#eksctl_create_a_fargate_profile)
+ [AWS マネジメントコンソール](#console_create_a_fargate_profile)
## `eksctl`
**`eksctl` で、Fargate プロファイルを作成するには**
以下の `eksctl` コマンドで Fargate プロファイルを作成し、すべてのサンプル値を自分の値に置き換えます。名前空間を指定する必要があります。ただし、`--labels` オプションは必須ではありません。
```
eksctl create fargateprofile \
--cluster my-cluster \
--name my-fargate-profile \
--namespace my-kubernetes-namespace \
--labels key=value
```
`my-kubernetes-namespace` および `key=value` ラベルには、特定のワイルドカードを使用できます。詳細については、「[Fargate プロファイルのワイルドカード](#fargate-profile-wildcards)」を参照してください。
## AWS マネジメントコンソール
**AWS マネジメントコンソール で、Fargate プロファイルを作成するには**
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. Fargate プロファイルを作成するクラスターを選択します。
1. **[コンピューティング]** タブを開きます。
1. **[Fargate プロファイル]** で、**[Fargate プロファイルを追加]** を選択します。
1. **[Fargate プロファイルを設定]** ページで、次の操作を行います。
1. **[名前]** に、Fargate プロファイルの一意の名前 (`my-profile` など) を入力します。
1. **[Pod 実行ロール]** で、Fargate プロファイルで使用する Pod 実行ロールを選択します。`eks-fargate-pods.amazonaws.com` サービスプリンシパルを持つ IAM ロールのみが表示されます。ここにロールが表示されない場合は、ロールを作成する必要があります。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
1. 選択した **[サブネット]** を必要に応じて変更します。
**注記**
Fargate で実行される Pod では、プライベートサブネットのみがサポートされます。
1. **[Tags]** (タグ) では、オプションで Fargate プロファイルにタグを付けることができます。これらのタグは、Pod など、プロファイルに関連付けられた他のリソースには伝達されません。
1. [**Next**] を選択します。
1. **[Pod の選択を設定]** ページで、次の操作を行います。
1. **[名前空間]** に、Pod と照合する名前空間を入力します。
+ `kube-system` または `default` など、特定の名前空間を使用して照合できます。
+ 特定のワイルドカード (例: `prod-*`) を使用して、複数の名前空間 (例: `prod-deployment` および `prod-test`) と照合することができます。詳細については、「[Fargate プロファイルのワイルドカード](#fargate-profile-wildcards)」を参照してください。
1. (オプション) セレクタに Kubernetes ラベルを追加します。特に、指定された名前空間内の Pod が一致する必要があるものにそれらを追加します。
+ ラベル `infrastructure: fargate` をセレクターに追加して、`infrastructure: fargate` Kubernetes ラベルも持つ指定された名前空間の Pod のみがセレクターと一致するようにすることができます。
+ 特定のワイルドカード (例: `key?: value?`) を使用して、複数の名前空間 (例: `keya: valuea` および `keyb: valueb`) と照合することができます。詳細については、「[Fargate プロファイルのワイルドカード](#fargate-profile-wildcards)」を参照してください。
1. [**Next**] を選択します。
1. **[確認と作成]** ページで、Fargate プロファイルの情報を確認し、**[作成]** を選択します。
# Fargate プロファイルを削除する
このトピックでは、Fargate プロファイルを削除する方法について説明します。Fargate プロファイルを削除すると、そのプロファイルで Fargate にスケジューリングされていた Pod はすべて削除されます。これらの Pod が別の Fargate プロファイルと一致する場合、それらの Pod はそのプロファイルで Fargate にスケジューリングされます。Fargate プロファイルがどのプロファイルとも一致しなくなった場合は、Fargate へのスケジューリングは行われず、保留中のままになる可能性があります。
一度にクラスター内の 1 つの Fargate プロファイルのみが、`DELETING` ステータスになることができます。そのクラスター内の他のプロファイルを削除する前に、Fargate プロファイルの削除が完了するまでお待ちください。
プロファイルは、次のいずれかのツールを使用して削除できます。
+ [`eksctl`](#eksctl_delete_a_fargate_profile)
+ [AWS マネジメントコンソール](#console_delete_a_fargate_profile)
+ [AWS CLI](#awscli_delete_a_fargate_profile)
## `eksctl`
**`eksctl` で、Fargate プロファイルを削除する**
クラスターからプロファイルを削除するには、次のコマンドを使用します。各*サンプル値*は独自の値に置き換えます。
```
eksctl delete fargateprofile --name my-profile --cluster my-cluster
```
## AWS マネジメントコンソール
**AWS マネジメントコンソール で、Fargate プロファイルを削除する**
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。クラスターの一覧で Fargate プロファイルを削除するクラスターを選択します。
1. **[コンピューティング]** タブを開きます。
1. 削除する Fargate プロファイルを選択し、**[削除]** を選択します。
1. **[Fargate プロファイルの削除]** ページで、プロファイルの名前を入力し、**[削除]** を選択します。
## AWS CLI
**AWS CLI で、Fargate プロファイルを削除する**
クラスターからプロファイルを削除するには、次のコマンドを使用します。各*サンプル値*は独自の値に置き換えます。
```
aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster
```
# Fargate Pod 設定の詳細を理解する
このセクションでは、AWS Fargate で Kubernetes Pod を実行するための固有の Pod 設定の詳細について説明します。
## ポッド CPU とメモリ
Kubernetes では、Pod 内の各コンテナに割り当てられるリクエスト、最小量の vCPU およびメモリリソースを定義できます。Pod は Kubernetes によってスケジュールされ、少なくとも各 Pod に対してリクエストされたリソースがコンピューティングリソース上で利用可能になるようにします。詳細については、Kubernetes のドキュメントの「[Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)」を参照してください。
**注記**
Amazon EKS Fargate はノードごとに Pod を 1 つだけ実行するため、リソースが少ない場合に Pod を削除するシナリオは発生しません。すべての Amazon EKS Fargate Pod は保証された優先度で実行されるため、リクエストされた CPU とメモリは、すべてのコンテナの制限に等しくする必要があります。詳細については、Kubernetes ドキュメントの「[Configure Quality of Service for Pods (ポッド用にサービスの品質を設定する)](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)」を参照してください。
Pod が Fargate にスケジュールされている場合、Pod 仕様内の vCPU とメモリの予約によって、Pod にプロビジョニングする CPU とメモリの量が決まります。
+ Init コンテナからの最大リクエストは、Init リクエスト vCPU およびメモリ要件を決定するために使用されます。
+ 実行時間の長いコンテナのリクエストは、実行時間の長いリクエスト vCPU とメモリ要件を決定するために合計されます。
+ 前記の 2 つの値のうち大きい方が、Pod 用に使用する vCPU とメモリリクエストに対して選択されます。
+ Fargate は、必要な Kubernetes コンポーネント (`kubelet`、`kube-proxy`、および `containerd`) の各 Pod のメモリ予約に 256 MB を追加します。
Fargate では、Pod の実行に必要なリソースを常に確保するために、vCPU とメモリのリクエストの合計に最も近い、次に示すコンピューティング設定に切り上げられます。
vCPU とメモリの組み合わせを指定しない場合は、使用可能な最小の組み合わせ (.25 vCPU と 0.5 GB のメモリ) が使用されます。
次の表は、Fargate で実行されている Pod で使用可能な vCPU とメモリの組み合わせを示しています。
| vCPU 値 | メモリの値 |
| --- | --- |
| .25 vCPU | 0.5 GB、1 GB、2 GB |
| .5 vCPU | 1 GB、2 GB、3 GB、4 GB |
| 1 vCPU | 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB |
| 2 vCPU | 4 GB ～ 16 GB (1 GB のインクリメント) |
| 4 vCPU | 8 GB ～ 30 GB (1 GB のインクリメント) |
| 8 vCPU | 16 GB～60 GB (4 GB のインクリメント) |
| 16 vCPU | 32 GB～120 GB (8 GB のインクリメント) |
Kubernetes コンポーネント用に予約されている追加メモリにより、要求よりも多くの vCPU による Fargate タスクがプロビジョニングされる可能性があります。例えば、1 つの vCPU と 8 GB のメモリを要求すると、メモリ要求に 256 MB が追加され、2 つの vCPU と 9 GB のメモリの Fargate タスクがプロビジョニングされます。これは、1 つの vCPU と 9 GB のメモリのタスクがないためです。
Fargate で実行されている Pod のサイズと、Kubernetes が `kubectl get nodes` でレポートするノードサイズに相関はありません。レポートされるノードサイズは、多くの場合 Pod のキャパシティーよりも大きくなります。次のコマンドを使用して、Pod キャパシティーを確認できます。*default* を Pod の名前空間に、*pod-name* を Pod の名前に置き換えます。
```
kubectl describe pod --namespace default pod-name
```
出力例は次のとおりです。
```
[...]
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
[...]
```
`CapacityProvisioned` アノテーションは、実際の Pod キャパシティーを表し、これで Fargate で実行されている Pod のコストが決まります。コンピューティング設定の料金情報については、「[AWS Fargate の料金](https://aws.amazon.com/fargate/pricing/)」を参照してください。
## Fargate ストレージ
Fargate 上で実行される Pod は、ドライバーの手動インストールステップなしで、Amazon EFS ファイルシステムを自動的にマウントします。Fargate ノードでは動的永続ボリュームプロビジョニングを使用できませんが、静的プロビジョニングを使用することはできます。詳細については、GitHub の「[Amazon EFS CSI ドライバー](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md)」を参照してください。
プロビジョニングすると、Fargate で実行されている各 Pod に対して、デフォルトで 20 GiB のエフェメラルストレージが割り当てられます。このタイプのストレージは、Pod の停止後に削除されます。Fargate に起動される新しい Pod では、エフェメラルストレージボリュームの暗号化がデフォルトで有効になっています。エフェメラル Pod ストレージは、AWS Fargate で管理されるキーを使用して AES-256 暗号化アルゴリズムで暗号化されます。
**注記**
Fargate で実行される Amazon EKS Pod のデフォルトで使用可能なストレージは、20 GiB 未満です。これは、一部のスペースが `kubelet` と Pod 内に読み込まれるその他の Kubernetes モジュールによって使用されるためです。
エフェメラルストレージの総量は、最大 175 GiB まで増やすことができます。Kubernetes でサイズを設定するには、Pod 内の各コンテナに対して、`ephemeral-storage` リソースのリクエストを指定します。Kubernetes が Pod をスケジュールすると、各 Pod に対するリソースリクエストの合計が Fargate タスクの容量を下回ることが保証されます。詳細については、Kubernetes ドキュメントの「[Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)」を参照してください。
Amazon EKS Fargate は、システム使用目的でリクエストされた数よりも大きなエフェメラルストレージをプロビジョニングします。たとえば、100 GiB のリクエストでは、115 GiB のエフェメラルストレージの Fargate タスクがプロビジョニングされます。
# AWS Fargate OS パッチ適用イベントのアクションを設定する
Amazon EKS は定期的に AWS Fargate ノードの OS にパッチを適用し、ノードを安全に保ちます。パッチ適用プロセスの一環として、ノードをリサイクルして OS パッチをインストールします。更新は、サービスへの影響を最小限に抑える方法で試行されます。ただし、Pod のエビクションが正常に行われない場合は、Pod を削除する必要がある場合があります。以下に示しているのは、中断の可能性を最小限に抑えるために実行できるアクションです。
+ 適切な Pod の中断予算 (PDB) を設定して、同時にダウンする Pod の数を制御します。
+ Pod が削除される前に、失敗したエビクションに対応する Amazon EventBridge ルールを作成します。
+ 受信した通知に記載されているエビクション日よりも前に、影響を受けるポッドを手動で再起動します。
+ AWS User Notifications で通知設定を作成します。
Amazon EKS は、Kubernetes コミュニティと緊密に協力して、できるだけ早く、バグ修正とセキュリティパッチが入手可能になるようにしています。すべての Fargate Pod は最新の Kubernetes パッチバージョンで起動されます。このバージョンは、Amazon EKS からクラスターの Kubernetes バージョンとして入手できます。以前のパッチバージョンの Pod をお持ちの場合、Amazon EKS はそれをリサイクルして最新バージョンに更新することがあります。これにより、Pod に最新のセキュリティアップデートが確実に装備されます。そのため、クリティカルな[共通脆弱性識別子](https://cve.mitre.org/) (CVE) 問題があっても、最新の状態に保たれてセキュリティリスクが軽減されています。
AWS Fargate OS が更新されると、Amazon EKS は影響を受けるリソースと今後のポッドのエビクション日を含む通知を送信します。指定されたエビクション日が不都合な場合は、通知に記載されたエビクション日よりも前に、影響を受けるポッドを手動で再起動するオプションを利用できます。通知を受け取る前に作成されたポッドは、エビクションの対象となります。ポッドを手動で再起動する方法の詳細については、[Kubernetes ドキュメント](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart)を参照してください。
Pod がリサイクルされるときに一度にダウンする Pod の数を制限するために、Pod の中断予算 (PDB) を設定できます。PDB を使用して、更新の実行を許可しながら、各アプリケーションの要件に基づいて最小限使用可能なポッドを定義できます。PDB の最小可用性は 100% 未満である必要があります。詳細については、Kubernetes ドキュメントの「[アプリケーションに Disruption Budget 指定する](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)」を参照してください。
Amazon EKS は [Eviction API](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) を使用して、アプリケーションに設定した PDB を尊重しながら Pod を安全に排出します。ポッドのエビクションは、影響を最小限に抑えるために、アベイラビリティーゾーンごとに行われます。エビクションが成功すると、新しい Pod には最新のパッチが適用され、それ以上のアクションは必要ありません。
Pod のエビクションが失敗すると、Amazon EKS はエビクションに失敗した Pod の詳細を含むイベントをアカウントに送信します。スケジュールされた終了時刻より前にメッセージに対応できます。具体的な時刻は、パッチの緊急性によって異なります。その時刻になると、Amazon EKS は Pod のエビクションを再び試行します。ただし、今回は、エビクションが失敗しても新しいイベントは送信されません。エビクションが再び失敗すると、新しい Pod に最新のパッチが適用できるように、既存の Pod が定期的に削除されます。
Pod のエビクションが失敗したときに受信されるイベントのサンプルを次に示します。これには、クラスター、Pod 名、Pod 名前空間、Fargate プロファイル、およびスケジュールされた終了時刻に関する詳細が含まれます。
```
{
"version": "0",
"id": "12345678-90ab-cdef-0123-4567890abcde",
"detail-type": "EKS Fargate Pod Scheduled Termination",
"source": "aws.eks",
"account": "111122223333",
"time": "2021-06-27T12:52:44Z",
"region": "region-code",
"resources": [
"default/my-database-deployment"
],
"detail": {
"clusterName": "my-cluster",
"fargateProfileName": "my-fargate-profile",
"podName": "my-pod-name",
"podNamespace": "default",
"evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget",
"scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]"
}
}
```
さらに、Pod に複数の PDB が関連付けられていると、エビクション失敗イベントが発生する可能性があります。このイベントは次のエラーメッセージを返します。
```
"evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support",
```
このイベントに基づいて、目的のアクションを作成できます。例えば、Pod の中断予算 (PDB) を調整して、Pod のエビクションの方法を制御できます。具体的には、利用可能な Pod の目標パーセンテージを指定する PDB から始めたとします。アップグレード中に Pod が強制終了される前に、PDB を異なる割合の Pod に調整できます。このイベントを受信するには、クラスターが属する AWS アカウントおよび AWS リージョンで Amazon EventBridge ルールを作成する必要があります。ルールでは、次の**カスタムパターン**を使用する必要があります。EventBridge ルールの作成の詳細については、*Amazon EventBridge ユーザーガイド*の「[イベントに反応する Amazon EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)」を参照してください 。
```
{
"source": ["aws.eks"],
"detail-type": ["EKS Fargate Pod Scheduled Termination"]
}
```
キャプチャするためのイベントに適切なターゲットを設定できます。詳細については、「Amazon EventBridge ユーザーガイド」の「[Amazon EventBridge ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)」を参照してください。AWS User Notifications で通知設定を作成することもできます。AWS マネジメントコンソール を使用して通知を作成する場合は、**[イベントルール]** で、 **[AWS 名]** に **[Elastic Kubernetes Service (EKS)]** を選択し、**[イベントタイプ]** に **[EKS Fargate Pod のスケジュールされた終了時刻]** を選択します。詳細については、「AWS User Notifications ユーザーガイド」の「[AWS User Notifications の開始方法](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html)」を参照してください。
EKS Pod エビクションに関するよくある質問については、*AWS re:Post* の「[よくある質問: Fargate Pod のエビクション通知](https://repost.aws/knowledge-center/fargate-pod-eviction-notice)」を参照してください。
# AWS Fargate アプリケーションと使用状況のメトリクスを収集する
AWS Fargate のシステムメトリクスおよび CloudWatch 使用状況メトリクスを収集できます。
## アプリケーションメトリクス
Amazon EKS や AWS Fargate で動作するアプリケーションには、AWS Distro for OpenTelemetry (ADOT) を使用できます。ADOT では、システムメトリクスを収集し、CloudWatch コンテナインサイトダッシュボードに送信できます。Fargate で実行されているアプリケーションで ADOT の使用を開始するには、「ADOT ドキュメント」の「[Using CloudWatch Container Insights with AWS Distro for OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights)」( Distro for OpenTelemetry を活用した CloudWatch Container Insights の使用) を参照してください。
## 使用状況メトリクス
CloudWatch 使用状況メトリクスを使用して、アカウントのリソースの使用状況を把握できます。これらのメトリクスを使用して、CloudWatch グラフやダッシュボードで現在のサービスの使用状況を可視化できます。
AWS Fargate 使用状況メトリクスは、AWS Service Quotas に対応しています。使用量がサービスクォータに近づいたときに警告するアラームを設定することもできます。Fargate のサービスのクォータの詳細については、「[Amazon EKS と Fargate Service Quotas を表示して管理する](service-quotas.md)」を参照してください。
AWS Fargate は、` AWS/Usage` 名前空間に以下のメトリクスを公開します。
| メトリクス | 説明 |
| --- | --- |
| `ResourceCount` | アカウントで実行されている指定されたリソースの合計数。リソースは、メトリクスに関連付けられたディメンションによって定義されます。 |
次のディメンションは、AWS Fargate によって公開される使用状況メトリクスを絞り込むために使用されます。
| ディメンション | 説明 |
| --- | --- |
| `Service` | リソースを含む AWS のサービスの名前。AWS Fargate 使用状況メトリクスの場合、このディメンションの値は `Fargate` です。 |
| `Type` | 報告されるエンティティのタイプ。現在、AWS Fargate 使用状況メトリクスの有効な値は `Resource` のみです。 |
| `Resource` | 実行中のリソースのタイプ。 現在、AWS Fargate は Fargate のオンデマンド 使用状況に関する情報を返します。Fargate のオンデマンド使用状況のリソース値は `OnDemand` です。 [注意] ==== Fargate のオンデマンド使用状況とは、Fargate を使用した Amazon EKS Pod、Fargate 起動タイプを使用した Amazon ECS タスク、`FARGATE` キャパシティープロバイダーを使用した Amazon ECS タスクを組み合わせたものです。 ==== |
| `Class` | 追跡されているリソースのクラス。現在、AWS Fargate はクラスディメンションを使用していません。 |
### Fargate のリソース使用状況メトリクスをモニタリングするための CloudWatch アラームの作成
AWS Fargate は、Fargate オンデマンドリソース使用状況の AWS Service Quotas に対応する CloudWatch 使用状況メトリクスを提供します。Service Quotas コンソールでは、使用状況をグラフで可視化できます。また、使用量が Service Quotas に近づいたときに警告するアラームも設定できます。詳細については、「[AWS Fargate アプリケーションと使用状況のメトリクスを収集する](#monitoring-fargate-usage)」を参照してください。
以下の手順を使用して、Fargate リソース使用状況メトリクスに基づく CloudWatch アラームを作成します。
1. Service Quotas コンソールを開きますhttps://console.aws.amazon.com/servicequotas/
1. 左のナビゲーションペインで **[AWS サービス**] を選択します。
1. **[AWS サービス**] リストから、**[AWS Fargate]** を探して選択します。
1. **[Service quotas]** (サービスクォータ) リストで、アラームを作成する Fargate 使用量クォータを選択します。
1. Amazon CloudWatch アラームのセクションで **[Create]** (作成) を選択します。
1. [**アラームのしきい値**] で、適用されたクォータ値からアラーム値として設定する値の割合を選択します。
1. [**アラーム名**] にアラームの名前を入力し、[**Create (作成)**] を選択します。
# クラスターの AWS Fargate ログ記録を開始する
Fargate の Amazon EKS では、Fluent Bit をベースにした組み込みのログルーターが利用できます。Fluent Bit コンテナをサイドカーとして明示的に実行する必要はなく、この実行は Amazon によって行われます。必要となるのは、ログルーターの設定だけです。設定は専用の `ConfigMap` を介して行い、その際は以下の基準を満たす必要があります。
+ 名前のついた `aws-logging`
+ `aws-observability` と呼ばれる専用の名前空間での作成
+ 5,300 文字以内にしてください。
`ConfigMap` を作成すると、Fargate の Amazon EKS は自動的にそれを検出しログルーターの設定を行います。Fargate は、Fluent Bit の AWS のバージョンを使用しています。これは、AWS によって管理される Fluent Bit の上流対応のディストリビューションです。詳細については、GitHub の「[AWS for Fluent Bit](https://github.com/aws/aws-for-fluent-bit)」を参照してください。
ログルーターを使用すると、AWS のさまざまなサービスをログの分析と保管に使用できます。Fargate からは、Amazon CloudWatch、Amazon OpenSearch Service に対し直接ログをストリーミングできます。また、[Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) 経由で [Amazon S3](https://aws.amazon.com/s3/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)、およびパートナーツールなどの送信先にログをストリーミングすることも可能です。
+ Fargate Pod をデプロイする既存の Kubernetes 名前空間を指定する既存の Fargate プロファイル。詳細については、「[ステップ 3: クラスターの Fargate プロファイルを作成する](fargate-getting-started.md#fargate-gs-create-profile)」を参照してください。
+ 既存の Fargate Pod 実行ロール。詳細については、「[ステップ 2: Fargate Pod 実行ロールを作成する](fargate-getting-started.md#fargate-sg-pod-execution-role)」を参照してください。
## ログルーターの設定
**重要**
ログを正常に公開するには、そのクラスターが属している VPC からログの送信先までの、ネットワークアクセスが必要になります。これには、ユーザーによる VPC の出力ルールの、カスタマイズが関係します。詳細については、「*Amazon CloudWatch Logs ユーザーガイド*」の「[Using CloudWatch Logs with interface VPC endpoints](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)」を参照してください。
以下のステップでは、すべての*サンプル値*を独自の値に置き換えます。
1. `aws-observability` という名前で、専用の Kubernetes 名前空間を作成します。
1. 次の内容をコンピュータ上の `aws-observability-namespace.yaml` という名前のファイルに保存します。`name` の値は `aws-observability` である必要があり、`aws-observability: enabled` ラベルが必須です。
```
kind: Namespace
apiVersion: v1
metadata:
name: aws-observability
labels:
aws-observability: enabled
```
1. 名前空間を作成します。
```
kubectl apply -f aws-observability-namespace.yaml
```
1. データ値 `Fluent Conf` を使用して `ConfigMap` を作成し、コンテナログを送信先に送ります。Fluent Conf とは Fluent Bit であり、コンテナログを任意のログ送信先にルーティングするために使用される、高速で軽量なログプロセッサ構成言語です。詳細については、Fluent Bit ドキュメントの「[Configuration File](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file)」を参照してください。
**重要**
典型的な `Fluent Conf` に含まれている主なセクションは、`Service``Input`、`Filter` および `Output` です。ただし、Fargate のログルータでは、以下だけを受け入れます。
`Filter` および `Output` セクション。
`Parser` セクション。
他のセクションを提供した場合、拒否されます。
Fargate ログルーターは `Service` および `Input` セクションを管理します。次の `Input` セクションがありますが、これらは変更できず、`ConfigMap` には必要ありません。ただし、メモリバッファー制限やログに適用されるタグなどの洞察は得られます。
```
[INPUT]
Name tail
Buffer_Max_Size 66KB
DB /var/log/flb_kube.db
Mem_Buf_Limit 45MB
Path /var/log/containers/*.log
Read_From_Head On
Refresh_Interval 10
Rotate_Wait 30
Skip_Long_Lines On
Tag kube.*
```
`ConfigMap` の作成時は、以下の (Fargate がフィールドの検証に使用する) ルールを考慮に入れます。
+ `[FILTER]`、`[OUTPUT]`および `[PARSER]` は、それぞれが対応するキーにより指定する必要があります。例: `[FILTER]` が `filters.conf` の下にある必要があります。`filters.conf` には、複数の `[FILTER]` を含められます。また、`[OUTPUT]` および `[PARSER]` セクションは、それぞれと対応するキーの下に置く必要があります。複数の `[OUTPUT]` セクションを指定することで、ログを異なる送信先に同時にルーティングできます。
+ Fargate は各セクションに必要なキーを検証します。`Name` および `match` がそれぞれの `[FILTER]` および `[OUTPUT]` に必要です。`Name` および `format` がそれぞれの `[PARSER]` に必要です。キーの大文字と小文字は区別されません。
+ `${ENV_VAR}` などの環境変数は `ConfigMap` では許可されていません。
+ インデントは、それぞれの `filters.conf`、`output.conf`、および `parsers.conf` の中で、ディレクティブまたはキーと値のペアで同じである必要があります。キーと値のペアは、ディレクティブよりも深いインデントにする必要があります。
+ Fargate は、サポートされている次のフィルターに対して検証します。`grep`、`parser`、`record_modifier`、`rewrite_tag`、`throttle`、`nest`、`modify`、および `kubernetes`。
+ Fargate は、サポートされている次の出力に対して検証します。`es`、`firehose`、`kinesis_firehose`、`cloudwatch`、`cloudwatch_logs`、および `kinesis`。
+ ログ記録を有効にするには、サポートされている `Output` プラグインが少なくとも 1 つ `ConfigMap` にあることが必要です。`Filter` および `Parser` は、ログ記録を有効にするために必要ありません。
また、希望の設定を使用して Amazon EC2 で Fluent Bit を実行し、検証によって発生する問題をトラブルシューティングすることもできます。以下のいずれかの例に従って、`ConfigMap` を作成します。
**重要**
Amazon EKS Fargate のログ記録では、`ConfigMap` での動的設定をサポートしていません。`ConfigMap` に対する任意の変更は、新しい Pod に対してのみ適用されます。既存の Pod には、これらの変更は適用されません。
例を使用して、必要なログ送信先用に `ConfigMap` を作成します。
**注記**
また、Amazon Kinesis Data Streams をログの宛先として使用できます。Kinesis Data Streams を使用する場合は、ポッド実行ロールに `kinesis:PutRecords` 権限が付与されていることを確認してください。詳細については、「*Fluent Bit: 公式マニュアル*」の Amazon Kinesis Data Streams の「[許可](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions)」を参照してください。
**Example**
------
#### [ CloudWatch ]
CloudWatch を使用する場合、次の 2 つの出力オプションがあります。
+ [C で記述された出力プラグイン](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch)
+ [Golang で記述された出力プラグイン](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)
次の例は、`cloudwatch_logs` プラグインを使用して CloudWatch にログを送信する方法を示しています。
1. 次の内容を `aws-logging-cloudwatch-configmap.yaml` という名前のファイルに保存します。*地域コード* を、クラスターのある AWS リージョンに置き換えます。`[OUTPUT]` のパラメータは必須です。
```
kind: ConfigMap
apiVersion: v1
metadata:
name: aws-logging
namespace: aws-observability
data:
flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch.
filters.conf: |
[FILTER]
Name parser
Match *
Key_name log
Parser crio
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
Keep_Log Off
Buffer_Size 0
Kube_Meta_Cache_TTL 300s
output.conf: |
[OUTPUT]
Name cloudwatch_logs
Match kube.*
region region-code
log_group_name my-logs
log_stream_prefix from-fluent-bit-
log_retention_days 60
auto_create_group true
parsers.conf: |
[PARSER]
Name crio
Format Regex
Regex ^(?