在集群中部署 Kubernetes 本机应用程序

使用 Kubernetes 技术在 IBM Cloud® Kubernetes Service 中部署容器化应用程序。 执行滚动更新和回滚,用户无需停机。

有关创建配置文件的更多信息,请参阅《 配置最佳实践 》指南。

启动 Kubernetes 仪表板

访问 Kubernetes 控制面板,通过 IBM Cloud 控制台CLI 查看群集和工作节点信息。

开始之前,请确认您拥有适当的 访问角色登录您的账户。 如果适用,请将相应的资源组设定为目标。 设置集群的上下文。

从 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 部署到的工作程序池的标识。

    ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID
    
  2. 列出工作程序池中的工作程序节点,并记下其中一个 Private IP 地址。

    ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    
  3. 描述工作程序节点。 在 Labels 输出中,记下工作程序池标识标签 ibm-cloud.kubernetes.io/worker-pool-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. 在应用部署中为 worker 池 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-idkey,而 <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 不再安装 NVIDIA GPU 驱动程序,工作节点上的 GPU 从 Kubernetes 版本 1.36 开始。 如果计划在 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 操作员安装指南安装所需组件:

  • 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 组件
    组件 描述
    元数据和标签名称 请为该任务输入名称和标签,并在文件的元数据以及 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。 验证 STATUS 是否为 Completed

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

    示例输出

    NAME                  READY     STATUS      RESTARTS   AGE
    nvidia-devicequery-ppkd4      0/1       Completed   0          36s
    
  4. 对 pod 执行 describe 命令,以查看 GPU 设备插件是如何安排 pod 的。

    • LimitsRequests 字段中,确保指定的资源限制与设备插件自动设置的请求相匹配。
    • 在 Events 中,验证是否已将 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。