워크로드 클러스터를 특수 하드웨어에 배포

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 연산자를 설치합니다.

  1. GPU 카드가 있는 ESXi 호스트를 vSphere Client를 추가합니다.

  2. PCI 패스스루를 사용하도록 설정하고 GPU ID를 다음과 같이 기록합니다.

    1. vSphere Client에서 GPU 클러스터에서 대상 ESXi 호스트를 선택합니다.
    2. 구성(Configure) > 하드웨어(Hardware) > PCI 디바이스(PCI Devices)를 선택합니다.
    3. 모든 PCI 디바이스(All PCI Devices) 탭을 선택합니다.
    4. 목록에서 대상 GPU를 선택합니다.
    5. 패스스루 전환(Toggle Passthrough)을 클릭합니다.
    6. 일반 정보 에서 디바이스 ID 및 벤더 ID(아래 이미지에 녹색으로 강조 표시됨)를 기록합니다. ID는 동일한 GPU 카드에 대해 동일합니다. 클러스터 구성 파일에는 이러한 파일이 필요합니다.

    PCI 디바이스 목록을 표시하는 vSphere Client 인터페이스입니다. 목록 아래에는 디바이스 ID 및 벤더 ID의 위치가 녹색 상자로 강조 표시됩니다.

  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"
    

    여기서:

    참고

    VM당 하나의 GPU 유형만 사용할 수 있습니다. 예를 들어 단일 VM에서 NVIDIA V100 및 NVIDIA Tesla T4를 둘 다 사용할 수는 없지만 벤더 ID 및 디바이스 ID가 동일한 여러 GPU 인스턴스를 사용할 수 있습니다.

    tanzu CLI는 MachineDeploymentWORKER_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 클러스터의 시간 초과 적용을 참조하십시오.

로컬 VM 템플릿 지정

Edge 워크로드 클러스터가 공유 vCenter 스토리지가 아닌 고유한 격리된 스토리지를 사용하는 경우 로컬 스토리지에서 노드 VM 템플릿 이미지(OVA 파일)를 검색하도록 구성해야 합니다.

참고

tanzu cluster upgrade를 사용하여 로컬 VM 템플릿을 사용하는 Edge 워크로드 클러스터의 Kubernetes 버전을 업그레이드할 수 없습니다. 대신 워크로드 클러스터 업그레이드 항목의 로컬 VM 템플릿으로 Edge 클러스터 업그레이드에 따라 클러스터를 업그레이드합니다.

클러스터의 단일 VM 템플릿 또는 Worker 및 제어부 시스템 배포와 관련된 다른 템플릿을 지정하려면 다음을 수행합니다.

  1. 클러스터 구성 파일을 생성하고 클래스 기반 클러스터 생성에 설명된 2단계 프로세스의 1단계로 클러스터 매니페스트를 생성합니다.

  2. 클러스터에 대한 VM 템플릿이 있는지 확인합니다.

    • TKG에 대해 올바른 Kubernetes 버전이 있어야 합니다.
    • TKr의 spec.osImages 속성과 일치하는 유효한 OVA 버전이 있어야 합니다.
    • 로컬 vCenter로 업로드되고 유효한 인벤토리 경로(예: /dc0/vm/ubuntu-2004-kube-v1.26.8+vmware.1-tkg.1)가 있습니다.
  3. 클러스터 전체 VM 템플릿을 정의하는지 또는 여러 VM 템플릿을 정의하는지에 따라 매니페스트에서 Cluster 개체 규격을 편집합니다.

    • Cluster 전체 VM 템플릿:

      • annotations에서 run.tanzu.vmware.com/resolve-vsphere-template-from-path를 빈 문자열로 설정합니다.
      • spec.topology.variablesvcenter 블록에서 template을 VM 템플릿의 인벤토리 경로로 설정합니다.
      • 예:

        annotations:
          run.tanzu.vmware.com/resolve-vsphere-template-from-path: ""
        ...
        spec:
         topology:
           class: tkg-vsphere-default-v1.0.0
           variables:
           - name: vcenter
             value:
               cloneMode: fullClone
               datacenter: /dc0
               datastore: /dc0/datastore/sharedVmfs-0
               folder: /dc0/vm/folder0
               network: /dc0/network/VM Network
               resourcePool: /dc0/host/cluster0/Resources/rp0
               ...
               template: VM-TEMPLATE
               ...
        

        여기서 VM-TEMPLATE은 클러스터의 VM 템플릿 경로입니다.

    • machineDeployment당 여러 VM 템플릿 수:

      • annotations에서 run.tanzu.vmware.com/resolve-vsphere-template-from-path를 빈 문자열로 설정합니다.
      • variables.overrides에서 spec.topology.workercontrolplane의 각 machineDeployments에 대해 VM 템플릿의 인벤토리 경로에 vcenter을 설정하는 template 줄을 추가합니다.
      • 예:

        annotations:
          run.tanzu.vmware.com/resolve-vsphere-template-from-path: ""
        ...
        spec:
         workers:
           machineDeployments:
           - class: tkg-worker
             metadata:
               annotations:
                 run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=ubuntu
             name: md-1
             replicas: 2
             variables:
               overrides:
               - name: vcenter
                 value:
                   ...
                   datacenter: /dco
                   template: VM-TEMPLATE
                   ...
        

        여기서 VM-TEMPLATEmachineDeployment의 VM 템플릿 경로입니다.

  4. 수정된 구성 파일을 사용하여 클래스 기반 클러스터 생성에 설명된 프로세스의 2단계로 클러스터를 생성합니다.

더 높은 지연 시간을 처리하기 위해 Edge 클러스터에 대한 시간 초과 확장

관리 클러스터가 Edge 사이트에서 실행되는 워크로드 클러스터를 원격으로 관리하거나 20개 이상의 워크로드 클러스터를 관리하는 경우 클러스터 API가 일시적으로 오프라인 상태이거나 원격 관리 클러스터와 통신하는 데 12분 이상 소요될 수 있는 시스템을 차단하거나 제거하지 않도록 특정 시간 초과를 조정할 수 있습니다(특히 인프라가 미프로비저닝된 경우).

Edge 클러스터가 제어부와 통신할 수 있는 추가 시간을 제공하기 위해 조정할 수 있는 세 가지 설정이 있습니다.

  • MHC_FALSE_STATUS_TIMEOUT: Ready 조건이 12분 넘게 False로 유지되는 경우, 가령 기본 12m40m으로 연장하여 MachineHealthCheck 컨트롤러가 시스템을 다시 생성하지 못하도록 합니다. 시스템 상태 점검에 대한 자세한 내용은 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