This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

將工作負載叢集部署到專用硬體

Tanzu Kubernetes Grid 支援在 vSphere 7.0 及更新版本上將工作負載叢集部署到特定類型且啟用了 GPU 的主機。

部署啟用了 GPU 的工作負載叢集

若要在 vSphere 工作負載叢集中,使用具有 GPU 的節點,必須啟用 PCI 傳遞模式。這允許叢集略過 ESXi 主管直接存取 GPU,從而提供類似於原生系統上的 GPU 效能的效能層級。使用 PCI 傳遞模式時,每個 GPU 裝置都專用於 vSphere 工作負載叢集中虛擬機器 (VM)。

附註

若要將啟用了 GPU 的節點新增到現有叢集,請使用 tanzu cluster node-pool set 命令。

必要條件

程序

若要建立工作負載叢集,且其中含有啟用了 GPU 的主機,請遵循以下步驟,來啟用 PCI 傳遞、建置自訂機器映像、建立叢集組態檔和 Tanzu Kubernetes 版本、部署工作負載叢集,以及使用 Helm 來安裝 GPU Operator。

  1. 將具有 GPU 卡的 ESXi 主機新增到 vSphere Client。

  2. 啟用 PCI 傳遞,並記錄 GPU 識別碼,如下所示:

    1. 在 vSphere Client 中,選取 GPU 叢集中的目標 ESXi 主機。
    2. 選取設定 (Configure) > 硬體 (Hardware) > PCI 裝置 (PCI Devices)
    3. 選取所有 PCI 裝置索引標籤。
    4. 從清單中選取目標 GPU。
    5. 按一下切換傳遞 (Toggle Passthrough)
    6. 在 [一般資訊 (General Information)] 下,記錄 [裝置識別碼 (Device ID)] 和 [廠商識別碼 (Vendor ID)] (在下圖中以綠色反白顯示)。相同的 GPU 卡會有相同的識別碼。對於叢集組態檔,您將需要這些。

    顯示 PCI 裝置清單的 vSphere Client 介面。在清單下方,裝置識別碼和廠商識別碼的位置會以綠色方塊反白顯示。

  3. 使用工作負載叢集範本中的範本來建立工作負載叢集組態檔,並包含以下變數:

    ...
    VSPHERE_WORKER_PCI_DEVICES: "0x<VENDOR-ID>:0x<DEVICE-ID>"
    VSPHERE_WORKER_CUSTOM_VMX_KEYS: 'pciPassthru.allowP2P=true,pciPassthru.RelaxACSforP2P=true,pciPassthru.use64bitMMIO=true,pciPassthru.64bitMMIOSizeGB=<GPU-SIZE>'
    VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST: "<BOOLEAN>"
    VSPHERE_WORKER_HARDWARE_VERSION: vmx-17
    WORKER_ROLLOUT_STRATEGY: "RollingUpdate"
    

    其中:

    附註

    每個虛擬機器只能使用一種 GPU 類型。例如,不能在單一虛擬機器上同時使用 NVIDIA V100 和 NVIDIA Tesla T4,但可以使用具有相同廠商識別碼和裝置識別碼的多個 GPU 執行個體。

    tanzu CLI 不允許更新 MachineDeployment 上的 WORKER_ROLLOUT_STRATEGY 規格。如果叢集升級因 PCI 裝置無法使用而停滯,VMware 建議使用 kubectl CLI 來編輯 MachineDeployment 政策。推出策略定義在 spec.strategy.type 中。

    如需可以設定給啟用了 GPU 的叢集的完整變數清單,請參閱〈組態檔變數參考〉中的啟用了 GPU 的叢集

  4. 透過執行以下命令,來建立工作負載叢集:

    tanzu cluster create -f CLUSTER-CONFIG-NAME
    

    其中 CLUSTER-CONFIG-NAME 是您在先前的步驟中建立的叢集組態檔的名稱。

  5. 新增 NVIDIA Helm 存放庫。

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
    && helm repo update
    
  6. 安裝 NVIDIA GPU Operator:

    helm install --kubeconfig=./KUBECONFIG  --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
    

    其中,KUBECONFIG 是工作負載叢集 kubeconfig 的名稱和位置。如需詳細資訊,請參閱擷取工作負載叢集 kubeconfig

    如需此命令中的參數的相關資訊,請參閱 NVIDIA 說明文件中的安裝 GPU Operator

  7. 確定 NVIDIA GPU Operator 正在執行:

    kubectl --kubeconfig=./KUBECONFIG  get pods -A
    

    輸出類似於:

    NAMESPACE         NAME                                                              READY   STATUS     RESTARTS   AGE
    gpu-operator      gpu-feature-discovery-szzkr                                       1/1     Running     0         6m18s
    gpu-operator      gpu-operator-1676396573-node-feature-discovery-master-7795vgdnd   1/1     Running     0         7m7s
    gpu-operator      gpu-operator-1676396573-node-feature-discovery-worker-bq6ct       1/1     Running     0         7m7s
    gpu-operator      gpu-operator-84dfbbfd8-jd98f                                      1/1     Running     0         7m7s
    gpu-operator      nvidia-container-toolkit-daemonset-6zncv                          1/1     Running     0         6m18s
    gpu-operator      nvidia-cuda-validator-2rz4m                                       0/1     Completed   0         98s
    gpu-operator      nvidia-dcgm-exporter-vgw7p                                        1/1     Running     0         6m18s
    gpu-operator      nvidia-device-plugin-daemonset-mln6z                              1/1     Running     0         6m18s
    gpu-operator      nvidia-device-plugin-validator-sczdk                              0/1     Completed   0         22s
    gpu-operator      nvidia-driver-daemonset-b7flb                                     1/1     Running     0         6m38s
    gpu-operator      nvidia-operator-validator-2v8zk                                   1/1     Running     0         6m18s
    

測試 GPU 叢集

若要測試啟用了 GPU 的叢集,請為 Kubernetes 說明文件中的 cuda-vector-add 範例建立網繭資訊清單,並進行部署。容器將下載、執行並使用 GPU 來執行 CUDA 計算。

  1. 建立一個名為 cuda-vector-add.yaml 的檔案,並新增以下內容:

    apiVersion: v1
    kind: Pod
    metadata:
     name: cuda-vector-add
    spec:
     restartPolicy: OnFailure
     containers:
       - name: cuda-vector-add
         # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
         image: "registry.k8s.io/cuda-vector-add:v0.1"
         resources:
           limits:
             nvidia.com/gpu: 1 # requesting 1 GPU
    
  2. 套用檔案:

    kubectl apply -f cuda-vector-add.yaml
    
  3. 執行:

    kubectl get po cuda-vector-add
    

    輸出類似於:

    cuda-vector-add   0/1     Completed   0          91s
    
  4. 執行:

    kubectl logs cuda-vector-add
    

    輸出類似於:

    [Vector addition of 50000 elements]
    Copy input data from the host memory to the CUDA device
    CUDA kernel launch with 196 blocks of 256 threads
    Copy output data from the CUDA device to the host memory
    Test PASSED
    Done
    

將工作負載叢集部署到 Edge 網站

Tanzu Kubernetes Grid v1.6+ 支援將工作負載叢集部署到 Edge VMware ESXi 主機。如果希望在不同的位置執行多個 Kubernetes 叢集,這些叢集全部由中央管理叢集管理,則可以使用此方法。

拓撲:您可以在具有單一控制平面節點且僅具有一或兩個主機的生產環境中,執行 Edge 工作負載叢集。但是,儘管這使用的 CPU、記憶體和網路頻寬較少,但卻沒有標準生產 Tanzu Kubernetes Grid 叢集的彈性和復原特性。如需詳細資訊,請參閱 VMware Tanzu Edge 解決方案參考架構 1.0

本機登錄:為了盡可能地減少通訊延遲及提高彈性,每個 Edge 叢集應具有自己的本機 Harbor 容器登錄。如需此架構的概觀,請參閱〈架構概觀〉中的容器登錄要安裝本機 Harbor 登錄,請參閱 vSphere 上的部署離線 Harbor 登錄

逾時:此外,當 Edge 工作負載叢集的管理叢集位於遠端的主要資料中心時,您可能需要調整特定的逾時,讓管理叢集有足夠的時間與工作負載叢集機器連線。若要調整這些逾時,請參閱下面的延長 Edge 叢集的逾時以處理較高的延遲

延長 Edge 叢集的逾時以處理更久的延遲

如果您的管理叢集會從遠端來管理在 Edge 網站上執行的工作負載叢集,或管理超過 20 個工作負載叢集,則可以調整特定的逾時,以便叢集 API 不會封鎖或刪除可能暫時離線或需要超過 12 分鐘才能與其遠端管理叢集通訊的機器 (尤其是當您的基礎結構佈建不足時)。

您可以調整三項設定,讓您的 Edge 叢集有額外的時間來與其控制平面進行通訊:

  • MHC_FALSE_STATUS_TIMEOUT:將預設 12m 延長至例如 40m,以防止 MachineHealthCheck 控制器重建機器 (如果其 Ready 條件維持 False 超過 12 分鐘)。如需有關機器健全狀況檢查的詳細資訊,請參閱設定 Tanzu Kubernetes 叢集的機器健全狀況檢查

  • NODE_STARTUP_TIMEOUT:將預設 20m 延長至例如 60m,以防止 MachineHealthCheck 控制器因為新機器啟動時間超過 20 分鐘,被視為狀況不良,而封鎖新機器加入叢集。

  • etcd-dial-timeout-duration:例如,在 capi-kubeadm-control-plane-controller-manager 資訊清單中,將預設 10m 延長到 40s,以阻止管理叢集上的 etcd 用戶端在掃描工作負載叢集上 etcd 的健全狀況時提前失敗。管理叢集會根據它能否與 etcd 連線,作為機器健全狀況的衡量標準。例如:

    1. 在終端機中執行:

      kubectl edit  capi-kubeadm-control-plane-controller-manager -n capi-system
      
      
    2. 變更 --etcd-dial-timeout-duration 的值:

      - args:
           - --leader-elect
           - --metrics-bind-addr=localhost:8080
           - --feature-gates=ClusterTopology=false
           - --etcd-dial-timeout-duration=40s
           command:
           - /manager
           image: projects.registry.vmware.com/tkg/cluster-api/kubeadm-control-plane-controller:v1.0.1_vmware.1
      

此外,您需要注意:

  • capi-kubedm-control-plane-manager:如果它以某種方式與工作負載叢集「分離」,您可能需要將它退回到新節點,以便它可以適當地監控工作負載叢集中的 etcd

  • TKG 中的 Pinniped 組態都會假設工作負載叢集已連線到管理叢集。萬一連線中斷,您應該確定工作負載網繭正在使用管理帳戶或服務帳戶,與 Edge 站台上的 API 伺服器進行通訊。否則,一旦與管理叢集中斷連線,會干擾 Edge 站台,使其無法透過 Pinniped 對其本機工作負載 API 伺服器進行驗證。

check-circle-line exclamation-circle-line close-line
Scroll to top icon