デフォルトでは、ACKクラスターは、x86アーキテクチャを使用する仮想ノードへのすべてのワークロードをスケジュールします。 クラスターにARMベースの仮想ノードと、x86-based仮想ノードなどの他の仮想ノードが含まれている場合は、ARMワークロードをARMベースの仮想ノードにのみスケジュールするようにKubernetesスケジューリングを設定できます。
前提条件
クラスター:
Kubernetes 1.20以降を実行するACKクラスターが作成されます。 詳細については、「ACK管理クラスターの作成」および「ACKクラスターの手動アップグレード」をご参照ください。
説明ARMベースのECS (Elastic Compute Service) インスタンスは、特定のリージョンとゾーンでのみ使用できます。 いずれかのリージョンにクラスターが作成されていることを確認します。 ARMベースのECSインスタンスが使用可能なリージョンとゾーンの詳細については、「各リージョンで使用可能なインスタンスタイプ」をご参照ください。
コンポーネント: ack-virtual-nodeコンポーネントがインストールされ、コンポーネントのバージョンが2.9.0以降です。 詳細については、「ack-virtual-node」をご参照ください。
使用上の注意
クラスターが1.24より前のバージョンのKubernetesを実行している場合、ARMベースの仮想ノードにワークロードをスケジュールするためにnodeSelector
またはnodeAffinity
を定義するときに、kubernetes.io/arch=arm64:NoSchedule
テントを許容する許容範囲
も追加する必要があります。 クラスターがKubernetes 1.24以降を実行している場合、スケジューラは、ARMベースの仮想ノードのkubernetes.io/arch=arm64:NoSchedule
テイントを自動的に認識できます。 寛容
を追加する必要はありません。
課金
ARMアーキテクチャを採用するエラスティックコンテナインスタンスにデプロイされたポッドは、エラスティックコンテナインスタンスの作成に使用されたECSインスタンスタイプに基づいて課金されます。 ポッドは、vCPUとメモリの使用量に基づいて課金されません。
Elastic Container Instanceベースのポッドを作成したら、kubectl describe pod
コマンドを実行して、ポッドのYAMLコンテンツを表示できます。 k8s.aliyun.com/eci-instance-spec
パラメーターは、ポッドで使用されるECSインスタンスタイプを示します。 ポッドは、ECSインスタンスタイプに基づいて課金されます。
ARMアーキテクチャを使用するECSインスタンスタイプの詳細については、以下のトピックを参照してください。
ステップ1: ARMベースの仮想ノードを追加する
ARMワークロードをクラスターにデプロイする前に、ARMベースの仮想ノードを作成する必要があります。 eci-profileを設定して、ARMベースの仮想ノードを作成できます。 次のいずれかの方法を使用して、eci-profile
ConfigMapを変更できます。 詳細については、「eci-profileの設定」をご参照ください。
ACKコンソールの使用
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[名前空間] ドロップダウンリストから [kube-system] を選択します。 eci-profileを見つけ、[操作] 列の [編集] をクリックします。 次に、
enableLinuxArm64Node
パラメーターをtrue
に設定します。 [OK] をクリックします。説明クラスターのすべてのvSwitchがARMベースのインスタンスをサポートしていないゾーンに存在する場合、ARMベースのインスタンスをサポートするゾーンにvSwitchを作成します。 次に、
vSwitchIds
パラメーターにvSwitchのIDを指定します。 ゾーンでvSwitchを作成する方法の詳細については、「vSwitchの作成と管理」をご参照ください。設定を完了したら、約30秒待ちます。 次に、[ノード] ページで
virtual-kubelet-<zoneId>-linux-arm64
という名前の仮想ノードを見つけることができます。
kubectl editコマンドを実行する
前提条件
クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します。 詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。
手順
次のコマンドを実行して、eci-profile ConfigMapを変更します。
kubectl edit configmap eci-profile -n kube-system
enableLinuxArm64Node
パラメーターをtrue
に設定します。 パラメーターが存在しない場合は、パラメーターを追加してtrueに設定します。vSwitchIds
パラメーターを指定します。vSwitchIds
パラメーターで指定されたvSwitchが、ARMベースのインスタンスをサポートするゾーンにあることを確認します。説明クラスターのすべてのvSwitchがARMベースのインスタンスをサポートしていないゾーンに存在する場合、ARMベースのインスタンスをサポートするゾーンにvSwitchを作成します。 次に、
vSwitchIds
パラメーターにvSwitchのIDを指定します。 ゾーンでvSwitchを作成する方法の詳細については、「vSwitchの作成と管理」をご参照ください。設定を完了したら、約30秒待ちます。 次に、[ノード] ページで
virtual-kubelet-<zoneId>-linux-arm64
という名前の仮想ノードを見つけることができます。
手順2: ARMベースの仮想ノードへのワークロードのスケジュール
ARMベースの仮想ノードへのARMワークロードのスケジュール
クラスターにARMベースの仮想ノードとその他のノードが含まれているが、すべてのワークロードがARMアーキテクチャを使用している場合、ARMベースの仮想ノードのみにワークロードをスケジュールする必要があります。 ポッドが他のノードにスケジュールされている場合、ポッドは起動できません。 デフォルトでは、すべてのARMベースの仮想ノードにkubernetes.io/arch=arm64
ラベルが付いています。 nodeSelectorまたはnodeAffinityを設定して、ARMベースの仮想ノードへのワークロードをスケジュールできます。
nodeSelector
次の制約をポッドに追加して、nodeSelectorがポッドをARMベースの仮想ノードにスケジュールするように強制することができます。 この場合、nodeSelectorは、arm64
ラベルを持つノードにのみポッドをスケジュールします。 ACKクラスター内のすべてのARMベースの仮想ノードには、このラベルがあります。
nodeSelector:
kubernetes.io/arch: arm64 # Specify the label that is used to select an ARM-based node.
次のサンプルコードは、展開によって作成されたポッドをARMベースの仮想ノードにスケジュールする方法の例を示しています。
nodeAffinity
前提条件
クラスターが仮想ノードスケジューリングを有効にしました。クラスターのKubernetesバージョンとコンポーネントバージョンが要件を満たしています。
手順
次の制約をポッドに追加して、ノードアフィニティに基づいてARMベースのノードにポッドをスケジュールすることができます。 この制約を追加すると、kubernetes.io/arm=arm64
ラベルを持つノードにのみポッドをスケジュールできます。
podSpecにこの制約が含まれている場合、スケジューラは自動的にkubernetes.io/arch=arm64:NoSchedule
を許容します。
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
次のサンプルコードは、展開によって作成されたポッドをARMベースの仮想ノードにスケジュールする方法の例を示しています。
マルチアーキテクチャのワークロードをARMベースの仮想ノードにスケジュールする
前提条件
クラスターが仮想ノードスケジューリングを有効にしました。クラスターのKubernetesバージョンとコンポーネントバージョンが要件を満たしています。
手順
デフォルトでは、ACKクラスターのワークロードは仮想ノードをx86-basedするようにスケジュールされます。 x86-basedの仮想ノードが不足している場合、ポッドはPending状態のままです。 x86およびARMアーキテクチャをサポートするイメージなど、マルチアーキテクチャイメージを使用する場合は、x86およびARMアーキテクチャにまたがるノードにポッドをスケジュールする必要があります。
たとえば、ARMベースの仮想ノードまたはx86-based仮想ノードへのワークロードをスケジュールするようにノードアフィニティを設定できます。 要求された仮想ノードが不十分な場合、スケジューラは他のタイプの仮想ノードにワークロードをスケジュールしようとします。
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
ARMベースの仮想ノードにスケジュールすることが望ましい
次のサンプルコードは、ARMベースの仮想ノードにワークロードをスケジュールする方法の例を示しています。
仮想ノードをx86-basedするスケジュール
次のサンプルコードは、ワークロードをx86-based仮想ノードにスケジュールする方法の例を示しています。
よくある質問
ポッドをARMベースのノードにスケジュールするようにnodeAffinityを設定した後、ポッドがECSインスタンスをx86-basedするようにスケジュールされるのはなぜですか。
デフォルトでは、クラスタースケジューラはECSインスタンスへのワークロードをスケジュールします。 ECSインスタンスのリソースが不足している場合、クラスタースケジューラは仮想ノードへのワークロードをスケジュールします。 スケジューラースコアリングプラグインの重みを変更しない場合、クラスターに十分なリソースがあり、nodeAffinityが適切にポッドをARMベースのノードにスケジュールするように設定されている場合でも、ポッドはECSインスタンスをx86-basedするようにスケジュールされる可能性があります。 したがって、このトピックのnodeAffinity設定を使用して、ワークロードをARMベースまたはx86-based仮想ノードにスケジュールする優先度を指定できます。 仮想ノードまたはECSインスタンスへのワークロードをスケジュールする優先度は保証できません。
ARMベースのプリエンプティブルインスタンスを使用できますか?
はい、ARMベースのプリエンプティブルインスタンスが利用可能です。 詳細については、「プリエンプティブルインスタンスの使用」をご参照ください。
クラスターを作成した後、ARMベースの仮想ノードをサポートするネットワークを構成するにはどうすればよいですか。
ARMベースのインスタンスをサポートするゾーンにACKクラスターを作成した後、eci-profile ConfigMapのvSwitchIds
パラメーターを変更して、ゾーンに存在するvSwitchを選択できます。 これにより、作成する仮想ノードがARMアーキテクチャをサポートします。
ACKクラスターでARMベースのノードを使用する場合の制限は何ですか?
ACKコンソールのMarketplaceページに表示されるコンポーネントは、ARMアーキテクチャをサポートしていません。 次のコンポーネントのみがARMアーキテクチャをサポートしています。
主要コンポーネント
ロギングと監視コンポーネント
ボリュームコンポーネント
ネットワークコンポーネント
関連ドキュメント
Container Registry Enterprise Editionインスタンスを使用してマルチアーキテクチャコンテナイメージを構築する方法の詳細については、「マルチアーチコンテナイメージの構築」をご参照ください。
通常のARMベースのECSノードを作成および管理する方法の詳細については、「ARMベースのノードプールの設定」をご参照ください。
基盤となるクラスターリソースを維持することなくビッグデータジョブを実行する方法の詳細については、「ARMベースの仮想ノードでのSparkジョブの実行」をご参照ください。