全部產品
Search

搜尋本產品

    Container Service for Kubernetes：調度Arm架構或多架構工作負載至Arm虛擬節點

    文件中心

    Container Service for Kubernetes：調度Arm架構或多架構工作負載至Arm虛擬節點

    更新時間：Jul 31, 2024

    ACK Serverless叢集預設會將所有工作負載調度到x86架構的虛擬節點。如果您的叢集中既有Arm虛擬節點，又有非Arm虛擬節點（例如x86虛擬節點），為了確保只相容Arm架構的工作負載調度到Arm虛擬節點，或多架構鏡像優先調度到Arm虛擬節點，您可以基於Kubernetes原生調度配置來實現。

    前提條件

    • 叢集：

      已建立ACK Serverless叢集，且叢集版本為v1.20及以上。具體操作，請參見建立叢集、手動升級叢集。

      說明

      Arm執行個體開放的地區及可用性區域是存在限制，請保證叢集在已開放地區。查詢Arm執行個體開放的地區及可用性區域，請參見ECS執行個體規格可購買地區總覽。

    • 組件：已安裝ack-virtual-node組件，且組件版本為2.9.0及以上。詳細資料，請參見ACK Virtual Node。

    注意事項

    如果您的叢集版本為v1.24之前，在使用nodeSelector或者nodeAffinity指定應用調度至Arm節點時，您需要同時聲明汙點容忍kubernetes.io/arch=arm64:NoSchedule的tolerations。如果您的叢集版本為v1.24版本及之後，調度器能夠自動識別Arm節點的汙點kubernetes.io/arch=arm64:NoSchedule，無需您額外聲明tolerations。

    相關計費

    建立的Arm架構類型的ECI Pod，按照實際產生的ECS規格進行計費，不按照vCPU和記憶體計費。

    重要

    ECI Pod建立成功後，您可以執行kubectl describe pod命令查看其YAML詳情。通過k8s.aliyun.com/eci-instance-spec欄位確認ECI Pod實際使用的ECS規格，ECI會按照該ECS規格進行計費。

    關於Arm架構的ECS規格的詳細資料，請參見：

    步驟一：添加Arm架構的虛擬節點

    在叢集中部署Arm工作負載之前，需要先建立Arm架構的虛擬節點（Virtual Node）。您可以通過配置ECI Profile建立支援Arm架構類型的虛擬節點。您可以通過以下兩種方式編輯eci-profile設定檔。關於ECI Profile的詳細資料，請參見配置eci-profile。

    通過Container Service管理主控台

    1. 登入Container Service管理主控台，在左側導覽列選擇叢集。

    2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇組態管理 > 配置項。

    3. 選擇命名空間為kube-system，找到eci-profile單擊編輯，將索引值enableLinuxArm64Node修改為true。然後單擊確定。

      image.png

      說明

      如果叢集已有vSwitch的所處可用性區域均未支援Arm執行個體，您需要先建立指定可用性區域的vSwitch。建立成功後，將vSwitch的ID添加進vSwitchIds中。關於建立指定可用性區域的vSwitch，請參見建立和管理交換器。

    通過kubectl edit命令

    前提條件

    擷取叢集KubeConfig並通過kubectl工具串連叢集。

    操作步驟

    執行如下命令，編輯ConfigMap。

    kubectl edit configmap eci-profile -n kube-system

    1. 添加或修改參數enableLinuxArm64Node為true。

    2. 設定vSwitchIds，確保當前叢集使用的vSwitchIds中，至少有一個支援Arm執行個體的可用性區域的vSwitch。

      說明

      如果叢集已有vSwitch的所處可用性區域均未支援Arm執行個體，您需要先建立指定可用性區域的vSwitch。建立成功後，將vSwitch的ID添加進vSwitchIds中。關於建立指定可用性區域的vSwitch，請參見建立和管理交換器。

      修改完成後，等待大概30s，您可以在節點頁面查看建立的名為virtual-kubelet-<zoneId>-linux-arm64的虛擬節點。

    步驟二：指定工作負載調度到Arm虛擬節點

    指定Arm架構的工作負載調度到Arm虛擬節點

    如果您的叢集中既有Arm節點也有非Arm節點，且您的應用只支援Arm架構，您可以指定應用運行在Arm節點上，以免應用Pod被調度到非Arm節點上導致啟動失敗。所有Arm節點上預設帶有Labelkubernetes.io/arch=arm64，您可以通過兩種方式nodeSelector和nodeAffinity指定應用部署到Arm節點上。

    使用nodeSelector

    您可以在Pod上增加如下約束，使用nodeSelector將Pod調度到Arm架構的virtual-node上。nodeSelector將指定此工作負載僅調度到具有arm64標籤的節點，ACK Serverless叢集中的Arm架構的virtual-node都具有此標籤。

    nodeSelector:
  kubernetes.io/arch: arm64 # 指定Arm節點。

    您可以使用以下範例程式碼將一個無狀態應用部署到Arm虛擬節點。

    展開查看YAML檔案

    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節點。
      containers:
      - name: nginx
        image: nginx

    使用nodeAffinity

    前提條件

    已開啟叢集虛擬節點調度策略，且叢集版本、組件版本符合要求。

    操作樣本

    您可以在Pod上增加如下約束，使用節點親和性聲明指定應用部署到Arm節點上。此約束指定Pod只能被調度到帶有Label kubernetes.io/arm=arm64的節點上。

    當Pod Spec上帶有此約束時，調度器自動容忍節點上的汙點kubernetes.io/arch=arm64:NoSchedule。

    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
      containers:
      - name: nginx
        image: nginx

    指定多架構鏡像調度到Arm虛擬節點

    前提條件

    已開啟叢集虛擬節點調度策略，且叢集版本、組件版本符合要求。

    操作樣本

    ACK Serverless叢集預設會將所有工作負載調度到x86架構的虛擬節點，並在x86節點資源不足時保持等待x86節點資源。如果您的應用鏡像為多架構鏡像，例如同時支援x86和Arm架構，您需要配置跨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:
# 容忍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:
# 容忍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優先將Pod調度到Arm架構的節點，卻調度到x86架構的ECS節點上？

    叢集調度器預設優先調度到ECS節點，ECS節點資源不足時調度到虛擬節點。在不修改調度器計分外掛程式權重的情況下，如叢集中存在資源充足的x86 ECS節點，即使通過nodeAffinity配置了優先調度到Arm架構的節點，Pod也可能會被調度到x86架構的ECS節點上。因此，通過本文中的nodeAffinity配置，只能保證不同架構（Arm/x86）虛擬節點的優先順序，而無法保證虛擬節點和ECS節點的優先順序。

    是否可以使用Arm架構類型的競價（Spot）執行個體？

    目前已經提供Arm架構的競價執行個體。使用方式，請參見使用搶佔式執行個體。

    在相應地區建立叢集後，如何配置網路來建立出支援Arm可用性區域的虛擬節點？

    在相應可用性區域建立ACK Serverless叢集後，通過配置eci-profile中vSwitchIds欄位，選擇支援Arm執行個體的可用性區域的虛擬交換器，從而保證建立出支援Arm架構的虛擬節點。

    在ACK Serverless叢集中使用Arm架構節點的限制？

    目前，Arm架構不支援應用市場的組件；組件中心僅支援以下模組的組件：

    • 核心組件

    • 日誌和監控

    • 儲存

    • 網路

    相關文檔