在叢集裡部署 Kubernetes 本機應用程式
使用 Kubernetes 技術在 IBM Cloud® Kubernetes Service 中部署容器化應用程式。 執行滾動更新和回滾,而不會讓您的使用者停機。
在 組態最佳實務指南中瞭解有關建立組態檔案的更多資訊。
啟動 Kubernetes 儀表板
透過 IBM Cloud 主控台 或 CLI 存取 Kubernetes 面板,以檢視群集和工作站節點資訊。
開始之前,請確認您擁有適當的 存取角色。 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
從 IBM Cloud 控制台啟動 Kubernetes 儀表板
- 登入 IBM Cloud 主控台。
- 從功能表列,選取您要使用的帳戶。
- 從
,按一下容器 > 群組。
- 在叢集頁面上,按一下您要存取的叢集。
- 從叢集詳細資料頁面中,按一下 Kubernetes 儀表板按鈕。
從命令列介面 (CLI) 啟動 Kubernetes 儀表板
CLI 方法可實現自動化和 CI/CD 整合。 開始前請 先安裝 CLI。
-
取得您的 Kubernetes 登入憑證。
kubectl config view -o jsonpath='{.users[0].user.auth-provider.config.id-token}' -
複製輸出中的 id-token 值。
-
啟動代理。
kubectl proxy輸出範例
Starting to serve on 127.0.0.1:8001 -
登入儀表板。
- 請在瀏覽器中導航至以下網址:URL:
http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ ``` 2. 在登入頁面上選擇**令牌**驗證方法。 3. 將 **id-token** 的值貼上至「**Token**」欄位,然後點擊「**登入**」。
使用 CTRL+C 離開 proxy 指令。 再次執行 kubectl proxy 以重新啟動儀表板。
使用 Kubernetes 儀表板部署應用程式
透過儀表板輸入組態詳細資訊或上傳 YAML 檔案來部署應用程式。
在開始之前,請 開啟儀表板 並驗證您擁有 服務存取角色。 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
部署應用程式
-
按一下 + 建立。
-
選擇部署方法:
- 選取「指定應用程式詳細資料」,然後輸入相關資料。
- 請選擇「上傳 YAML 或 JSON 檔案」,以上傳您的應用程式 設定檔。
-
按一下部署以驗證您的應用程式已成功部署。
使用 CLI 部署應用程式
CLI 方法可提供精確的控制,並實現自動化。 您將建立設定檔,定義應用程式的資源,並可進行版本控制。
開始之前,請安裝 CLI 並驗證您擁有 服務存取角色。 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
部署應用程式
使用標籤將應用程式部署至特定工作者節點
當您部署應用程式時,應用程式 Pod 會任意地部署至叢集裡的各種工作者節點。 有時,您可能希望限制應用程式 Pod 部署到的工作節點。 例如,您可能希望應用程式 Pod 僅部署到特定工作者節點儲存區中的工作者節點,因為這些工作者節點位於裸機機器上。 若要指定應用程式 Pod 必須部署至其中的工作者節點,請將親緣性規則新增至應用程式部署。
開始之前
若要將應用程式部署到特定的工作節點,
-
取得您要將應用程式 Pod 部署至其中的工作者節點儲存區的 ID。
ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID -
列出工作者節點儲存區中的工作者節點,並記下其中一個專用 IP 位址。
ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID -
說明工作者節點。 在標籤輸出中,請注意工作者節點儲存區 ID 標籤
ibm-cloud.kubernetes.io/worker-pool-id。本主題中的步驟使用工作者節點儲存區 ID,僅將應用程式 Pod 部署至該工作者節點儲存區內的工作者節點。 若要使用不同的標籤將應用程式 Pod 部署至特定工作者節點,則就要注意此標籤。 例如,若只要將應用程式 Pod 部署至特定專用 VLAN 上的工作者節點,請使用
privateVLAN=標籤。kubectl describe node <worker_node_private_IP>輸出範例
NAME: 10.xxx.xx.xxx Roles: <none> Labels: arch=amd64 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=b3c.4x16.encrypted beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-south failure-domain.beta.kubernetes.io/zone=dal10 ibm-cloud.kubernetes.io/encrypted-docker-data=true ibm-cloud.kubernetes.io/ha-worker=true ibm-cloud.kubernetes.io/iaas-provider=softlayer ibm-cloud.kubernetes.io/machine-type=b3c.4x16.encrypted ibm-cloud.kubernetes.io/sgx-enabled=false ibm-cloud.kubernetes.io/worker-pool-id=00a11aa1a11aa11a1111a1111aaa11aa-11a11a ibm-cloud.kubernetes.io/worker-version=1.36_1534 kubernetes.io/hostname=10.xxx.xx.xxx privateVLAN=1234567 publicVLAN=7654321 Annotations: node.alpha.kubernetes.io/ttl=0 ... -
在應用程式部署中,為工作執行程序池 ID 標籤 新增一則親和性規則。
範例 YAML
apiVersion: apps/v1 kind: Deployment metadata: name: with-node-affinity spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: ibm-cloud.kubernetes.io/worker-pool-id operator: In values: - <worker_pool_ID> ...在範例 YAML 文件的 「親和性」 部分中,
ibm-cloud.kubernetes.io/worker-pool-id代表「key」,而<worker_pool_ID>則代表「value」。 -
套用已更新的部署配置檔。
kubectl apply -f with-node-affinity.yaml -
驗證應用程式 Pod 已部署至正確的工作者節點。
- 列出叢集裡的 Pod。
kubectl get pods -o wide ``` 輸出範例 ```sh {: screen} NAME READY STATUS RESTARTS AGE IP NODE cf-py-d7b7d94db-vp8pq 1/1 Running 0 15d 172.30.xxx.xxx 10.176.48.78 ``` 2. 在輸出中,識別應用程式的 Pod。 記下 Pod 所在工作者節點的 **NODE** 專用 IP 位址。 在前一個範例輸出中,應用程式 Pod `cf-py-d7b7d94db-vp8pq` 位於具有 IP 位址 `10.xxx.xx.xxx` 的工作者節點上。 3. 列出您在應用程式部署內所指定工作者節點儲存區中的工作者節點。 ```sh {: pre} ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID ``` 輸出範例 ```sh {: screen} ID Public IP Private IP Machine Type State Status Zone Version kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w7 169.xx.xxx.xxx 10.176.48.78 b3c.4x16 normal Ready dal10 1.8.6_1504 kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w8 169.xx.xxx.xxx 10.176.48.83 b3c.4x16 normal Ready dal10 1.8.6_1504 kube-dal12-crb20b637238bb471f8b4b8b881bbb4962-w9 169.xx.xxx.xxx 10.176.48.69 b3c.4x16 normal Ready dal12 1.8.6_1504 ``` 如果您已根據另一個因素建立應用程式親緣性規則,請改為取得該值。 例如,若要驗證應用程式 Pod 是否已部署至特定 VLAN 上的工作節點,請執行 `ibmcloud ks worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID`,以查看該工作節點所處的 VLAN。 {: tip} 4. 在輸出中,驗證具有您在前一個步驟中所識別之專用 IP 位址的工作者節點已部署在此工作者節點儲存區。
在 NVIDIA GPU 機器上部署應用程式
如果您具有 GPU 機型,則可以加快運算密集工作負載 (例如 AI、機器學習、推理等) 所需的處理時間。
從 Kubernetes 版本開始的重要驅動程式變更 1.36:IBM Cloud Kubernetes Service 不再在從 Kubernetes 版本 1.36 開始使用 GPU 的工作節點上安裝 NVIDIA GPU 驅動程式。 如果您計劃在 1.36 或更新版本的集群上執行 GPU 工作負載,您必須在自己的工作節點上管理 GPU 驅動程式的安裝和生命週期。 對於執行 1.35 或更早版本的集群,IBM- 提供的 GPU 驅動程式仍然可用。 如需遷移指引,請參閱 遷移至自行管理的 NVIDIA GPU 驅動 程式。
在下列步驟中,您將學習如何部署需要 GPU 的工作負載。 不過,您也可以部署那些無需在 GPU 和 CPU 之間處理工作負載的應用程式。
您亦可透過 Kubernetes 此示範嘗試執行數學密集型工作負載,例如機器 TensorFlow 學習框架。
必要條件
開始之前
-
建立使用 GPU 特性的 叢集 或工作者節點儲存區。 請記住,設定裸機機器可能需要多個營業日才能完成。 如需可用特性的清單,請參閱下列鏈結。
-
請確保您已被指派一個 服務存取角色, 該角色會授予相應的「Kubernetes」RBAC 角色,以便您能夠在叢集中管理 Kubernetes 資源。
適用於 Kubernetes 版本 1.36 及更新版本:您必須自行安裝和管理 NVIDIA GPU 驅動程式堆疊。 IBM Cloud Kubernetes Service 不再在工作節點上提供預先安裝的 GPU 驅動程式。 按照 NVIDIA GPU Operator 安裝指南安裝所需元件:
- NVIDIA 核心驅動程式
- 容器執行時元件 (例如 nvidia-container-toolkit)
- Kubernetes 裝置外掛程式
在安裝驅動程式之前,請求 GPU 的 pod 將維持在 Pending 狀態。 在節點上有相容的驅動程式可用後,它們會自動過渡到 Running。
對於 Kubernetes 版本 1.35 及更早版本:IBM- 提供的 GPU 驅動程式會自動安裝在 GPU 工作節點上。 不需要安裝額外的驅動程式。
部署工作量
-
建立 YAML 檔案。 在此範例中,
Job的 YAML 檔案會透過建立一個短暫存在的 Pod 來管理類似批次的工作負載,該 Pod 會持續運行直至指令執行完畢並成功終止。對於 GPU 工作負載,您必須在工作 YAML 檔案中指定
resources: limits: nvidia.com/gpu欄位。apiVersion: batch/v1 kind: Job metadata: name: nvidia-devicequery labels: name: nvidia-devicequery spec: template: metadata: labels: name: nvidia-devicequery spec: containers: - name: nvidia-devicequery image: nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04 imagePullPolicy: IfNotPresent resources: limits: nvidia.com/gpu: 2 restartPolicy: Never了解您的 YAML 組件 元件 說明 meta 資料及標籤名稱 請輸入工作名稱與標籤,並在檔案的元資料及 spec template的元資料中使用相同的名稱。 例如,nvidia-devicequery。containers.image提供容器是其執行中實例的映像檔。 在此範例中,該值設為使用 DockerHub CUDA 裝置查詢映像檔: nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04。containers.imagePullPolicy若要僅在該映像目前未存在於工作節點時才下載新映像,請指定 IfNotPresent``。resources.limits對於 GPU 機器,您必須指定資源限制。 Kubernetes 裝置外掛程式會將預設資源請求設定為符合該限制。
- 您必須將金鑰指定為
nvidia.com/gpu。 - 輸入您要求的 GPU 總數,例如
2。 請注意,容器 Pod 不共用 GPU,且 GPU 不能過度確定。 例如,如果您只有 1 部mg1c.16x128機器,則在該機器中您只有 2 個 GPU,且最多可以指定2。
- 您必須將金鑰指定為
-
套用 YAML 檔案。 例如:
kubectl apply -f nvidia-devicequery.yaml -
透過篩選具有「
nvidia-devicequery」標籤的 Pod,來檢查該工作 Pod。 驗證 STATUS 為 Completed。kubectl get pod -A -l 'name in (nvidia-devicequery)'輸出範例
NAME READY STATUS RESTARTS AGE nvidia-devicequery-ppkd4 0/1 Completed 0 36s -
說明 Pod,以查看 GPU 裝置外掛程式如何排定 Pod。
- 在
Limits及Requests欄位中,查看您所指定的資源限制符合裝置外掛程式自動設定的要求。 - 在事件中,驗證已將 Pod 指派給 GPU 工作者節點。
kubectl describe pod nvidia-devicequery-ppkd4 ``` 輸出範例 ```sh {: screen} NAME: nvidia-devicequery-ppkd4 Namespace: default ... Limits: nvidia.com/gpu: 1 Requests: nvidia.com/gpu: 1 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 1m default-scheduler Successfully assigned nvidia-devicequery-ppkd4 to 10.xxx.xx.xxx ... ``` - 在
-
若要驗證工作已使用 GPU 來運算其工作負載,您可以檢查日誌。
kubectl logs nvidia-devicequery-ppkd4輸出範例
/cuda-samples/sample Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "Tesla P100-PCIE-16GB" CUDA Driver Version / Runtime Version 11.4 / 11.7 CUDA Capability Major/Minor version number: 6.0 Total amount of global memory: 16281 MBytes (17071734784 bytes) (056) Multiprocessors, (064) CUDA Cores/MP: 3584 CUDA Cores GPU Max Clock rate: 1329 MHz (1.33 GHz) Memory Clock rate: 715 Mhz Memory Bus Width: 4096-bit L2 Cache Size: 4194304 bytes Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384) Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total shared memory per multiprocessor: 65536 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 2 copy engine(s) Run time limit on kernels: No Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Enabled Device supports Unified Addressing (UVA): Yes Device supports Managed Memory: Yes Device supports Compute Preemption: Yes Supports Cooperative Kernel Launch: Yes Supports MultiDevice Co-op Kernel Launch: Yes Device PCI Domain ID / Bus ID / location ID: 0 / 175 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 11.4, CUDA Runtime Version = 11.7, NumDevs = 1 Result = PASS在此範例中,您看到使用 GPU 來執行工作,因為 GPU 已在工作者節點中排程。 如果限制設為 2,則只會顯示 2 個 GPU。
現在您已部署測試 GPU 工作負載,您可能想要設定叢集以執行依賴於 GPU 處理的工具,例如 IBM Maximo Visual Inspection。
遷移到自我管理的 NVIDIA GPU 驅動程式
有關在升級至 Kubernetes 版本 1.36 時,從 IBM- 提供的 GPU 驅動程式轉換為自我管理驅動程式的詳細指引,請參閱 轉換為自我管理的 NVIDIA GPU 驅動程式 Kubernetes 1.36。