Container Service for Kubernetes (ACK) は、デフォルトで x86 ベースのワーカーノードにワークロードをスケジュールします。ARM ベースと x86 ベースのノードが混在するクラスターでは、Kubernetes のスケジューリングを設定して、ARM ワークロードを ARM ベースのノードに限定してルーティングするか、マルチアーキテクチャのワークロードに対して ARM ベースのノードを優先するようにします。
前提条件
開始する前に、以下を確認してください。
オペレーティングシステムとして Alibaba Cloud Linux 3 を使用し、Kubernetes 1.20 以降を実行しているクラスター。詳細については、「クラスターの作成」および「クラスターのアップグレード」をご参照ください。
kube-scheduler コンポーネントがインストールされていること。詳細については、「コンポーネントの管理」をご参照ください。
[アドオン] ページでは、[コアコンポーネント]、[ログとモニタリング]、[ストレージ]、[ネットワーキング] コンポーネントのみが ARM ベースのノードプールをサポートします。ACK コンソールの [マーケットプレイス] ページにリストされているコンポーネントは、ARM ベースのノードプールにはデプロイできません。
ARM ベースのノードを優先する
スケジューリング構成に ARM ベースのノードを追加する前に、以下の制約にご注意ください。
ARM イメージのみ:ARM ベースのノードにスケジュールされるアプリケーションは、ARM アーキテクチャ用にコンパイルされたコンテナイメージを使用する必要があります。x86 専用のイメージを ARM ノードにスケジュールすると、Pod の起動に失敗します。
マルチアーキテクチャイメージ:アプリケーションイメージが ARM と x86 の両方をサポートしている場合は、
preferredDuringSchedulingIgnoredDuringExecutionを使用して ARM ノードを優先し、ARM のキャパシティが利用できない場合には x86 ノードへのフォールバックを許可します。
Taint による ARM ノードの保護
kubernetes.io/arch=arm64:NoSchedule Taint を ARM ベースのノードに追加することで、ARM アーキテクチャをサポートしないワークロードが誤ってスケジュールされるのを防ぎます。
Kubernetes は 3 つの Taint 効果を提供します。
| 効果 | 動作 |
|---|---|
NoSchedule | 一致する Toleration がない新しい Pod は、そのノードにスケジュールされません。すでにノードで実行中の Pod は退去させられません。 |
NoExecute | 一致する Toleration がない新しい Pod は、そのノードにスケジュールされません。一致する Toleration がない既存の Pod は退去させられます。 |
PreferNoSchedule | スケジューラは、一致する Toleration がない Pod をノードに配置することを避けますが、厳密には妨げません。 |
ARM ベースのノードには NoSchedule を使用します。これにより、既存の Pod に影響を与えることなく、互換性のない新しい Pod をブロックします。
Kubernetes バージョン別の Toleration の動作:
Kubernetes < 1.24:
nodeSelectorまたはnodeAffinityを使用して ARM ノードをターゲットにする場合、Pod の spec にkubernetes.io/arch=arm64:NoScheduleの Toleration を手動で追加する必要があります。Kubernetes >= 1.24:Pod が ARM ノードをターゲットにする場合、スケジューラは自動的に
kubernetes.io/arch=arm64:NoScheduleTaint を許容するため、手動での Toleration の追加は不要です。
課金
ARM アーキテクチャを使用する ECS インスタンスタイプとその料金については、以下をご参照ください。
ARM ベースのノードプールの作成
ノードプールを作成する際、インスタンスタイプ セクションで アーキテクチャ を ARM に設定し、必要に応じて他のパラメーターを設定してから、ノードプールの作成を完了します。詳細については、「ノードプールの作成と管理」をご参照ください。
各リージョンで利用可能なインスタンスタイプの一覧については、各リージョンで利用可能なインスタンスタイプをご参照ください。
クラスターに ARM ベースのノードを追加するには、新しいクラスターを作成する際に追加するか、既存のクラスターにノードプールを追加します。
クラスター作成時に ARM ベースのノードプールを作成
クラスターの作成時にノードプールを設定する場合、インスタンスタイプ セクションで、アーキテクチャ を ARM に設定し、g8m 汎用インスタンスファミリーからインスタンスタイプを選択して、その他のパラメーターを設定した後、クラスターの作成を完了します。クラスターの作成方法について詳しくは、「ACK マネージドクラスターの作成」をご参照ください。
各リージョンで利用可能なインスタンスタイプ にアクセスして、各リージョンで利用可能なインスタンスタイプを表示します。
クラスターの作成時にノードプールを設定する場合、[アーキテクチャ] を Arm に設定し、[インスタンスタイプ] セクションで g8m 汎用インスタンスを選択します。その他のパラメーターは、要件に応じて設定してください。
詳細については、「ACK マネージドクラスターの作成」をご参照ください。

利用可能な ARM インスタンスタイプをリージョン別に表示するには、詳細については、「各リージョンで利用可能な ECS インスタンスタイプ」をご参照ください。
既存のクラスターに ARM ベースのノードプールを追加
ノードプールを作成する際は、[アーキテクチャ] を ARM に設定し、[インスタンスタイプ] セクションで他のパラメーターを要件に応じて設定します。
詳細については、「ノードプールの作成と管理」をご参照ください。

利用可能な ARM インスタンスタイプをリージョン別に表示するには、「各リージョンで利用可能な ECS インスタンスタイプ」をご参照ください。
ARM 専用ワークロードの ARM ベースノードへのスケジューリング
ワークロードが ARM アーキテクチャのみを使用し、クラスターに非 ARM ノードが含まれている場合、それらのワークロードを ARM ノードにルーティングします。互換性のないノードにスケジュールされた Pod は起動に失敗します。
すべての ARM ベースのノードには、自動的に kubernetes.io/arch=arm64 ラベルが付与されます。nodeSelector または nodeAffinity を使用して、このラベルをターゲットにします。
nodeSelector
Pod の spec に以下のフィールドを追加して、スケジューリングを ARM ベースのノードに制限します。
nodeSelector:
kubernetes.io/arch: arm64 # arm64 ラベルを持つノードにのみスケジュールします。以下の Deployment は nodeSelector を使用して、すべての Pod を ARM ベースのノードにスケジュールします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: only-arm
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
kubernetes.io/arch: arm64 # arm64 ラベルを持つノードにのみスケジュールします。
containers:
- name: nginx
image: nginx確認:マニフェストを適用した後、以下のコマンドを実行し、Pod が ARM ベースのノードで実行されていることを確認します。
kubectl get pods -o wide期待される出力 (NODE 列に ARM ベースのノード名が表示されます):
NAME READY STATUS RESTARTS AGE NODE
only-arm-xxxxxxxxx-xxxxx 1/1 Running 0 30s <arm-node-name>nodeAffinity
nodeAffinity と requiredDuringSchedulingIgnoredDuringExecution を使用して、ARM 専用のスケジューリングを強制します。この制約が存在する場合、スケジューラは自動的に kubernetes.io/arch=arm64:NoSchedule Taint を許容します。
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64以下の Deployment は nodeAffinity を使用して、すべての Pod を ARM ベースのノードにスケジュールします。
apiVersion: apps/v1
kind: Deployment
metadata:
name: only-arm
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
containers:
- name: nginx
image: nginx確認:マニフェストを適用した後、以下のコマンドを実行し、Pod が ARM ベースのノードで実行されていることを確認します。
kubectl get pods -o wide期待される出力:
NAME READY STATUS RESTARTS AGE NODE
only-arm-xxxxxxxxx-xxxxx 1/1 Running 0 30s <arm-node-name>マルチアーキテクチャワークロードの ARM ベースノードへのスケジューリング
アプリケーションイメージが ARM と x86 の両方をサポートしている場合、preferredDuringSchedulingIgnoredDuringExecution を設定して ARM ベースのノードを優先します。ARM のキャパシティが不足している場合、Pod は保留状態になる代わりに x86 ノードにフォールバックします。
ARM ベースのノードを優先
以下のデプロイメントは、ARM ベースのノードを優先します。ARM ベースのノードが利用できない場合、Pod は x86 ノードにフォールバックします。
x86 ベースのノードを優先
よくある質問
ARM ベースのプリエンプティブルインスタンスを使用できますか?
はい。詳細については、「プリエンプティブルインスタンスの使用」をご参照ください。
ARM ベースのノードでサポートされているコンポーネントは何ですか?
ACK クラスターでは、以下のコンポーネントカテゴリのみが ARM アーキテクチャをサポートしています。
主要コンポーネント
ロギングおよびモニタリングコンポーネント
ボリュームコンポーネント
ネットワークコンポーネント
ACK コンソールの [マーケットプレイス] ページのコンポーネントは、ARM アーキテクチャをサポートしていません。
次のステップ
ARM ベースの仮想ノードを作成し、それらにワークロードをスケジュールします。詳細については、「ARM ベースの仮想ノードへのワークロードのスケジューリング」をご参照ください。
Container Registry Enterprise Edition を使用して、マルチアーキテクチャのコンテナイメージをビルドします。詳細については、「マルチアーキテクチャのコンテナイメージのビルド」をご参照ください。
クラスターリソースを管理することなく、ARM ベースの仮想ノードで Spark ジョブを実行します。詳細については、「ARM ベースの仮想ノードでの Spark ジョブの実行」をご参照ください。