AL2 から AL2023 へのアップグレード高速 Arm Docker から containerd への移行テスト詳細情報

Amazon EKS 最適化 Amazon Linux AMI

Amazon EKS 最適化 Amazon Linux AMI は、Amazon Linux 2 (AL2) および Amazon Linux 2023 (AL2023) 上に構築されています。Amazon EKS ノードのベースイメージとして機能するように構成されています。AMI は、Amazon EKS と連携するように構成されており、次のコンポーネントが含まれています。

kubelet
AWS IAM Authenticator
Docker (Amazon EKS バージョン 1.23 以前)
containerd

注記

AL2 のセキュリティやプライバシーに関するイベントは、Amazon Linux Security Centerで追跡したり、関連する RSS フィードをサブスクライブしたりできます。セキュリティおよびプライバシーイベントには、問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。
高速 AMI または Arm AMI をデプロイする前に、「Amazon EKS 最適化高速 Amazon Linux AMI」および「Amazon EKS 最適化 Arm Amazon Linux AMI」の情報を確認してください。
Kubernetes バージョン 1.23 では、オプションのブートストラップフラグを使用して、Docker から containerd への移行をテストできます。詳細については、「Docker から containerd への移行テスト」を参照してください。
Kubernetes バージョン 1.25 以降、Amazon EC2 P2 インスタンスを Amazon EKS に最適化された高速 Amazon Linux AMI で使用するには、追加設定が必要です。これらの Kubernetes バージョン 1.25 以降向けの AMI は NVIDIA 525 シリーズまたはそれ以降のドライバーに対応しており、P2 インスタンスとの互換性がありません。NVIDIA 525 シリーズおよびそれ以降のドライバーは P3、P4、P5 インスタンスとの互換性があるため、これらのインスタンスを Kubernetes バージョン 1.25 またはそれ以降の AMI で使用することができます。Amazon EKS クラスターをバージョン 1.25 にアップグレードする前に、P2 インスタンスを P3、P4、P5 インスタンスに移行します。また、NVIDIA 525 シリーズまたはそれ以降と連携するように、アプリケーションを自発的にアップグレードする必要があります。新しい NVIDIA 525 シリーズ以降のドライバーは、2024 年 1 月後半に Kubernetes バージョン 1.23 および 1.24 にバックポートする予定です。
Amazon EKS バージョン 1.30 以降では、新しく作成されたマネージド型ノードグループは、ノードオペレーティングシステムとして自動的に AL2023 を使用するようデフォルトで設定されます。以前は、新しいノードグループはデフォルトで AL2 を使用するよう設定されていました。新しいノードグループを作成するときに AL2 を AMI タイプとして選択すれば、AL2 を引き続き使用できます。
AL2 のサポートは 2025 年 6 月 30 日に終了します。詳細については、「Amazon Linux 2 に関するよくある質問」を参照してください。

AL2 から AL2023 へのアップグレード

Amazon EKS 最適化 AMI は、AL2 および AL2023 をベースとする 2 つのファミリーで使用できます。AL2023 は、クラウドアプリケーションに安全かつ安定した高パフォーマンス環境を提供するように設計された、新しい Linux ベースのオペレーティングシステムです。これは Amazon Web Services の次世代 Amazon Linux であり、サポートされているすべての Amazon EKS バージョンで利用できます (延長サポート中のバージョン 1.23 や 1.24 を含む)。AL2023 をベースとする Amazon EKS 高速 AMI は、後日利用可能になります。高速ワークロードがある場合は、AL2 高速 AMI または Bottlerocket を引き続き使用する必要があります。

AL2023 には、AL2 に比べていくつかの改善点があります。詳細については、「Amazon Linux 2023 ユーザーガイド」の「Comparing AL2 and AL2023」を参照してください。AL2 からいくつかのパッケージが追加、アップグレード、削除されています。アップグレードする前に、AL2023 でアプリケーションをテストすることを強くお勧めします。AL2023 のパッケージに関するすべての変更一覧については、「Amazon Linux 2023 リリースノート」の「Package changes in Amazon Linux 2023」を参照してください。

これらの変更に加えて、以下の点に注意してください。

AL2023 では、YAML 設定スキーマを使用する新しいノード初期化プロセス nodeadm が導入されています。セルフマネージド型ノードグループまたは起動テンプレートを持つ AMI を使用している場合は、新しいノードグループの作成時に追加のクラスターメタデータを明示的に指定する必要があります。最低限必要なパラメータの例を以下に示します。ここで、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 を使用している場合には影響しません。詳細については、「Amazon EKS API リファレンス」の certificateAuthority、サービスの cidr、DescribeCluster を参照してください。
AL2023 では、サポートされているすべての Amazon EKS バージョンで Docker がサポートされているとは限りません。AL2 では、Amazon EKS バージョン 1.24 以降で Docker のサポートは終了し、削除されました。廃止の詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。
AL2023 には Amazon VPC CNI バージョン 1.16.2 以降が必要です。
AL2023 にはデフォルトで IMDSv2 が必要です。IMDSv2 には、セキュリティ体制の改善に役立ついくつかの利点があります。セッション指向の認証方式を使用しており、セッションを開始するためにシンプルな HTTP PUT リクエストでシークレットトークンを作成する必要があります。セッショントークンの有効期間は 1 秒～ 6 時間です。IMDSv1 から IMDSv2 への移行方法の詳細については、「インスタンスメタデータサービスバージョン 2 の使用への移行」および「Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure」を参照してください。IMDSv1 を使用する場合は、インスタンスのメタデータオプションの起動プロパティで設定を手動で上書きすることで使用可能になります。

注記
IMDSv2 の場合、マネージド型ノードグループのデフォルトのホップカウントは 1 に設定されています。つまり、コンテナが IMDS を使用してノードの認証情報にアクセスすることはできません。ノードの認証情報へのコンテナアクセスが必要な場合は、カスタム Amazon EC2 起動テンプレートの HttpPutResponseHopLimit を手動で上書きして 2 に増やすことでアクセスが可能になります。または、IMDSv2 の代わりに Amazon EKS Pod Identity を使用して、認証情報を提供することもできます。
AL2023 は、次世代の統合コントロールグループ階層 (cgroupv2) を備えています。cgroupv2 は、コンテナランタイムを実装するために systemd によって使用されます。AL2023 には、cgroupv1 を使用してシステムを実行できるコードが引き続き含まれていますが、この設定は推奨されません。またサポート対象でもありません。この設定は、今後の Amazon Linux のメジャーリリースで完全に削除される予定です。

既存のマネージド型ノードグループの場合は、起動テンプレートの使用方法に応じて、インプレースアップグレードまたは Blue/Green アップグレードを実行できます。

マネージド型ノードグループでカスタム AMI を使用している場合は、起動テンプレートの AMI ID を入れ替えることで、インプレースアップグレードを実行できます。このアップグレード戦略を実行する前に、まずアプリケーションとユーザーデータが AL2023 に転送されていることを必ず確認してください。
標準の起動テンプレートまたは AMI ID を指定しないカスタム起動テンプレートでマネージド型ノードグループを使用している場合は、Blue/Green 戦略を使用してアップグレードする必要があります。通常、Blue/Green アップグレードはより複雑で、AMI タイプとして AL2023 を指定する完全に新しいノードグループを作成する必要があります。新しいノードグループの設定は、AL2 ノードグループのすべてのカスタムデータが新しい OS と互換性があることを確認して、慎重に行う必要があります。新しいノードグループがアプリケーションでテストおよび検証されると、Pods を古いノードグループから新しいノードグループに移行できます。移行が完了したら、古いノードグループを削除できます。

Karpenter を利用していて、AL2023 を使用する場合は、EC2NodeClass amiFamily フィールドを AL2023 に変更する必要があります。デフォルトでは、Karpenter ではドリフトが有効になっています。つまり、amiFamily フィールドが変更されると、Karpenter はワーカーノードを使用可能な最新の AMI に自動的に更新します。

Amazon EKS 最適化高速 Amazon Linux AMI

注記

AL2023 をベースとする Amazon EKS 高速 AMI は、後日利用可能になります。高速ワークロードがある場合は、AL2 高速 AMI または Bottlerocket を引き続き使用する必要があります。

Amazon EKS 最適化高速 Amazon Linux AMI は、標準的な Amazon EKS 最適化 Amazon Linux AMI 上に構築されています。これは、Amazon EKS ノードのオプションのイメージとして機能し、GPU、Inferentia、Trainium ベースのワークロードをサポートするよう設定されています。

標準の Amazon EKS 最適化 AMI 設定に加えて、高速 AMI には、以下が備わっています。

NVIDIA ドライバー
nvidia-container-runtime (デフォルトのランタイム)
AWS Neuron コンテナランタイム

高速 AMI に含まれる最新のコンポーネント一覧については、GitHub のamazon-eks-ami リリースを参照してください。

注記

Amazon EKS 最適化高速 AMI では、GPU と Inferentia をベースとしたインスタンスタイプのみをサポートします。ノードの AWS CloudFormation テンプレートには、これらのインスタンスタイプを指定するようにしてください。Amazon EKS 最適化高速 AMI を使用することで、NVIDIA のユーザーライセンス契約 (EULA) に同意したものとみなされます。
Amazon EKS 最適化高速 AMI は、以前は、GPU をサポートする Amazon EKS 最適化 AMI と呼ばれていたものです。
これまでのバージョンの Amazon EKS 最適化高速 AMI では、nvidia-docker リポジトリがインストールされていました。このリポジトリは、Amazon EKS AMI バージョン v20200529 以降では包含されなくなります。

GPU ベースのワークロードを有効化するには

次の手順に、Amazon EKS 最適化高速 AMI を使用しながら GPU ベースのインスタンス上でワークロードを実行する方法を示します。その他のオプションについては、以下を参照してください。

Inferentia ベースのワークロードの使用の詳細については、「AWS Inferentia を使用した機械学習推論」を参照してください。
Neuron の使用方法の詳細については、「AWS Neuron Documentation」の「Containers - Kubernetes - Getting Started」。

GPU ノードをクラスターに加えた後、Kubernetes 用 NVIDIA デバイスプラグインをクラスターの DaemonSet として適用する必要があります。次のコマンドを実行する前に、vX.X.X を必要となる NVIDIA/k8s-device-plugin バージョンに置き換えます。
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml
```
ノードに割り当て可能な GPU があることは、次のコマンドで確認できます。
```
kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"
```

Pod をデプロイして、GPU ノードが適切に設定されていることをテストするには

次の内容で、nvidia-smi.yaml という名前のファイルを作成します。tag を必要な nvidia/cuda のタグに置き換えます。このマニフェストは、ノード上で nvidia-smi を実行する NVIDIA CUDA コンテナを起動します。
```
apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: nvidia/cuda:tag
    args:
    - "nvidia-smi"
    resources:
      limits:
        nvidia.com/gpu: 1
```
次のコマンドを使用してマニフェストを適用します。
```
kubectl apply -f nvidia-smi.yaml
```

Pod の実行の終了後、次のコマンドを使用してログを表示します。


kubectl logs nvidia-smi

出力例は次のとおりです。

Mon Aug  6 20:23:31 20XX
+-----------------------------------------------------------------------------+
| NVIDIA-SMI XXX.XX                 Driver Version: XXX.XX                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1C.0 Off |                    0 |
| N/A   46C    P0    47W / 300W |      0MiB / 16160MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Amazon EKS 最適化 Arm Amazon Linux AMI

Arm インスタンスは、ウェブサーバー、コンテナ化されたマイクロサービス、キャッシュフリート、および分散データストアといったスケールアウト型で Arm ベースのアプリケーションにおいて、コストを大幅に削減します。クラスターに Arm ノードを追加する際には、次の考慮事項を確認してください。

考慮事項

クラスターが 2020 年 8 月 17 日より前にデプロイされている場合、クラスターの重要なアドオンマニフェストを 1 回だけアップグレードする必要があります。これは、クラスター内で使用中の各ハードウェアアーキテクチャのイメージを、Kubernetes が正しく取得できるようにするためです。クラスターのアドオン更新の詳細については、「Amazon EKS クラスターに必要な Kubernetes バージョンを更新する」を参照してください。2020 年 8 月 17 日以降にクラスターをデプロイしている場合、ご使用の CoreDNS、kube-proxy、および Amazon VPC CNI plugin for Kubernetes のアドオンは、すでにマルチアーキテクチャに対応済みです。
Arm ノードにデプロイされたアプリケーションは、Arm 用にコンパイルする必要があります。
既存のクラスターでデプロイ済みの DaemonSets がある場合、または Arm ノードをデプロイする新しいクラスターにこれをデプロイする場合は、クラスター内のすべてのハードウェアアーキテクチャで DaemonSet が実行可能であることを確認します。
同じクラスター内で、Arm ノードグループと x86 ノードグループを実行することができます。その場合、Pod をデプロイできるハードウェアアーキテクチャを Kubernetes が認識できるようにするために、マルチアーキテクチャのコンテナイメージを Amazon Elastic Container Registry などのコンテナリポジトリにデプロイした上で、ノードセレクターをマニフェストに追加することも考慮に入れてください。詳細については、Amazon ECR ユーザーガイドのマルチアーキテクチャイメージのプッシュと、ブログ記事 Introducing multi-architecture container images for Amazon ECR を参照してください。

Docker から `containerd` への移行テスト

Amazon EKS は、Kubernetes バージョン 1.24 のリリース以降、Docker のサポートを終了しました。詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。

Kubernetes バージョン 1.23 では、オプションのブートストラップフラグを使用して、Amazon EKS 最適化 AL2 AMI の containerd ランタイムを有効にすることができます。この機能により、バージョン 1.24 以降に更新するときに containerd に移行するための明確なパスが提供されます。Amazon EKS は、Kubernetes バージョン 1.24 のリリース以降、Docker のサポートを終了しました。containerd ランタイムは Kubernetes コミュニティで広く導入されていて、CNCF で段階的に進めているプロジェクトです。これは、新しいクラスターまたは既存のクラスターにノードグループを追加することでテストできます。

ブートストラップフラグを有効にするには、以下のいずれかのタイプでノードグループを作成します。

セルフマネージド型

セルフマネージド型の Amazon Linux ノードの起動の手順に従ってノードグループを作成します。BootstrapArguments パラメータでは、Amazon EKS 最適化 AMI と、以下のテキストを指定します。


--container-runtime containerd

マネージド

eksctl を使用する場合には、次の内容の my-nodegroup.yaml という名前のファイルを作成します。example value をすべて自分の値に置き換えてください。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。ami-1234567890abcdef0 の最適化された AMI ID を取得するには、「Amazon EKS 最適化 Amazon Linux AMI ID の取得」を参照してください。


apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd

注記

多数のノードを同時に起動する場合は、エラーを回避するために、ブートストラップ引数 --apiserver-endpoint、--b64-cluster-ca、および --dns-cluster-ip にも値を指定することをお勧めします。詳細については、「AMI を指定する」を参照してください。

以下のコマンドを実行して、ノードグループを作成します。


eksctl create nodegroup -f my-nodegroup.yaml

異なるツールを使用してマネージド型のノードグループを作成する場合、そのノードグループのデプロイには起動テンプレートを使用する必要があります。起動テンプレート内で Amazon EKS 最適化 AMI ID を指定した上で、その起動テンプレートによりノードグループをデプロイし、次のユーザーデータを設定します。このユーザーデータは、引数を bootstrap.sh ファイルに渡します。ブートストラップファイルの詳細については、GitHub の bootstrap.sh を参照してください。


/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

詳細情報

Amazon EKS 最適化 Amazon Linux AMI の詳細については、以下のセクションを参照してください。

Amazon Linux をマネージド型ノードグループと使用するには、「マネージド型ノードグループ」を参照してください。
セルフマネージド型の Amazon Linux ノードの起動には、「Amazon EKS 最適化 Amazon Linux AMI ID の取得」を参照してください。
バージョンについては、「Amazon EKS 最適化 Amazon Linux AMI のバージョン」を参照してください。
Amazon EKS 最適化 Amazon Linux AMI の最新の ID を取得するには、「Amazon EKS 最適化 Amazon Linux AMI ID の取得」を参照してください。
Amazon EKS 最適化 AMI の構築に使用されているオープンソーススクリプトについては、「Amazon EKS 最適化 Amazon Linux AMI のビルドスクリプト」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Dockershim の廃止

バージョンを表示