GKE on AWS では、Arm ベースの AWS Graviton プロセッサ用に構築された Arm ワークロードを実行できます。
制限事項
1.24.8-gke.1300 より前のバージョンの Kubernetes を実行している Arm ノードプールは、ノードプールの作成時に taint を自動的に追加し、Arm ワークロードが Arm 以外のノードでスケジューリングされないようにします。バージョン 1.24.8-gke.1300 以降のクラスタの Arm ノードプールでは、この taint が追加されなくなりました。1.24.8-gke.1300 より前のクラスタからアップグレードする場合は、自分で taint を作成するか、アップグレード時にこのことを考慮する必要があります。
GKE on AWS の Arm ノードプールは、Anthos Service Mesh、Config Sync、Policy Controller をサポートしていません。これらのプロダクトは x86 ノードプールで実行する必要があります。
Kubernetes バージョン 1.24 を実行しているクラスタには、Connect Agent を実行するための x86 ノードプールが必要です。クラスタで Kubernetes バージョン 1.25 以降を実行している場合は、x86 ノードプールは必要ありません。
このページでは、Arm ノードプールの作成方法、マルチ アーキテクチャ イメージが Arm ワークロードのデプロイにおすすめの方法である理由、Arm ワークロードをスケジューリングする方法について説明します。
始める前に
Arm ワークロード用のノードプールを作成するには、次のリソースが必要です。
- ノードプールを作成する既存の AWS クラスタ。このクラスタでは、Kubernetes バージョン 1.24 以降を実行する必要があります。
- ノードプール VM の IAM インスタンス プロファイル。
- ノードプール VM が実行されるサブネット。
クラスタで Kubernetes バージョン 1.24 を実行している場合は、Connect Agent を実行する x86 ノードプール。
GKE on AWS でノードプールを作成する方法の詳細については、ノードプールを作成するをご覧ください。
Arm ノードプールを作成する
GKE on AWS は、Canonical Ubuntu arm64 最小ノードイメージと containerd ランタイムで構築されたノードプールをサポートしています。
Arm ノードプールを作成して既存のクラスタに追加するには、次のコマンドを実行します。
gcloud container aws node-pools create NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--instance-type INSTANCE_TYPE \
--root-volume-size ROOT_VOLUME_SIZE \
--iam-instance-profile NODEPOOL_PROFILE \
--node-version NODE_VERSION \
--min-nodes MIN_NODES \
--max-nodes MAX_NODES \
--max-pods-per-node MAX_PODS_PER_NODE \
--location GOOGLE_CLOUD_LOCATION \
--subnet-id NODEPOOL_SUBNET \
--ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
--config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN
次のように置き換えます。
NODE_POOL_NAME: ノードプールに付ける名前CLUSTER_NAME: ノードプールを接続するクラスタの名前INSTANCE_TYPE: 次のいずれかのインスタンス タイプ。m6gm6gdt4gr6gr6gdc6gc6gdc6gnx2gdc7gim4gng5gこれらのインスタンス タイプでは、Arm ベースの AWS Graviton プロセッサを使用します。また、必要なインスタンス サイズを指定する必要があります。たとえば、
m6g.mediumです。完全な一覧については、サポートされている AWS インスタンス タイプをご覧ください。
ROOT_VOLUME_SIZE: 各ノードのルート ボリュームに必要なサイズ（GB）NODEPOOL_PROFILE: ノードプール VM の IAM インスタンス プロファイルNODE_VERSION: ノードプールの各ノードにインストールする Kubernetes のバージョン。バージョン 1.24 以降である必要があります。たとえば、1.24.3-gke.200です。MIN_NODES: ノードプールに含めることができるノードの最小数。MAX_NODES: ノードプールに含めることができるノードの最大数。MAX_PODS_PER_NODE: プール内の任意の 1 つのノードで作成できる Pod の最大数GOOGLE_CLOUD_LOCATION: Google Cloud の名前このノードプールが管理されるロケーション
NODEPOOL_SUBNET: ノードプールが実行されるサブネットの ID。このサブネットが VPC のプライマリ CIDR ブロックの外部にある場合は、追加の手順が必要です。詳細については、セキュリティ グループをご覧ください。SSH_KEY_PAIR_NAME: SSH アクセス用に作成された AWS SSH 鍵ペアの名前（省略可）CONFIG_KMS_KEY_ARN: ユーザーデータを暗号化する AWS KMS 鍵の Amazon Resource Name（ARN）
マルチ アーキテクチャ イメージについて
コンテナ イメージには、Arm ワークロードを実行する予定のノードのアーキテクチャと互換性が必要です。コンテナ イメージに ARM との互換性があることを確認するには、マルチ アーキテクチャ イメージを使用することをおすすめします。
マルチアーキテクチャ イメージは、複数のアーキテクチャをサポートできるイメージのことです。これは、1 つのタグがある 1 つのイメージのように見えますが、さまざまなマシン アーキテクチャ上で実行する一連のイメージが含まれています。マルチ アーキテクチャ イメージには、Docker イメージ マニフェスト V2 スキーム 2 または OCI イメージ インデックス仕様との互換性があります。
マルチ アーキテクチャ イメージをクラスタにデプロイすると、コンテナ ランタイムでデプロイ先のノードのアーキテクチャと互換性のあるイメージが自動的に選択されます。ワークロードのマルチアーキテクチャ イメージがあれば、このワークロードを複数のアーキテクチャにデプロイできます。シングル アーキテクチャ イメージを互換性のないノードにスケジューリングすると、読み込み時にエラーが発生します。
Arm ワークロードでマルチ アーキテクチャ イメージを使用する方法について詳しくは、Google Kubernetes Engine（GKE）ドキュメントの Arm ワークロード用のマルチ アーキテクチャ イメージをビルドするをご覧ください。