すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:ARMまたはマルチアーキテクチャのワークロードをARMベースの仮想ノードにスケジュールする

最終更新日:Dec 09, 2024

デフォルトでは、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コンソールの使用

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[設定] > [設定] を選択します。

  3. [名前空間] ドロップダウンリストから [kube-system] を選択します。 eci-profileを見つけ、[操作] 列の [編集] をクリックします。 次に、enableLinuxArm64Nodeパラメーターをtrueに設定します。 [OK] をクリックします。

    image.png

    説明

    クラスターのすべてのvSwitchがARMベースのインスタンスをサポートしていないゾーンに存在する場合、ARMベースのインスタンスをサポートするゾーンにvSwitchを作成します。 次に、vSwitchIdsパラメーターにvSwitchのIDを指定します。 ゾーンでvSwitchを作成する方法の詳細については、「vSwitchの作成と管理」をご参照ください。

kubectl editコマンドを実行する

前提条件

クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続します。 詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。

手順

次のコマンドを実行して、eci-profile ConfigMapを変更します。

kubectl edit configmap eci-profile -n kube-system
  1. enableLinuxArm64Nodeパラメーターをtrueに設定します。 パラメーターが存在しない場合は、パラメーターを追加してtrueに設定します。

  2. 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ベースの仮想ノードにスケジュールする方法の例を示しています。

展開してYAMLテンプレートを表示

説明

次のYAMLテンプレートは、kubernetes.io/arch=arm64:NoScheduleテイントの許容範囲を追加します。 クラスターがKubernetes 1.24以降を実行する場合、スケジューラは自動的にこの汚れを認識できます。 公差を手動で追加する必要はありません。

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 # Specify the label that is used to select an ARM-based node. 
      tolerations:
      # Tolerate the taint of the virtual node.
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
      # Tolerate the taint of the ARM-based virtual node.
        - 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

前提条件

クラスターが仮想ノードスケジューリングを有効にしました。クラスターの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ベースの仮想ノードにスケジュールする方法の例を示しています。

展開してYAMLテンプレートを表示

説明

次のYAMLテンプレートは、kubernetes.io/arch=arm64:NoScheduleテイントの許容範囲を追加します。 クラスターがKubernetes 1.24以降を実行する場合、スケジューラは自動的にこの汚れを認識できます。 公差を手動で追加する必要はありません。

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:
       # Tolerate the taint of the virtual node.
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
       # Tolerate the taint of the ARM-based virtual node.
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule 
      containers:
      - name: nginx
        image: nginx

マルチアーキテクチャのワークロードを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ベースの仮想ノードにワークロードをスケジュールする方法の例を示しています。

展開してYAMLテンプレートを表示

説明

次のYAMLテンプレートは、kubernetes.io/arch=arm64:NoScheduleテイントの許容範囲を追加します。 クラスターがKubernetes 1.24以降を実行する場合、スケジューラは自動的にこの汚れを認識できます。 公差を手動で追加する必要はありません。

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:
      # Tolerate the taint of the virtual node.
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Tolerate the taint of the ARM-based virtual node. 
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      # Preferably schedule the workload to an ARM-based node. 
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64
      containers:
      - name: my-container
        image: nginx

仮想ノードをx86-basedするスケジュール

次のサンプルコードは、ワークロードをx86-based仮想ノードにスケジュールする方法の例を示しています。

展開してYAMLテンプレートを表示

説明

次のYAMLテンプレートは、kubernetes.io/arch=arm64:NoScheduleテイントの許容範囲を追加します。 クラスターがKubernetes 1.24以降を実行する場合、スケジューラは自動的にこの汚れを認識できます。 公差を手動で追加する必要はありません。

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:
      # Tolerate the taint of the virtual node.
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Tolerate the taint of ARM-based virtual nodes. 
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      # Preferably schedule the workload to a x86-based virtual node. 
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
      containers:
      - name: my-container
        image: nginx

よくある質問

ポッドを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アーキテクチャをサポートしています。

  • 主要コンポーネント

  • ロギングと監視コンポーネント

  • ボリュームコンポーネント

  • ネットワークコンポーネント

関連ドキュメント