**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# 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 の設定ミスなどの予期しない結果につながる可能性があります。