Amazon EKS 最適化 Amazon Linux AMI
Amazon EKS 最適化 Linux AMI は Amazon Linux 2 上に構築され、Amazon EKS ノードのベースイメージとして機能するように構成されています。AMI は、Amazon EKS と連携するように構成されており、Docker、kubelet
、および AWS IAM Authenticator が含まれています。
-
Amazon Linux 2 のセキュリティもしくはプライバシーに関するイベントを、Amazon Linux セキュリティセンター
により追跡したり、関連する RSS フィード をサブスクライブしたりが可能です。セキュリティおよびプライバシーイベントには、問題の概要、影響を受けるパッケージ、および問題を修正するためにインスタンスを更新する方法などがあります。 -
高速 AMI または Arm AMI をデプロイする前に、「Amazon EKS 最適化高速 Amazon Linux AMI」および「Amazon EKS 最適化 Arm Amazon Linux AMI」の情報を確認してください。
-
Amazon EKS 最適化 Amazon Linux 2 には、
containerd
ランタイムを有効にするための、オプションのブートストラップフラグが含まれています。Kubernetes v1.21 は、Docker コンテナランタイムをサポートする最後のバージョンになります。この機能により、containerd
に移行するための明確な道筋が示されます。containerd
ランタイムは Kubernetes コミュニティで広く導入されていて、CNCF で卒業レベルに到達したプロジェクトです。これは、新しいクラスターまたは既存のクラスターにノードグループを追加することでテストできます。詳細については、「containerd ランタイムブートストラップフラグを有効にする」を参照してください。Amazon EKS 最適化高速 Amazon Linux v1.21 向け AMI をブートストラップすると、AWS Inferentiaワークロードがサポートされません。
次の表のいずれかのリンクを開くと、AWS リージョン および Kubernetes バージョンに対応する最新の Amazon EKS 最適化 Amazon Linux AMI ID が表示されます。さまざまなツールを使用して、AWS Systems Manager パラメータで ID を取得することもできます。詳細については、「Amazon EKS 最適化 Amazon Linux AMI ID の取得」を参照してください。
これらの AMI には、最新の AWS CloudFormation ノードテンプレートが必要です。前のバージョンのノードテンプレートで、これらの AMI を使用することはできません。使用すると、クラスターへの参加に失敗します。これらの AMI を使用する前に、既存の AWS CloudFormation ノードスタックを最新のテンプレート (以下に示す URL) に更新してください。
https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-10-29/amazon-eks-nodegroup.yaml
AWS CloudFormation ノードテンプレートは、Amazon EC2 ユーザーデータを使用してノードを起動し、このデータにより、専用のブートストラップスクリプト
containerd
ランタイムブートストラップフラグを有効にする
Amazon EKS 最適化 Amazon Linux 2 AMI には、containerd
ランタイムを有効化するための、オプションのブートストラップフラグが含まれています。この機能により、containerd
に移行するための明確な道筋が示されます。Amazon EKS は、Kubernetes バージョン 1.23 のリリース以降、Docker のサポート終了を進めます。詳細については、「Dockershim の廃止」を参照してください。
ブートストラップフラグを有効にするには、以下のいずれかのタイプでノードグループを作成します。
-
セルフマネージド – セルフマネージド型の Amazon Linux ノードの起動 の手順に従い、ノードグループを作成します。BootstrapArguments パラメータでは、Amazon EKS 最適化 AMI と、以下のテキストを指定します。
--container-runtime containerd
-
マネージド –
eksctl
を使用する場合には、次の内容の
という名前のファイルを作成します。my-nodegroup.yaml
をすべて自分の値に置き換えてください。example-value
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name:
my-cluster
region:region-code
managedNodeGroups: - name:my-nodegroup
ami:eks-optimized-AMI-ID
overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.shmy-cluster
--container-runtime containerd以下のコマンドを実行して、ノードグループを作成します。
eksctl create nodegroup -f
my-nodegroup.yaml
--version1.21
異なるツールを使用してマネージド型のノードグループを作成する場合、そのノードグループのデプロイには起動テンプレートを使用する必要があります。起動テンプレート内で Amazon EKS 最適化 AMI ID を指定した上で、その起動テンプレートによりノードグループをデプロイし、次のユーザーデータを設定します。このユーザーデータは、引数を
bootstrap.sh
ファイルに渡します。ブートストラップファイルの詳細については、GitHub の「bootstrap.sh」を参照してください。 /etc/eks/bootstrap.sh
my-cluster
\ --container-runtime containerd
Amazon EKS 最適化高速 Amazon Linux AMI
Amazon EKS 最適化高速 Amazon Linux AMI は、標準的な Amazon EKS 最適化 Amazon Linux AMI 上に構築されています。Amazon EKS ノードが GPU と Inferentia
標準の Amazon EKS 最適化 AMI 設定に加えて、高速 AMI には、以下が備わっています。
-
NVIDIA ドライバー
-
nvidia-container-runtime
(デフォルトのランタイム) -
AWS Neuron コンテナランタイム
-
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 を使用した機械学習推論
-
GPU ノードをクラスターに参加させた後、次のコマンドにより、NVIDIA device plugin for Kubernetes
をクラスターの DaemonSet として適用する必要があります。 kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/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
というファイルを作成します。このマニフェストでは、ノード上でnvidia-smi
を実行する Cuda コンテナ を起動します。apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: restartPolicy: OnFailure containers: - name: nvidia-smi image: nvidia/cuda:9.2-devel args: - "nvidia-smi" resources: limits: nvidia.com/gpu: 1
-
次のコマンドを使用してマニフェストを適用します。
kubectl apply -f nvidia-smi.yaml
-
ポッドの実行が終了後、次のコマンドを使用してログを表示します。
kubectl logs nvidia-smi
出力は次のとおりです。
Mon Aug 6 20:23:31 2018 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 396.26 Driver Version: 396.26 | |-------------------------------+----------------------+----------------------+ | 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 用にコンパイルする必要があります。
-
Arm では、Amazon FSx for Lustre CSI ドライバー をご使用になれません。
-
既存のクラスタでデプロイ済みの DaemonSets がある場合、または新しいクラスタで Arm ノードと共にこれをデプロイする場合は、クラスタ内のすべてのハードウェアアーキテクチャで Daemonset が実行可能であることを確認します。
-
同じクラスタ内で、Arm ノードグループと x86 ノードグループを実行することができます。その場合、Pod をデプロイできるハードウェアアーキテクチャを Kubernetes が認識できるようにするために、マルチアーキテクチャのコンテナイメージを Amazon Elastic Container Registry などのコンテナリポジトリにデプロイした上で、ノードセレクターをマニフェストに追加する作業も考慮に入れてください。詳細については、Amazon ECR ユーザーガイドのマルチアーキテクチャイメージのプッシュと、ブログ記事 Introducing multi-architecture container images for Amazon ECR
を参照してください。