Arm アーキテクチャまたはマルチアーキテクチャのワークロードの Arm 仮想ノードへのスケジューリングの指定 - Container Service for Kubernetes

前提条件

クラスター：

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

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

注意事項

nodeSelector または nodeAffinity を使用してアプリケーションを Arm ノードにスケジューリングする場合、Toleration の要件はクラスターの Kubernetes バージョンによって異なります。Kubernetes 1.24 より前のバージョンでは、kubernetes.io/arch=arm64:NoSchedule Taint に対する Toleration を Pod 仕様に明示的に追加する必要があります。Kubernetes 1.24 以降では、スケジューラーがこの Taint を自動的に許容するため、Toleration の追加は不要です。

課金

ARM アーキテクチャを使用する ECS インスタンスタイプとその料金の詳細については、次のトピックをご参照ください：

手順1：Arm 仮想ノードの追加

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

コンソール

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

説明
クラスター内のすべての vSwitch が Arm ベースのインスタンスをサポートしていないゾーンにある場合は、まずサポートされているゾーンに vSwitch を作成する必要があります。vSwitch が作成されたら、その ID を vSwitchIds フィールドに追加します。特定のゾーンで vSwitch を作成する方法の詳細については、「vSwitch の作成と管理」をご参照ください。

設定が完了したら、約 30 秒待ちます。その後、ノード ページで virtual-kubelet-<zoneId>-linux-arm64 という名前の新しい仮想ノードが見つかります。

Kubectl

前提条件

クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続してください。

手順

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

kubectl edit configmap eci-profile -n kube-system

enableLinuxArm64Node パラメーターを追加または更新し、その値を true に設定します。
vSwitchIds パラメーターを設定します。vSwitchIds リストで指定された vSwitch のうち少なくとも 1 つが、Arm ベースのインスタンスをサポートするゾーンに存在することを確認してください。

説明
クラスター内のすべての vSwitch が Arm ベースのインスタンスをサポートしていないゾーンにある場合は、まずサポートされているゾーンに vSwitch を作成する必要があります。vSwitch が作成されたら、その ID を vSwitchIds フィールドに追加します。特定のゾーンで vSwitch を作成する方法の詳細については、「vSwitch の作成と管理」をご参照ください。

設定が完了したら、約 30 秒待ちます。その後、ノード ページで virtual-kubelet-<zoneId>-linux-arm64 という名前の新しい仮想ノードが見つかります。

手順2：Arm 仮想ノードへのスケジューリング

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

クラスターに Arm ノードと Arm 以外のノードの両方があり、アプリケーションが Arm 専用である場合は、そのアプリケーションを Arm ノードにスケジュールする必要があります。これにより、Pod が Arm 以外のノードで起動に失敗するのを防ぎます。デフォルトでは、すべての Arm ノードに kubernetes.io/arch=arm64 というラベルが付いています。nodeSelector または nodeAffinity を使用して、アプリケーションを Arm ノードにデプロイできます。

nodeSelector

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

nodeSelector:
  kubernetes.io/arch: arm64 # Arm ノードを指定します。

次のサンプル YAML を使用して、ステートレスアプリケーションを Arm 仮想ノードにデプロイできます。

YAML ファイルを展開して表示

説明

次の YAML は、kubernetes.io/arch=arm64:NoSchedule taint に対する toleration を追加します。お使いのクラスターが Kubernetes 1.24 以降を実行するACK 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 仕様に次の nodeAffinity 制約を追加して、アプリケーションを Arm ノードにデプロイできます。この制約により、Pod はkubernetes.io/arch=arm64 ラベルを持つノードにのみスケジューリングされることが保証されます。

Pod 仕様にこの制約が含まれている場合、スケジューラは自動的にノード上の kubernetes.io/arch=arm64:NoSchedule テイントを容認します。

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

次のサンプル YAML を使用して、ステートレスアプリケーションを Arm 仮想ノードにデプロイできます。

YAML ファイルを展開して表示

説明

次の YAML は、kubernetes.io/arch=arm64:NoSchedule taint に対する toleration を追加します。お使いのクラスターが Kubernetes 1.24 以降を実行するACK 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:
      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: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0

マルチアーキテクチャイメージのスケジューリング

前提条件

クラスターで仮想ノードスケジューリング機能が有効になっており、クラスターとコンポーネントのバージョンが要件を満たしていること。

例

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

例えば、ノードアフィニティを設定することで、ワークロードを Arm または x86 の仮想ノードに優先的にスケジュールできます。優先するタイプのリソースが不足している場合、スケジューラは、もう一方のアーキテクチャの仮想ノードにワークロードをスケジュールすることを試みます。

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

Arm アーキテクチャを優先

以下は、Arm 仮想ノードに優先的にスケジューリングされるワークロードのサンプル YAML です。

YAML ファイルを展開して表示

説明

次の YAML は、kubernetes.io/arch=arm64:NoSchedule taint に対する toleration を追加します。お使いのクラスターが Kubernetes 1.24 以降を実行するACK Pro クラスターの場合、ACK スケジューラがこの taint を自動的に認識するため、toleration を追加する必要はありません。

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 アーキテクチャを優先

YAML ファイルを展開して表示

説明

次の YAML は、kubernetes.io/arch=arm64:NoSchedule taint に対する toleration を追加します。お使いのクラスターが Kubernetes 1.24 以降を実行するACK Pro クラスターの場合、ACK スケジューラがこの taint を自動的に認識するため、toleration を追加する必要はありません。

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

よくある質問

Arm ノードと x86 ノードのスケジューリング優先順位

デフォルトでは、クラスターのスケジューラーはワークロードを ECS インスタンスに優先的にスケジューリングします。ECS インスタンスのリソースが不足している場合、スケジューラーは仮想ノードを考慮します。スケジューラーのスコアリングプラグインの重みを変更しない限り、Arm ノードを優先するように nodeAffinity を設定しても、十分なリソースが利用可能であれば、Pod は x86 の ECS インスタンスにスケジューリングされる可能性があります。したがって、このトピックでの nodeAffinity の設定は、異なる仮想ノードアーキテクチャ間 (Arm 対 x86) のスケジューリング優先順位のみを保証するものであり、仮想ノードと ECS インスタンス間の優先順位を保証するものではありません。

Arm プリエンプティブルインスタンスを使用できますか？

はい、Arm ベースのプリエンプティブルインスタンスは利用可能です。詳細については、「プリエンプティブルインスタンスの使用」をご参照ください。

Arm 仮想ノードのネットワーク設定

ACK クラスターまたはを作成した後、eci-profile の vSwitchIds フィールドを設定して、Arm ベースのインスタンスをサポートするゾーンの vSwitch を選択します。これにより、仮想ノードが Arm アーキテクチャをサポートするようになります。

ACK クラスターまたはで Arm アーキテクチャノードを使用する際の制限事項は何ですか？

現在、アプリマーケットプレイスのコンポーネントは Arm アーキテクチャではサポートされていません。コンポーネントセンターでは、次のカテゴリのコンポーネントのみがサポートされています：

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

Container Service for Kubernetes:Arm アーキテクチャまたはマルチアーキテクチャのワークロードの Arm 仮想ノードへのスケジューリング

前提条件

注意事項

課金

手順1：Arm 仮想ノードの追加

コンソール

Kubectl

前提条件

手順

手順2：Arm 仮想ノードへのスケジューリング

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

nodeSelector

nodeAffinity

前提条件

例

マルチアーキテクチャイメージのスケジューリング

前提条件

例

Arm アーキテクチャを優先

x86 アーキテクチャを優先

よくある質問

Arm ノードと x86 ノードのスケジューリング優先順位

Arm プリエンプティブルインスタンスを使用できますか？

Arm 仮想ノードのネットワーク設定

ACK クラスターまたはで Arm アーキテクチャノードを使用する際の制限事項は何ですか？

関連ドキュメント