ARM またはマルチアーキテクチャワークロードの ARM ベース仮想ノードへのスケジューリング - ACK

デフォルトでは、およびACK Serverless クラスターは、すべてのワークロードを x86 仮想ノードにスケジュールします。ご利用のクラスターに Arm 仮想ノードと x86 仮想ノードなどの Arm 以外の仮想ノードの両方が含まれている場合、Kubernetes のネイティブスケジューリング設定を使用して、Arm 専用のワークロードが Arm 仮想ノードでのみ実行されるようにしたり、マルチアーキテクチャイメージが最初に Arm 仮想ノードにスケジュールされるようにしたりできます。

前提条件

クラスター：

Kubernetes バージョン 1.20 以降を実行するACK Serverless クラスターが作成されていること。詳細については、「クラスターの作成」および「クラスターの手動アップグレード」をご参照ください。

説明
Arm インスタンスは、特定のリージョンおよびゾーンでのみ利用可能です。ご利用のクラスターがサポート対象のリージョンにデプロイされていることを確認してください。サポートされているリージョンとゾーンのリストを表示するには、「ECS インスタンスタイプ：利用可能なリージョンの概要」をご参照ください。
コンポーネント：バージョン 2.9.0 以降の ack-virtual-node コンポーネントがインストールされていること。詳細については、「ACK Virtual Node」をご参照ください。

注意事項

ご利用のクラスターが Kubernetes バージョン 1.24 未満を実行している場合、nodeSelector または nodeAffinity を使用してアプリケーションを Arm ノードにスケジュールする際に、kubernetes.io/arch=arm64:NoSchedule Taint に対する Toleration を宣言する必要があります。ご利用のクラスターが Kubernetes バージョン 1.24 以降を実行している場合、スケジューラは Arm ノード上の kubernetes.io/arch=arm64:NoSchedule Taint を自動的に認識します。この Toleration を手動で宣言する必要はありません。

課金

ARM ベースの ECS インスタンスタイプとその料金の詳細については、次のドキュメントをご参照ください：

ステップ 1：Arm 仮想ノードの追加

クラスターに Arm ワークロードをデプロイする前に、Arm 仮想ノードを作成する必要があります。ECI プロファイルを設定して、Arm アーキテクチャのサポートを有効にできます。eci-profile 設定ファイルは、次のいずれかの方法で編集できます。ECI プロファイルの詳細については、「ECI プロファイルの設定」をご参照ください。

コンソール

ACK コンソールにログインします。左側のナビゲーションウィンドウで、クラスターリスト をクリックします。
クラスターリスト ページで、対象クラスターの名前をクリックします。左側のナビゲーションウィンドウで、設定 > ConfigMap をクリックします。
Namespace ドロップダウンリストで、[kube-system] を選択します。[eci-profile] ConfigMap を見つけ、編集をクリックします。enableLinuxArm64Node キーの値を true に変更します。その後、OK をクリックします。

説明
ご利用のクラスターのゾーンに Arm インスタンスをサポートする vSwitch がない場合は、まずサポートされているゾーンに vSwitch を作成します。次に、その vSwitch ID を vSwitchIds フィールドに追加します。詳細については、「vSwitch の作成と管理」をご参照ください。

kubectl

前提条件

クラスターの KubeConfig ファイルを取得し、kubectl を使用してクラスターに接続します。

手順

次のコマンドを実行して ConfigMap を編集します：

kubectl edit configmap eci-profile -n kube-system

enableLinuxArm64Node パラメーターを true に設定します。
vSwitchIds に、Arm インスタンスをサポートするゾーンの vSwitch を少なくとも 1 つ含めるように設定します。

説明
ご利用のクラスターのゾーンに Arm インスタンスをサポートする vSwitch がない場合は、まずサポートされているゾーンに vSwitch を作成します。次に、その vSwitch ID を vSwitchIds フィールドに追加します。詳細については、「vSwitch の作成と管理」をご参照ください。

ステップ 2：Arm 仮想ノードへのワークロードのスケジューリング

Arm 専用ワークロードの Arm 仮想ノードへのスケジューリング

ご利用のクラスターに Arm ベースのノードと他の種類のノードの両方が含まれており、ワークロードが Arm アーキテクチャのみをサポートしている場合、ワークロードを Arm ベースのノードでのみ実行するようにスケジュールできます。これにより、Pod が他のノードにスケジュールされて失敗するのを防ぎます。デフォルトでは、すべての Arm ベースのノードには kubernetes.io/arch=arm64 ラベルが付いています。`nodeSelector` または `nodeAffinity` を使用して、ワークロードを Arm ベースのノードにデプロイできます。

nodeSelector

`nodeSelector` を使用して Pod を Arm 仮想ノードにスケジュールするには、Pod 仕様に次の制約を追加します。この制約により、ワークロードは `arm64` ラベルを持つノードでのみ実行されることが保証されます。およびACK Serverless クラスター内のすべての Arm 仮想ノードにはこのラベルが付いています。

nodeSelector:
  kubernetes.io/arch: arm64 # Arm ノードにスケジュールします。

次の例は、ステートレスアプリケーションを Arm 仮想ノードにデプロイする方法を示しています。

YAML ファイルの表示

説明

次の YAML ファイルでは、kubernetes.io/arch=arm64:NoSchedule に対する Toleration を追加します。ご利用のクラスターが Kubernetes 1.24 以降を実行するACK Managed Cluster Pro である場合、ACK スケジューラはこの Taint を自動的に検出し、Toleration を宣言する必要はありません。

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 # Arm ノードにスケジュールします。
      tolerations:
      # 仮想ノードの Taint を許容します。
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
      # Arm 仮想ノードの Taint を許容します。
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule
      containers:
      - name: nginx
        image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0

nodeAffinity

前提条件

ご利用のクラスターで仮想ノードスケジューリングが有効になっていること。詳細については、「仮想ノードスケジューリングの有効化」をご参照ください。ご利用のクラスターとコンポーネントのバージョンが要件を満たしていることを確認してください。

例

Pod に次のノードアフィニティ制約を追加して、アプリケーションを Arm64 ノードにデプロイできます。この制約は、Pod が kubernetes.io/arm=arm64 ラベルを持つノードにのみスケジュールできることを指定します。

この制約が Pod 仕様に存在する場合、スケジューラはノード上の kubernetes.io/arch=arm64:NoSchedule Taint に対する Toleration を自動的に追加します。

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

次の例は、ステートレスアプリケーションを Arm 仮想ノードにデプロイする方法を示しています。

YAML ファイルの表示

説明

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
      tolerations:
       # 仮想ノードの Taint を許容します。
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
       # Arm 仮想ノードの Taint を許容します。
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule         
      containers:
      - name: nginx
        image: nginx

マルチアーキテクチャイメージの Arm 仮想ノードへのスケジューリング

前提条件

例

デフォルトでは、およびACK Serverless クラスターは、すべてのワークロードを x86 仮想ノードにスケジュールします。x86 リソースが不足している場合、ワークロードは x86 リソースが利用可能になるまで待機します。アプリケーションイメージが x86 と Arm の両方など、複数のアーキテクチャをサポートしている場合は、クロスアーキテクチャのノードスケジューリングを設定する必要があります。

たとえば、ノードアフィニティを使用して、Arm または x86 仮想ノードへのスケジューリングを優先させることができます。優先されるノードタイプのリソースが不足している場合、スケジューラは他のアーキテクチャのノードにワークロードをスケジュールしようとします。

      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Arm アーキテクチャの優先

次の例は、Arm 仮想ノードを優先する方法を示しています。

YAML ファイルの表示

説明

apiVersion: apps/v1
kind: Deployment
metadata:
  name: arm-prefer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      # 仮想ノードの Taint を許容します。
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Arm 仮想ノードの Taint を許容します。
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      # Arm アーキテクチャのノードを優先します。
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64
      containers:
      - name: my-container
        image: nginx

x86 アーキテクチャの優先

次の例は、x86 仮想ノードを優先する方法を示しています。

YAML ファイルの表示

説明

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amd-prefer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      # 仮想ノードの Taint を許容します。
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Arm 仮想ノードの Taint を許容します。
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule     
      # x86 アーキテクチャのノードを優先します。
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
      containers:
      - name: my-container
        image: nginx

よくある質問

nodeAffinity を設定して Arm ノードを優先したにもかかわらず、Pod が x86 ECS ノードにスケジュールされるのはなぜですか？

デフォルトでは、クラスターのスケジューラは ECS ノードを優先し、ECS リソースが不足している場合にのみワークロードを仮想ノードにスケジュールします。スケジューラースコアリングプラグインの重みを変更せず、ご利用のクラスターに十分な x86 ECS リソースがある場合、`nodeAffinity` を設定して Arm ノードを優先したとしても、Pod は x86 ECS ノードにスケジュールされる可能性があります。したがって、このトピックの `nodeAffinity` 設定は、Arm と x86 の仮想ノード間でのみスケジューリングの優先順位を制御し、仮想ノードと ECS ノードの間では制御しません。

Arm ベースのスポットインスタンスを使用できますか？

はい。Arm ベースのスポットインスタンスは利用可能です。詳細については、「スポットインスタンスの使用」をご参照ください。

あるリージョンでクラスターを作成した後、Arm 仮想ノードをサポートするようにネットワークを構成するにはどうすればよいですか？

サポートされているゾーンにまたはACK Serverless クラスターを作成した後、eci-profile の `vSwitchIds` フィールドに、Arm インスタンスをサポートするゾーンの vSwitch を含めるように設定する必要があります。これにより、Arm 仮想ノードが作成されることが保証されます。

およびACK Serverless クラスターで Arm ノードを使用する場合の制限事項は何ですか？

現在、Arm アーキテクチャは Marketplace コンポーネントをサポートしていません。コンポーネントセンターは、次のモジュールのみをサポートしています：

コアコンポーネント
ロギングとモニタリング
ストレージ
ネットワーキング

参照

Container Registry Enterprise Edition (ACR EE) を使用して、マルチアーキテクチャコンテナイメージをビルドできます。詳細については、「マルチアーキテクチャコンテナイメージのビルド」をご参照ください。
標準の Arm ECS ノードの作成と管理方法の詳細については、「Arm ノードへのワークロードのスケジューリング」をご参照ください。
ビッグデータタスクを実行し、基盤となるクラスターリソースの管理を避けたい場合は、「Arm ベースの仮想ノードでの Spark ジョブの実行」をご参照ください。