在叢集裡部署 Kubernetes 本機應用程式

使用 Kubernetes 技術在 IBM Cloud® Kubernetes Service 中部署容器化應用程式。 執行滾動更新和回滾,而不會讓您的使用者停機。

組態最佳實務指南中瞭解有關建立組態檔案的更多資訊。

啟動 Kubernetes 儀表板

透過 IBM Cloud 主控台CLI 存取 Kubernetes 面板,以檢視群集和工作站節點資訊。

開始之前,請確認您擁有適當的 存取角色請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。

從 IBM Cloud 控制台啟動 Kubernetes 儀表板

  1. 登入 IBM Cloud 主控台
  2. 從功能表列,選取您要使用的帳戶。
  3. 功能表功能表圖示,按一下容器 > 群組
  4. 叢集頁面上,按一下您要存取的叢集。
  5. 從叢集詳細資料頁面中,按一下 Kubernetes 儀表板按鈕。

從命令列介面 (CLI) 啟動 Kubernetes 儀表板

CLI 方法可實現自動化和 CI/CD 整合。 開始前請 先安裝 CLI

  1. 取得您的 Kubernetes 登入憑證。

    kubectl config view -o jsonpath='{.users[0].user.auth-provider.config.id-token}'
    
  2. 複製輸出中的 id-token 值。

  3. 啟動代理。

    kubectl proxy
    

    輸出範例

    Starting to serve on 127.0.0.1:8001
    
  4. 登入儀表板。

    1. 請在瀏覽器中導航至以下網址: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 檔案來部署應用程式。

在開始之前,請 開啟儀表板 並驗證您擁有 服務存取角色請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。

部署應用程式

  1. 按一下 + 建立

  2. 選擇部署方法:

    • 選取「指定應用程式詳細資料」,然後輸入相關資料。
    • 請選擇「上傳 YAML 或 JSON 檔案」,以上傳您的應用程式 設定檔
  3. 按一下部署以驗證您的應用程式已成功部署。

使用 CLI 部署應用程式

CLI 方法可提供精確的控制,並實現自動化。 您將建立設定檔,定義應用程式的資源,並可進行版本控制。

開始之前,請安裝 CLI 並驗證您擁有 服務存取角色請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。

部署應用程式

  1. 根據需要建立包含 部署服務入口資源的組態檔案。 進一步瞭解使用 Kubernetes 資源時如何保護個人資訊安全

  2. 套用配置檔。

    kubectl apply -f config.yaml
    
  3. 確認您可以存取您的應用程式。

使用標籤將應用程式部署至特定工作者節點

當您部署應用程式時,應用程式 Pod 會任意地部署至叢集裡的各種工作者節點。 有時,您可能希望限制應用程式 Pod 部署到的工作節點。 例如,您可能希望應用程式 Pod 僅部署到特定工作者節點儲存區中的工作者節點,因為這些工作者節點位於裸機機器上。 若要指定應用程式 Pod 必須部署至其中的工作者節點,請將親緣性規則新增至應用程式部署。

開始之前

若要將應用程式部署到特定的工作節點,

  1. 取得您要將應用程式 Pod 部署至其中的工作者節點儲存區的 ID。

    ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID
    
  2. 列出工作者節點儲存區中的工作者節點,並記下其中一個專用 IP 位址。

    ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    
  3. 說明工作者節點。 在標籤輸出中,請注意工作者節點儲存區 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
    ...
    
  4. 在應用程式部署中,為工作執行程序池 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」。

  5. 套用已更新的部署配置檔。

    kubectl apply -f with-node-affinity.yaml
    
  6. 驗證應用程式 Pod 已部署至正確的工作者節點。

    1. 列出叢集裡的 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 工作節點上。 不需要安裝額外的驅動程式。

部署工作量

  1. 建立 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
  2. 套用 YAML 檔案。 例如:

    kubectl apply -f nvidia-devicequery.yaml
    
  3. 透過篩選具有「nvidia-devicequery」標籤的 Pod,來檢查該工作 Pod。 驗證 STATUSCompleted

    kubectl get pod -A -l 'name in (nvidia-devicequery)'
    

    輸出範例

    NAME                  READY     STATUS      RESTARTS   AGE
    nvidia-devicequery-ppkd4      0/1       Completed   0          36s
    
  4. 說明 Pod,以查看 GPU 裝置外掛程式如何排定 Pod。

    • LimitsRequests 欄位中,查看您所指定的資源限制符合裝置外掛程式自動設定的要求。
    • 在事件中,驗證已將 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
        ...
        ```
    
  5. 若要驗證工作已使用 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。