동적 스토리지

이 항목에서는 영구 볼륨 및 스토리지 클래스를 사용하여 TKG(Tanzu Kubernetes Grid) 워크로드 클러스터에 동적 스토리지를 구현하는 방법을 설명합니다.

개요: PersistentVolume, PersistentVolumeClaim, and StorageClass

Kubernetes 클러스터에서 PV(PersistentVolume) 개체는 포드 수명 주기의 영향을 받지 않는 클러스터 포드에 공유 스토리지를 제공합니다. 스토리지는 포드가 기본 스토리지에 액세스하는 양과 방법을 정의하는 PVC(PersistentVolumeClaim) 개체를 통해 PV에 프로비저닝됩니다. 자세한 내용은 Kubernetes 설명서에서 영구 볼륨을 참조하십시오.

클러스터 관리자는 클러스터 사용자가 서로 다른 스토리지 유형 및 규칙을 사용하여 PVC 및 PV 개체를 동적으로 생성할 수 있도록 하는 StorageClass 개체를 정의할 수 있습니다. Tanzu Kubernetes Grid는 사용자가 턴키 환경에서 영구 스토리지를 프로비저닝할 수 있도록 하는 기본 StorageClass 개체도 제공합니다.

StorageClass 개체에는 EV를 프로비저닝하는 내부 또는 외부 서비스 플러그인을 식별하는 provisioner 필드와 Kubernetes 스토리지 클래스를 인프라 수준에서 정의된 스토리지 옵션(예: vSphere VM 스토리지 정책)과 연결되는 parameters 필드가 포함도어 있습니다. 자세한 내용은 Kubernetes 설명서에서 스토리지 클래스를 참조하십시오.

지원되는 스토리지 유형

Tanzu Kubernetes Grid는 Kubernetes 내부("트리 내") 또는 외부("트리 외부") 플러그인에서 프로비저닝된 다양한 스토리지 유형에 대해 StorageClass 개체를 지원합니다.

스토리지 유형

• vSphere CNS(클라우드 네이티브 스토리지)
• Amazon EBS
• Azure Disk
• Azure File
• iSCSI
• NFS

참고

vSphere CSI는 스토리지 DRS를 지원하지 않으며, vSphere CSI 설명서의 vSphere 컨테이너 스토리지 플러그인이 지원하는 vSphere 기능에 설명된 조건으로 Storage vMotion을 지원합니다.

vSphere CSI가 조건과 함께 Storage vMotion을 지원하는 자세한 내용은 CSI 문서를 참조하십시오.

vSphere CNS, Amazon EBS, Azure Disk 기본 스토리지 클래스는 기본 스토리지 클래스를 참조하십시오.

외부 프로비저닝

TKG v2.4에서 모든 기본 스토리지 클래스는 "트리 내" 프로비저닝이 아닌 외부("트리 외부") 스토리지 프로비저닝을 사용합니다.

• 스토리지 클래스에는 코어 Kubernetes가 함께 제공되지 않습니다.
• StorageClass 개체 provisioner 값에는 kubernetes.io 접두사가 지정되지 않습니다.
• 프로비저너는 외부 스토리지의 CSI(Container Storage Interface) 기준을 따릅니다.
• 이전 버전의 TKG에서 배포한 기본 스토리지 클래스가 있는 워크로드 클러스터에는 트리 내 스토리지 프로비저닝이 있을 수 있습니다. 스토리지 클래스를 사용하여 영구 볼륨 생성을 참조하십시오.

기본 스토리지 클래스

Tanzu Kubernetes Grid는 워크로드 클러스터 사용자가 클러스터 관리자에 의해 생성된 StorageClass 개체 없이도 턴키 환경에서 인프라에 영구 스토리지를 프로비저닝할 수 있도록 하는 기본 StorageClass 개체를 제공합니다.

ENABLE_DEFAULT_STORAGE_CLASS 변수는 워크로드 클러스터에 대해 기본 스토리지 클래스를 활성화할 수 있도록 tanzu cluster create의 --file 옵션으로 전달된 클러스터 구성 파일에 기본적으로 true로 설정됩니다.

중요

기본 스토리지 클래스 정의를 수정하지 마십시오. 스토리지 클래스를 사용자 지정하려면 TKG에서 생성된 기본 개체를 수정하는 대신 다른 name을 사용하여 새 StorageClass 정의를 생성합니다.

Tanzu Kubernetes Grid 기본 스토리지 클래스 정의는 다음과 같습니다.

vSphere CNS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
  storagePolicyName: optional

Kubernetes 설명서의 vSphere CSI 스토리지 클래스 매개 변수를 참조하십시오.

Amazon EBS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com

AWS 설명서의 Amazon EBS CSI 드라이버 스토리지 클래스 매개 변수를 참조하십시오.

Azure Disk

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: default
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: disk.csi.azure.com
parameters:
  kind: Managed
  storageaccounttype: Standard_LRS
  cachingmode: ReadOnly
volumeBindingMode: WaitForFirstConsumer

Azure 설명서의 Azure Disk CSI 드라이버 스토리지 클래스 매개 변수를 참조하십시오.

Azure File

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: file.csi.azure.com
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS

Kubernetes 설명서의 Azure File 스토리지 클래스 매개 변수를 참조하십시오.

CNS 설정 및 스토리지 정책 생성(vSphere)

vSphere 관리자는 Tanzu Kubernetes Grid 클러스터 사용자의 니즈에 따라 vSphere CNS를 설정하고 VMDK(가상 디스크) 스토리지에 대한 스토리지 정책을 생성할 수 있습니다.

다음과 같이 Kubernetes 클러스터의 영구 스토리지에 vSAN 또는 로컬 VMFS(Virtual Machine File System)를 사용할 수 있습니다.

vSAN 스토리지:

vSphere Client vSAN 스토리지에 대한 스토리지 정책을 생성하려면 홈(Home) > 정책 및 프로필(Policies and Profiles) > VM 스토리지 정책(VM Storage Policies)으로 이동한 후 생성(Create)을 클릭하여 VM 스토리지 정책 생성(Create VM Storage Policy) 마법사를 시작합니다.

vSphere 설명서의 스토리지 정책 생성에 있는 지침을 따르십시오. 다음을 확인하십시오.

• 정책 구조(Policy structure) 페이지의 데이터스토어별 규칙(Datastore specific rules)에서 "vSAN" 스토리지에 규칙 사용(Enable rules for “vSAN” storage)을 선택합니다.
• 다른 창을 구성하거나 필요에 따라 기본값을 수락합니다.
• 참조할 스토리지 정책 이름을 StorageClass 개체에 storagePolicyName 값으로 기록합니다.

로컬 VMFS 스토리지:

로컬 스토리지에 대한 스토리지 정책을 생성하려면 스토리지에 태그를 적용하고 다음과 같이 태그를 기반으로 스토리지 정책을 생성합니다.

1. 최상단 vSphere 메뉴에서 태그 및 사용자 지정 특성(Tags & Custom Attributes)을 선택합니다.

2. 태그(Tags) 창에서 범주(Categories)를 선택하고 새로 만들기(New)를 클릭합니다.

3. 범주 이름을 입력합니다(예: tkg-storage). 확인란을 사용하여 데이터센터(Datacenter) 및 스토리지 개체(폴더 및 데이터스토어)와 연결합니다. 생성(Create)을 클릭합니다.

4. 최상위 스토리지(Storage) 보기에서 VMFS 볼륨을 선택하고 요약(Summary) 창에서 태그(Tags) > 할당(Assign)…을 클릭합니다.

5. 태그 할당(Assign Tag) 팝업에서 태그 할당(Assign Tag)을 클릭합니다.

6. 태그 생성(Create Tag) 팝업에서 태그에 tkg-storage-ds1과 같은 이름을 지정하고 생성한 범주를 할당합니다. 확인을 클릭합니다.

7. 태그 할당(Assign Tag)에서 태그를 선택하고 할당(Assign)을 클릭합니다.

8. 최상위 vSphere에서 VM 스토리지 정책(VM Storage Policies) > 스토리지 정책 생성(Create a Storage Policy)을 선택합니다. 구성 마법사가 시작됩니다.

9. 이름 및 설명(Name and description) 창에서 스토리지 정책의 이름을 입력합니다. 참조할 스토리지 정책 이름을 StorageClass 개체에 storagePolicyName 값으로 기록합니다.

10. 정책 구조(Policy structure) 창의 데이터스토어별 규칙(Datastore specific rules)에서 태그 기반 배치 규칙 사용(Enable tag-based placement rules)을 선택합니다.

11. 태그 기반 배치(Tag based placement) 창에서 태그 규칙 추가(Add Tag Rule)를 클릭하고 다음을 구성합니다.

    • 태그 범주(Tag category): 범주 이름 선택
    • 사용 옵션(Usage option): Use storage tagged with
    • 태그(Tags): 태그 이름 찾아보기 및 선택

12. 다른 창을 확인하고 구성하거나 필요에 따라 기본값을 수락한 다음 검토 후 마침(Review and finish)을 클릭합니다. 마침(Finish)을 클릭하여 스토리지 정책을 생성합니다.

사용자 지정 스토리지 클래스 생성

클러스터 관리자는 다음과 같이 새 스토리지 클래스를 생성할 수 있습니다.

1. vSphere Kubernetes StorageClass의 기준으로 사용할 VM 스토리지 정책을 선택하거나 생성합니다.
   • vSphere 관리자는 위의 스토리지 정책 생성(vSphere)에 따라 스토리지 정책을 생성할 수 있습니다.
2. provisioner, parameters 및 기타 옵션을 사용하여 StorageClass 구성 .yaml을 생성합니다.
   • vSphere에서 storagePolicyName 매개 변수를 vSphere 스토리지 정책 이름에 큰따옴표로 묶어 Kubernetes 스토리지 클래스를 vSphere 스토리지 정책과 연결합니다.
3. 파일을 kubectl create -f로 전달합니다.
4. kubectl describe storageclass <storageclass metadata.name>을 실행하여 스토리지 클래스를 확인합니다.

예를 들어 Kubernetes 설명서의 동적 프로비저닝 사용을 참조하십시오.

vSphere CSI 정보 및 리소스에 대한 자세한 내용은 VMware vSphere 컨테이너 스토리지 플러그인 설명서를 참조하십시오.

클러스터에서 사용자 지정 스토리지 클래스 사용

위에 설명된 기본 스토리지 클래스 중 하나를 사용하지 않는 클러스터 노드에 영구 스토리지를 프로비저닝하기 위해 클러스터 사용자는 다음과 같이 포드 구성에 사용자 지정 스토리지 클래스를 포함합니다.

1. kubectl의 컨텍스트를 클러스터로 설정합니다. 예:

   kubectl config use-context my-cluster-admin@my-cluster
   

2. 스토리지 클래스를 선택하거나 생성합니다.

   • 선택:
     • 사용 가능한 스토리지 클래스를 나열하려면 kubectl get storageclass를 실행합니다.
   • 생성
     • 클러스터 관리자는 위의 사용자 지정 스토리지 클래스 생성을 수행하여 스토리지 클래스를 생성할 수 있습니다.

3. PVC 및 해당 PV를 생성합니다.

   1. StorageClass 개체의 metadata.name 값으로 설정된 spec.storageClassName으로 PersistentVolumeClaim 구성 .yaml을 생성합니다. 예를 들어 Kubernetes 설명서의 동적 프로비저닝 사용을 참조하십시오.
   2. 파일을 kubectl create -f로 전달합니다.
   3. kubectl describe pvc <pvc metadata.name>을 실행하여 PVC를 확인합니다.
   4. PV는 PVC를 사용하여 자동으로 생성됩니다. kubectl describe pvc 출력에 있는 이름을 Successfully provisioned volume 뒤에 기록합니다.
   5. kubectl describe pv <pv unique name>을 실행하여 PV를 확인합니다.

4. PVC를 사용하려면 포드를 생성합니다.

   1. spec.volumes을 persistentVolumeClaim.claimName 아래에 PVC를 포함하도록 설정하는 Pod 구성 .yaml을 생성합니다. 예를 들어 vSphere 컨테이너 스토리지 플러그인 설명서의 vSphere 컨테이너 스토리지 플러그인을 사용하여 블록 볼륨 프로비저닝을 참조하십시오.
   2. 파일을 kubectl create -f로 전달합니다.
   3. kubectl get pod <pod metadata.name>을 실행하여 포드를 확인합니다.

vSphere CSI에 볼륨 확장 사용(vSphere 7)

워크로드 클러스터에서 사용하는 vSphere CSI 스토리지에 대해 볼륨 확장을 사용하도록 설정하려면 클러스터의 CSI 프로세스에 csi-resizer 사이드카 포드를 추가해야 합니다.

워크로드 클러스터의 CSI 구성은 Kubernetes 암호로 인코딩됩니다. 이 절차에서는 CSI 구성 암호를 수정하여 csi-resizer 프로세스를 추가합니다. 암호에 stringData 정의를 추가하여 암호의 이전 CSI 구성 데이터를 포함하는 두 개의 인코딩된 구성 데이터 문자열 values.yaml과 csi-resizer 포드를 배포하는 새로운 overlays.yaml 문자열을 결합합니다.

참고

온라인 볼륨 확장은 업데이트 2를 vSphere 7.0에서 지원됩니다. 자세한 내용은 vSphere with Tanzu 볼륨 확장을 참조하십시오.

1. 변경 중인 워크로드 클러스터의 관리 클러스터에 로그인하고 워크로드 클러스터의 이름을 검색해야 하는 경우 tanzu cluster list를 실행합니다.

2. 레이블 선택기 vsphere-csi 및 클러스터 이름을 사용하여 워크로드 클러스터의 CSI 암호 이름을 검색합니다.

   $ kubectl get secret \
     -l tkg.tanzu.vmware.com/cluster-name=NAME_OF_WORKLOAD_CLUSTER \
     -l tkg.tanzu.vmware.com/addon-name=vsphere-csi
   my-wc-vsphere-csi-secret
   

3. 암호 컨텐츠의 백업을 YAML 형식으로 vsphere-csi-secret.yaml에 저장합니다.

   kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
   

4. data.values 값을 base64로 일반 YAML로 디코딩하여 암호의 현재 컨텐츠를 다시 출력합니다.

   $ kubectl get secret my-wc-vsphere-csi-secret -o jsonpath={.data.values\\.yaml} | base64 -d
   
   #@data/values
   #@overlay/match-child-defaults missing_ok=True
   ---
   vsphereCSI:
   CSIAttacherImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/csi-attacher
     tag: v3.0.0_vmware.1
     pullPolicy: IfNotPresent
   vsphereCSIControllerImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/vsphere-block-csi-driver
     tag: v2.1.1_vmware.1
     pullPolicy: IfNotPresent
   livenessProbeImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/csi-livenessprobe
     tag: v2.1.1_vmware.1
     pullPolicy: IfNotPresent
   vsphereSyncerImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/volume-metadata-syncer
     tag: v2.1.1_vmware.1
     pullPolicy: IfNotPresent
   CSIProvisionerImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/csi-provisioner
     tag: v2.0.0_vmware.1
     pullPolicy: IfNotPresent
   CSINodeDriverRegistrarImage:
     repository: projects.registry.vmware.com/tkg
     path: csi/csi-node-driver-registrar
     tag: v2.0.1_vmware.1
     pullPolicy: IfNotPresent
   namespace: kube-system
   clusterName: wc-1
   server: 10.170.104.114
   datacenter: /dc0
   publicNetwork: VM Network
   username: <MY-VSPHERE-USERNAME>
   password: <MY-VSPHERE-PASSWORD>
   
   

5. 편집기에서 vsphere-csi-secret.yaml을 열고 다음을 수행하여 아래 코드처럼 보이게 합니다.

   1. 긴 문자열인 values.yaml의 기존 정의를 삭제합니다.
   2. 첫 번째 줄 뒤에 stringData를 정의하는 줄을 추가하고 values.yaml을 들여쓰기하여 첫 번째 요소로 만듭니다.
   3. 이전 단계에서 data.values 출력을 복사합니다.
   4. 세 번째 줄 뒤에 data.values 출력에 붙여 넣고 values.yaml 값으로 들여쓰기합니다.
   5. values.yaml 정의 바로 아래에 아래와 같이 overlays.yaml에 다른 stringData 정의를 추가합니다. 파일의 다른 정의는 수정하지 마십시오.

   apiVersion: v1
   stringData:
     values.yaml: |
       #@data/values
       #@overlay/match-child-defaults missing_ok=True
       ---
       vsphereCSI:
         CSIAttacherImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/csi-attacher
           tag: v3.0.0_vmware.1
           pullPolicy: IfNotPresent
         vsphereCSIControllerImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/vsphere-block-csi-driver
           tag: v2.1.1_vmware.1
           pullPolicy: IfNotPresent
         livenessProbeImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/csi-livenessprobe
           tag: v2.1.1_vmware.1
           pullPolicy: IfNotPresent
         vsphereSyncerImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/volume-metadata-syncer
           tag: v2.1.1_vmware.1
           pullPolicy: IfNotPresent
         CSIProvisionerImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/csi-provisioner
           tag: v2.0.0_vmware.1
           pullPolicy: IfNotPresent
         CSINodeDriverRegistrarImage:
           repository: projects.registry.vmware.com/tkg
           path: csi/csi-node-driver-registrar
           tag: v2.0.1_vmware.1
           pullPolicy: IfNotPresent
         namespace: kube-system
         clusterName: wc-1
         server: 10.170.104.114
         datacenter: /dc0
         publicNetwork: VM Network
         username: <MY-VSPHERE-USERNAME>
         password: <MY-VSPHERE-PASSWORD>
     overlays.yaml: |
       #@ load("@ytt:overlay", "overlay")
       #@overlay/match by=overlay.subset({"kind": "Deployment", "metadata": {"name": "vsphere-csi-controller"}})
       ---
       spec:
         template:
           spec:
             containers:
             #@overlay/append
               - name: csi-resizer
                 image: projects.registry.vmware.com/tkg/kubernetes-csi_external-resizer:v1.0.0_vmware.1
                 args:
                   - "--v=4"
                   - "--timeout=300s"
                   - "--csi-address=$(ADDRESS)"
                   - "--leader-election"
                 env:
                   - name: ADDRESS
                     value: /csi/csi.sock
                 volumeMounts:
                   - mountPath: /csi
                     name: socket-dir
   kind: Secret
   ...
   

6. kubectl apply를 실행하여 수정된 정의로 클러스터의 암호를 업데이트하고 csi-controller 포드를 다시 생성합니다.

   kubectl apply -f vsphere-csi-secret.yaml
   

7. vsphere-csi-controller 및 외부 리사이저가 클러스터에서 작동하는지 확인하려면 다음을 수행합니다.

   1. 6개의 정상 포드가 있는 워크로드 클러스터에서 vsphere-csi-controller가 실행 중인지 확인합니다.

      $ kubectl get pods -n kube-system -l app=vsphere-csi-controller
      NAME                                     READY   STATUS    RESTARTS   AGE
      vsphere-csi-controller-<ID-HASH>   6/6     Running   0          6m49s
      

   2. vsphere-csi-controller의 로그를 확인하여 외부 리사이저가 시작되었는지 확인합니다.

      $ kubectl logs vsphere-csi-controller-<ID-HASH> -n kube-system -c csi-resizer
      I0308 23:44:45.035254       1 main.go:79] Version : v1.0.0-0-gb22717d
      I0308 23:44:45.037856       1 connection.go:153] Connecting to unix:///csi/csi.sock
      I0308 23:44:45.038572       1 common.go:111] Probing CSI driver for readiness
      I0308 23:44:45.040579       1 csi_resizer.go:77] CSI driver name: "csi.vsphere.vmware.com"
      W0308 23:44:45.040612       1 metrics.go:142] metrics endpoint will not be started because `metrics-address` was not specified.
      I0308 23:44:45.042184       1 controller.go:117] Register Pod informer for resizer csi.vsphere.vmware.com
      I0308 23:44:45.043182       1 leaderelection.go:243] attempting to acquire leader lease  kube-system/external-resizer-csi-vsphere-vmware-com...
      I0308 23:44:45.073383       1 leaderelection.go:253] successfully acquired lease kube-system/external-resizer-csi-vsphere-vmware-com
      I0308 23:44:45.076028       1 leader_election.go:172] new leader detected, current leader: vsphere-csi-controller-87d7dcf48-jcht2
      I0308 23:44:45.079332       1 leader_election.go:165] became leader, starting
      I0308 23:44:45.079638       1 controller.go:241] Starting external resizer csi.vsphere.vmware.com
      

온라인 또는 오프라인 모드에서 vSphere CSI 스토리지 볼륨을 확장하는 방법에 대한 자세한 내용은 vSphere with Tanzu 볼륨 확장을 참조하십시오.

토폴로지 인식 볼륨 프로비저닝(vSphere)

독립형 관리 클러스터에서 생성된 워크로드 클러스터의 경우 토폴로지 인식 로컬 스토리지 볼륨 프로비저닝을 구성할 수 있습니다. 토폴로지 인식 볼륨 프로비저닝을 사용하면 볼륨을 동적으로 프로비저닝할 때 Kubernetes가 지능적인 결정을 내릴 수 있습니다. Kubernetes는 포드에 대한 볼륨을 프로비저닝하기에 가장 좋은 위치에 스케줄러 입력을 가져옵니다.

가용성 영역 생성(AZ):

1. 여러 가용성 영역에 클러스터 실행 지침에 따라 vSphere에서 다음을 생성합니다.

   1. 호스트 그룹 및 VM 그룹을 추가합니다.

   2. 호스트 그룹의 VM 그룹을 제한하는 규칙을 추가합니다.

      하나의 VM 그룹 및 호스트 그룹이 워크로드 클러스터에서 AZ를 실행하는 데 사용됩니다.

      참고

      제한 규칙은 로컬 볼륨 구성에만 적용됩니다. 여러 가용성 영역에 배포하는 경우에는 제한 규칙을 생성할 필요가 없습니다.

   3. 독립형 관리 클러스터에서 사용자 지정 리소스 정의(CRD) VSphereFailureDomain 및 VSphereDeploymentZone을 배포합니다.

      AZ는 VSphereDeploymentZone에 매핑된 후 vSphere의 호스트 그룹에 매핑됩니다.

2. 새 AZ를 추가합니다. ytt 오버레이 구성을 사용하거나 Tanzu CLI를 사용하여 새 AZ를 추가할 수 있습니다.

   ytt

   다음은 레거시 클러스터 및 고급 클러스터의 ytt 오버레이 구성을 보여 줍니다. ytt를 다운로드하고 설치하는 방법에 대한 자세한 내용은 Carvel 도구 설치를 참조하십시오.

   레거시 클러스터

   #@overlay/match by=overlay.subset({"kind":"MachineDeployment", "metadata":{"name": "${CLUSTER_NAME}-md-0"}})
     ---
     apiVersion: cluster.x-k8s.io/v1beta1
     kind: MachineDeployment
     metadata:
       name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
     spec:
       clusterName: #@ data.values.CLUSTER_NAME
       replicas: #@ data.values.WORKER_MACHINE_COUNT_0
       selector:
         matchLabels: null
       strategy:
         type: #@ verify_and_configure_machine_deployment_rollout_strategy(data.values.WORKER_ROLLOUT_STRATEGY)
       template:
         metadata:
           labels:
             node-pool: #@ "{}-worker-pool".format(data.values.CLUSTER_NAME)
         spec:
           clusterName: #@ data.values.CLUSTER_NAME
           version: #@ data.values.KUBERNETES_VERSION
           bootstrap:
             configRef:
               name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
               apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
               kind: KubeadmConfigTemplate
           infrastructureRef:
             name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
             apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
             kind: AWSMachineTemplate
           failureDomain: #@ default_az_0
   
   

   클래스 기반 클러스터

   workers:
     machineDeployments:
     #@overlay/match by=overlay.index(0)
     - class: tkg-worker
       name: md-0
       replicas: #@ data.values.WORKER_MACHINE_COUNT_0
       #@overlay/match missing_ok=True
       failureDomain: #@ default_az_0
       metadata:
         annotations:
           run.tanzu.vmware.com/resolve-os-image: #@ "ami-region={},os-name={},os-arch={}".format(data.values.AWS_REGION, data.values.OS_NAME, data.values.OS_ARCH)
   

   Tanzu CLI

   새 AZ를 생성하여 Tanzu CLI를 사용하여 토폴로지 인식 로컬 스토리지 프로비저닝을 지원할 수 있습니다.

   레거시 클러스터

   tanzu cl node-pool set cl-name -f node-pool.yaml
   
   # node-pool.yaml
   name: vsphere-wc-1-manual-node-pool
   replicas: 1
   az: "rack4"
   

   고급 클러스터

   ClusterClass 기반 클러스터를 위한 노드 풀 구성의 설정(생성)을 참조하십시오.