EKS 1.32へのアップグレード方法：bootstrap.shからnodeadmへの切り替え

EKSバージョン1.31から1.32への移行は、AmazonのElastic Kubernetes Service上のKubernetesクラスター管理、特にノードのブートストラッププロセスに大きな変化をもたらします。長年使用されてきた従来のbootstrap.shスクリプトは、新しいツールnodeadmに完全に置き換えられます。この変更は単なるツールの切り替えではなく、Amazon Linux 2（AL2）AMIからAmazon Linux 2023（AL2023）およびBottlerocket AMIへの基盤OSの移行に密接に関連しています。さらに、2025年11月26日以降、AmazonはEKS最適化済みAL2 AMIの公開を停止するため、多くのチームにとってこのアップグレードは重要な期限となります。 現在EKS 1.31以前でAL2ベースのノードグループを使用しているクラスターは、アップグレード時に即座に互換性の問題に直面します。AL2023では/etc/eks/bootstrap.shや/etc/eks/eni-max-pods.txtのようなbootstrap.sh関連ファイルが存在しないため、ユーザーデータスクリプトを更新しない限りノードはクラスターに参加できません。つまり、旧方式に依存した自動化やTerraformテンプレートは動作しなくなり、nodeadmの新しい宣言的スタイルに書き換える必要があります。 nodeadmは単なる置き換えではなく、クラスター情報の提供方法を根本的に変えます。bootstrap.shがAmazon EKS DescribeCluster APIを通じてクラスターのメタデータを自動検出していたのに対し、nodeadmはAPIサーバーのエンドポイント、証明書認証局、サービスCIDRなどのパラメータを明示的に入力する必要があります。以前--kubelet-extra-argsで行っていたノード設定のカスタマイズは、YAMLベースのNodeConfigSpecを使う形に変わりました。この変更は大規模展開時のスケーラビリティ向上とAPIスロットリングの軽減を目的としています。 移行を始める前に、どのクラスターが影響を受けるかを特定することが重要です。チームはAWS CLIコマンドでノードグループのAMIタイプを確認し、ユーザーデータスクリプトにbootstrap.shの参照がないかを調べるべきです。将来のAMIとしてAL2023とBottlerocketのどちらを選ぶかも重要な判断です。AL2023はSELinuxのパーミッシブモードやIMDSv2のみの有効化などOSレベルのカスタマイズ性が高い一方、Bottlerocketはコンテナネイティブで最小限の攻撃面設計、自動更新やセキュリティ準拠が標準装備されています。 もう一つの重要な準備作業はkubentやplutoのようなツールで非推奨のKubernetes APIをスキャンすることです。Kubernetesは新バージョンでベータや非推奨APIを削除することが多いため、アップグレード後のワークロード破損を避けるために必要です。バックアップも不可欠で、EKSクラスターはアップグレード後にダウングレードがサポートされないため、etcdスナップショットの取得、Veleroなどでのクラスター設定のバックアップ、nodeadm移行で影響を受けるノード固有設定やIAMロールのドキュメント化を行うべきです。 nodeadmの導入とAL2023イメージへの移行後は、初期のデバッグが予想されます。新しいコンポーネントと変更されたノード初期化フローにより、トラブルシューティング方法は従来と異なります。しかし、ベストプラクティスに従いアーキテクチャの変化を理解すれば、アップグレードはスムーズに進み、将来の改善やスケーラビリティ向上に備えたクラスター構築が可能になります。