**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# 最適化された Amazon Linux AMI を使用してノードを作成する
Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes ワーカーノードの実行に最適化された専用の Amazon マシンイメージ (AMI) を提供します。これらの EKS に最適化された Amazon Linux (AL) AMI は、クラスター内でのシームレスな統合とセキュリティを確保するために、`kubelet`、AWS IAM Authenticator、`containerd` などの重要なコンポーネントで事前設定されています。このガイドでは、使用可能な AMI バージョンの詳細を示すと共に、高速コンピューティングと Arm ベースのアーキテクチャ向けの専用オプションについて説明します。
## 考慮事項
+ Amazon Linux のセキュリティまたはプライバシーに関するイベントを、[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/)で追跡できます。そのためには目的のバージョンのタブを選択してください。該当する RSS フィードをサブスクライブすることもできます。セキュリティおよびプライバシーイベントには問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。
+ 高速または Arm AMI をデプロイする前に、[Amazon EKS 最適化高速 Amazon Linux AMI](#gpu-ami) および [Amazon EKS 最適化 Arm Amazon Linux AMI](#arm-ami) の情報を確認してください。
+ Amazon EC2 `P2` インスタンスは、`NVIDIA` ドライバーバージョン 470 以前を必要とするため、Amazon EKS ではサポートされていません。
+ バージョン `1.30` 以降のクラスターで新しく作成されたマネージド型ノードグループは、ノードオペレーティングシステムとして自動的に AL2023 を使用するようデフォルトで設定されます。
## Amazon EKS 最適化高速 Amazon Linux AMI
Amazon EKS 最適化高速 Amazon Linux (AL) AMI は、標準的な EKS 最適化 Amazon Linux AMI 上に構築されています。これは、Amazon EKS ノードのオプションのイメージとして機能し、GPU、[Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、[Trainium](https://aws.amazon.com/machine-learning/trainium/) ベースのワークロードをサポートするよう設定されています。
詳細については、「[GPU インスタンス向けに EKS 最適化高速 AMI を使用する](ml-eks-optimized-ami.md)」を参照してください。
## Amazon EKS 最適化 Arm Amazon Linux AMI
Arm インスタンスは、ウェブサーバー、コンテナ化されたマイクロサービス、キャッシュフリート、および分散データストアといったスケールアウト型の Arm ベースアプリケーションにおいて、コストを大幅に削減します。クラスターに Arm ノードを追加する際には、次の考慮事項を確認してください。
+ クラスターが 2020 年 8 月 17 日より前にデプロイされている場合、クラスターの重要なアドオンマニフェストを 1 回だけアップグレードする必要があります。これは、クラスター内で使用中の各ハードウェアアーキテクチャのイメージを、Kubernetes が正しく取得できるようにするためです。クラスターのアドオン更新の詳細については、「[ステップ 1: アップグレードの準備をする](update-cluster.md#update-existing-cluster)」を参照してください。2020 年 8 月 17 日以降にクラスターをデプロイしている場合、ご使用の CoreDNS、`kube-proxy`、および Amazon VPC CNI Plugin for Kubernetes アドオンは、既にマルチアーキテクチャに対応しています。
+ Arm ノードにデプロイされたアプリケーションは、Arm 用にコンパイルする必要があります。
+ 既存のクラスターでデプロイ済みの DaemonSet がある場合、または新しいクラスターで Arm ノードと共にこれをデプロイする場合は、クラスター内のすべてのハードウェアアーキテクチャで DaemonSet が実行可能であることを確認します。
+ 同じクラスタ内で、Arm ノードグループと x86 ノードグループを実行することができます。その場合、Pod をデプロイできるハードウェアアーキテクチャを Kubernetes が認識できるようにするために、マルチアーキテクチャのコンテナイメージを Amazon Elastic Container Registry などのコンテナリポジトリにデプロイした上で、ノードセレクターをマニフェストに追加する作業も考慮に入れてください。詳細については、*Amazon ECR ユーザーガイド*の[マルチアーキテクチャイメージのプッシュ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html)と、ブログ記事 [Introducing multi-architecture container images for Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr) を参照してください。
## 詳細情報
Amazon EKS 最適化 Amazon Linux AMI の詳細については、以下のセクションを参照してください。
+ Amazon Linux をマネージド型ノードグループと使用するには、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。
+ セルフマネージド型の Amazon Linux ノードの起動には、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。
+ バージョンについては、「[Amazon Linux AMI のバージョン情報を取得する](eks-linux-ami-versions.md)」を参照してください。
+ Amazon EKS 最適化 Amazon Linux AMI の最新の ID を取得するには、「[推奨 Amazon Linux AMI ID を取得する](retrieve-ami-id.md)」を参照してください。
+ Amazon EKS 最適化 AMI の構築に使用されているオープンソーススクリプトについては、「[EKS に最適化されたカスタム Amazon Linux AMI の構築](eks-ami-build-scripts.md)」を参照してください。
# Amazon Linux 2 から Amazon Linux 2023 にアップグレードする
**警告**
Amazon EKS は、2025 年 11 月 26 日に、EKS 最適化 Amazon Linux 2 (AL2) AMI の公開を取り止めました。Amazon EKS 用の AL2023 および Bottlerocket ベースの AMI は、バージョン 1.33 以降をはじめサポート対象のすべての Kubernetes で使用できます。
AL2023 は、クラウドアプリケーションに安全かつ安定した高パフォーマンス環境を提供するように設計された、Linux ベースのオペレーティングシステムです。これは Amazon Web Services の次世代 Amazon Linux であり、サポートされているすべての Amazon EKS バージョンで利用できます。
AL2023 には、AL2 に比べていくつかの改善点があります。詳細については、「*Amazon Linux 2023 ユーザーガイド*」の「[AL2 と AL2023 の比較](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)」を参照してください。AL2 からいくつかのパッケージが追加、アップグレード、削除されています。アップグレードする前に、AL2023 でアプリケーションをテストすることを強くお勧めします。AL2023 のパッケージに関するすべての変更の一覧については、「*Amazon Linux 2023 リリースノート*」の「[Amazon Linux 2023 でのパッケージ変更](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html)」を参照してください。
これらの変更に加えて、以下の点に注意してください。
+ 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
```
AL2 では、これらのパラメータからのメタデータは Amazon 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` は、[https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec) を使用して各ノードの `kubelet` にパラメータを適用する形式も変更します。AL2 では、これは `--kubelet-extra-args` パラメータを使用して行われました。これは一般的に、ノードにラベルとテイントを追加するために使用されます。以下の例は、ノードへの `maxPods` と `--node-labels` の適用を示しています。
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ AL2023 には Amazon VPC CNI バージョン `1.16.2` 以降が必要です。
+ AL2023 にはデフォルトで `IMDSv2` が必要です。`IMDSv2` には、セキュリティ体制の改善に役立ついくつかの利点があります。セッション指向の認証方式を使用しており、セッションを開始するためにシンプルな HTTP PUT リクエストでシークレットトークンを作成する必要があります。セッショントークンの有効期間は 1 秒～ 6 時間です。`IMDSv1` から `IMDSv2` への移行方法の詳細については、「[インスタンスメタデータサービスバージョン 2 の使用への移行](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)」および「[Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure)」を参照してください。`IMDSv1` を使用する場合は、インスタンスのメタデータオプションの起動プロパティで設定を手動で上書きすることで使用可能になります。
**注記**
AL2023 を使用する `IMDSv2` の場合、マネージドノードグループのデフォルトのホップ数は異なる場合があります。
起動テンプレートを使用しない場合、デフォルトは `1` に設定されます。つまり、コンテナが IMDS を使用してノードの認証情報にアクセスすることはできません。ノードの認証情報へのコンテナアクセスが必要な場合は、[カスタム Amazon EC2 起動テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html)を使用するとアクセスが可能になります。
起動テンプレートでカスタム AMI を使用する場合、デフォルト `HttpPutResponseHopLimit` は `2` に設定されます。起動テンプレートの `HttpPutResponseHopLimit` を手動で上書きできます。
または、`IMDSv2` の代わりに [Amazon EKS Pod Identity](pod-identities.md) を使用して、認証情報を提供することもできます。
+ AL2023 は、次世代の統合コントロールグループ階層 (`cgroupv2`) を備えています。`cgroupv2` は、コンテナランタイムを実装するために `systemd` によって使用されます。AL2023 には、`cgroupv1` を使用してシステムを実行できるコードが引き続き含まれていますが、この設定は推奨されません。またサポート対象でもありません。この設定は、今後の Amazon Linux のメジャーリリースで完全に削除される予定です。
+ AL2023 をサポートするには、`eksctl` に `eksctl` のバージョン `0.176.0` 以降が必要です。
既存のマネージド型ノードグループの場合は、起動テンプレートの使用方法に応じて、インプレースアップグレードまたは Blue/Green アップグレードを実行できます。
+ マネージド型ノードグループでカスタム AMI を使用している場合は、起動テンプレートの AMI ID を入れ替えることで、インプレースアップグレードを実行できます。このアップグレード戦略を実行する前に、まずアプリケーションとユーザーデータが AL2023 に転送されていることを必ず確認してください。
+ 標準の起動テンプレートまたは AMI ID を指定しないカスタム起動テンプレートでマネージド型ノードグループを使用している場合は、Blue/Green 戦略を使用してアップグレードする必要があります。通常、Blue/Green アップグレードはより複雑で、AMI タイプとして AL2023 を指定する完全に新しいノードグループを作成する必要があります。新しいノードグループの設定は、AL2 ノードグループのすべてのカスタムデータが新しい OS と互換性があることを確認して、慎重に行う必要があります。新しいノードグループがアプリケーションでテストおよび検証されると、Pod を古いノードグループから新しいノードグループに移行できます。移行が完了したら、古いノードグループを削除できます。
Karpenter を利用していて、AL2023 を使用する場合は、`EC2NodeClass` `amiFamily` フィールドを AL2023 に変更する必要があります。デフォルトでは、Karpenter ではドリフトが有効になっています。つまり、`amiFamily` フィールドが変更されると、Karpenter はワーカーノードを使用可能な最新の AMI に自動的に更新します。
## nodeadm に関する追加情報
EKS 最適化 Amazon Linux 2023 AMI を利用する場合、または公式の amazon-eks-ami GitHub リポジトリで提供されている Packer スクリプトを使用してカスタム EKS Amazon Linux 2023 AMI を構築する場合は、EC2 ユーザーデータ内またはカスタム AMI の一部として nodeadm init を明示的に実行しないようにする必要があります。
ユーザーデータで動的 NodeConfig を生成する場合は、その設定を `/etc/eks/nodeadm.d` のドロップイン yaml または json ファイルに書き込むことができます。これらの設定ファイルは、nodeadm init が起動プロセスの後半で自動的に開始されると、マージされてノードに適用されます。例えば、次のようになります。
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
EKS 最適化 Amazon Linux 2023 AMI は、個別の systemd サービスを通じて nodeadm init を 2 つのフェーズで自動的に実行します。nodeadm-config はユーザーデータの実行前に実行され、nodeadm-run は実行後に実行されます。nodeadm-config サービスは、ユーザーデータを実行する前に containerd と kubelet のベースライン設定を確立します。nodeadm-run サービスは、選択したシステムデーモンを実行し、ユーザーデータの実行後に最終的な設定を完了します。こうした自動実行以外にユーザーデータまたはカスタム AMI を介して nodeadm init コマンドが実行されると、実行順序に関する仮定が破られ、ENI の設定ミスなどの予期しない結果につながる可能性があります。
# Amazon Linux AMI のバージョン情報を取得する
Amazon EKS 最適化 Amazon Linux AMI は、Kubernetes バージョンと AMI のリリース日によって次の形式でバージョニングされています。
```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```
各 AMI リリースには、[kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)、Linux カーネル、[containerd](https://containerd.io/) のさまざまなバージョンが含まれます。また高速 AMI には、さまざまなバージョンの NVIDIA ドライバーも含まれます。このバージョンに関する情報は、GitHub の「[Changelog](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md)」で確認できます。
# 推奨 Amazon Linux AMI ID を取得する
ノードをデプロイする際に、事前構築済みの Amazon EKS 最適化 Amazon マシンイメージ (AMI) の ID を指定できます。希望する設定に合った AMI ID を取得するには、AWS Systems Manager Parameter Store API をクエリします。この API を使用すると、Amazon EKS 最適化 AMI ID を手動で検索する必要がなくなります。詳細については、「[GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html)」を参照してください。使用する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)には、Amazon EKS 最適化 AMI メタデータを取得するための `ssm:GetParameter` IAM アクセス許可が必要です。
サブパラメータ `image_id` を指定する次のコマンドを使用することで、推奨される最新の Amazon EKS 最適化 Amazon Linux AMI のイメージ ID を取得できます。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください：
+ `` を [Amazon EKS がサポートする任意のバージョン](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)に置き換えます。
+ *ami-type* は、以下のいずれかのオプションに置き換えます。Amazon EC2 インスタンスタイプの詳細については、「[Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
+ Amazon Linux 2023 (AL2023) `x86` ベースのインスタンスには *amazon-linux-2023/x86\$164/standard* を使用します。
+ [AWS Graviton](https://aws.amazon.com/ec2/graviton/) ベースのインスタンスなどの AL2023 ARM インスタンスには *amazon-linux-2023/arm64/standard* を使用します。
+ 最新の承認済みの AL2023 NVIDIA `x86` ベースのインスタンスには、*amazon-linux-2023/x86\$164/nvidia* を使用します。
+ 最新の承認済みの AL2023 NVIDIA `arm64` ベースのインスタンスには、*amazon-linux-2023/arm64/nvidia* を使用します。
+ 最新の AL2023 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/) インスタンスには、*amazon-linux-2023/x86\$164/neuron* を使用します。
+ `` を、AMI ID を必要とする [Amazon EKS がサポートされている AWS リージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html)で置き換えます。
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami///recommended/image_id \
--region --query "Parameter.Value" --output text
```
プレースホルダーの置換が行われた後のコマンドの例を以下に示します。
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region us-west-2 --query "Parameter.Value" --output text
```
出力例は次のとおりです。
```
ami-1234567890abcdef0
```
# EKS に最適化されたカスタム Amazon Linux AMI の構築
**警告**
Amazon EKS は、2025 年 11 月 26 日に、EKS 最適化 Amazon Linux 2 (AL2) AMI の公開を取り止めました。Amazon EKS 用の AL2023 および Bottlerocket ベースの AMI は、バージョン 1.33 以降をはじめサポート対象のすべての Kubernetes で使用できます。
Amazon EKS では、「[Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami)」リポジトリにオープンソースのビルドスクリプトが用意されており、これらを使用して`kubelet`、ランタイム環境、AWS IAM Authenticator for Kubernetes の設定を確認し、AL ベースの AMI を一から構築できます。
このリポジトリには、ブート時に実行される特殊な [AL2 用 bootstrap スクリプト](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh)と [AL2023 用 nodeadm ツール](https://awslabs.github.io/amazon-eks-ami/nodeadm/)が保存されています。これらのスクリプトによって、インスタンスの証明書データ、コントロールプレーンエンドポイント、クラスター名などを設定します。ここに置かれているものは、Amazon EKS 最適化 AMI のビルド用として最も信頼できるスクリプトと見なされるため、GitHub リポジトリの状態をフォローすることで、AMI への変更をモニタリングできます。
EKS 最適化 AMI をベースとしてカスタム AMI を構築する場合、コンポーネントの互換性が損なわれる可能性があるため、オペレーティングシステムのアップグレード (`dnf upgrade` など) を実行したり、EKS 最適化 AMI に含まれる Kubernetes または GPU パッケージをアップグレードしたりすることは、推奨もサポートもされていません。EKS 最適化 AMI に含まれるオペレーティングシステムまたはパッケージをアップグレードする場合は、本番環境にデプロイする前に、開発環境またはステージング環境で徹底的にテストすることをお勧めします。
GPU インスタンス用のカスタム AMI を構築する場合は、実行するインスタンスタイプの世代およびファミリーごとに、個別のカスタム AMI を構築することをお勧めします。EKS 最適化高速 AMI は、基盤となるインスタンスタイプの世代およびファミリーに基づいて、ランタイム時にドライバーとパッケージを選択的にインストールします。詳細については、[インストール](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh)と[ランタイム](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh)の EKS AMI スクリプトを参照してください。
## 前提条件
+ [AWS CLI をインストールする](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [HashiCorp Packer v1.9.4\$1 をインストールする](https://developer.hashicorp.com/packer/downloads)
+ [GNU Make をインストールする](https://www.gnu.org/software/make/)
## クイックスタート
このクイックスタートでは、AWS アカウントにカスタム AMI を作成するコマンドを示します。AMI のカスタマイズに使用できる設定の詳細については、「[Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/)」ページのテンプレート変数を参照してください。
### 前提条件
必要な [Amazon プラグイン](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon)をインストールします。例えば、次のようになります。
```
packer plugins install github.com/hashicorp/amazon
```
### ステップ 1. 環境をセットアップする
公式の Amazon EKS AMI リポジトリをクローンまたはフォークします。例えば、次のようになります。
```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```
Packer がインストールされていることを確認します。
```
packer --version
```
### ステップ 2. カスタム AMI を作成する
さまざまなカスタム AMI のコマンド例を以下に示します。
**基本的な NVIDIA AL2 AMI**
```
make k8s=1.31 os_distro=al2 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**基本的な NVIDIA AL2023 AMI**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**STIG 準拠 Neuron AL2023 AMI**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=neuron \
enable_fips=true \
source_ami_id=ami-0abcd1234efgh5678 \
kms_key_id=alias/aws-stig
```
これらのコマンドを実行すると、Packer によって次の操作が行われます。\$1 一時的な Amazon EC2 インスタンスを起動します。\$1 Kubernetes コンポーネント、ドライバー、設定をインストールします。\$1 AWS アカウントで AMI を作成します。
正常な出力は次の例のようになります。
```
==> Wait completed after 8 minutes 42 seconds
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```
### ステップ 3. デフォルト値を表示する
デフォルト値と追加オプションを表示するには、次のコマンドを実行します。
```
make help
```