이 항목에서는 영구 볼륨 및 스토리지 클래스를 사용하여 TKG(Tanzu Kubernetes Grid) 워크로드 클러스터에 동적 스토리지를 구현하는 방법을 설명합니다.
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 CSI는 스토리지 DRS를 지원하지 않으며, vSphere CSI 설명서의 vSphere 컨테이너 스토리지 플러그인이 지원하는 vSphere 기능에 설명된 조건으로 Storage vMotion을 지원합니다.
vSphere CSI가 조건과 함께 Storage vMotion을 지원하는 자세한 내용은 CSI 문서를 참조하십시오.
vSphere CNS, Amazon EBS, Azure Disk 기본 스토리지 클래스는 기본 스토리지 클래스를 참조하십시오.
외부 프로비저닝
TKG v2.4에서 모든 기본 스토리지 클래스는 "트리 내" 프로비저닝이 아닌 외부("트리 외부") 스토리지 프로비저닝을 사용합니다.
StorageClass
개체 provisioner
값에는 kubernetes.io
접두사가 지정되지 않습니다.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 스토리지 클래스 매개 변수를 참조하십시오.
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 설명서의 스토리지 정책 생성에 있는 지침을 따르십시오. 다음을 확인하십시오.
StorageClass
개체에 storagePolicyName
값으로 기록합니다.로컬 VMFS 스토리지:
로컬 스토리지에 대한 스토리지 정책을 생성하려면 스토리지에 태그를 적용하고 다음과 같이 태그를 기반으로 스토리지 정책을 생성합니다.
최상단 vSphere 메뉴에서 태그 및 사용자 지정 특성(Tags & Custom Attributes)을 선택합니다.
태그(Tags) 창에서 범주(Categories)를 선택하고 새로 만들기(New)를 클릭합니다.
범주 이름을 입력합니다(예: tkg-storage
). 확인란을 사용하여 데이터센터(Datacenter) 및 스토리지 개체(폴더 및 데이터스토어)와 연결합니다. 생성(Create)을 클릭합니다.
최상위 스토리지(Storage) 보기에서 VMFS 볼륨을 선택하고 요약(Summary) 창에서 태그(Tags) > 할당(Assign)…을 클릭합니다.
태그 할당(Assign Tag) 팝업에서 태그 할당(Assign Tag)을 클릭합니다.
태그 생성(Create Tag) 팝업에서 태그에 tkg-storage-ds1
과 같은 이름을 지정하고 생성한 범주를 할당합니다. 확인을 클릭합니다.
태그 할당(Assign Tag)에서 태그를 선택하고 할당(Assign)을 클릭합니다.
최상위 vSphere에서 VM 스토리지 정책(VM Storage Policies) > 스토리지 정책 생성(Create a Storage Policy)을 선택합니다. 구성 마법사가 시작됩니다.
이름 및 설명(Name and description) 창에서 스토리지 정책의 이름을 입력합니다. 참조할 스토리지 정책 이름을 StorageClass
개체에 storagePolicyName
값으로 기록합니다.
정책 구조(Policy structure) 창의 데이터스토어별 규칙(Datastore specific rules)에서 태그 기반 배치 규칙 사용(Enable tag-based placement rules)을 선택합니다.
태그 기반 배치(Tag based placement) 창에서 태그 규칙 추가(Add Tag Rule)를 클릭하고 다음을 구성합니다.
Use storage tagged with
다른 창을 확인하고 구성하거나 필요에 따라 기본값을 수락한 다음 검토 후 마침(Review and finish)을 클릭합니다. 마침(Finish)을 클릭하여 스토리지 정책을 생성합니다.
클러스터 관리자는 다음과 같이 새 스토리지 클래스를 생성할 수 있습니다.
StorageClass
의 기준으로 사용할 VM 스토리지 정책을 선택하거나 생성합니다.
provisioner
, parameters
및 기타 옵션을 사용하여 StorageClass
구성 .yaml
을 생성합니다.
storagePolicyName
매개 변수를 vSphere 스토리지 정책 이름에 큰따옴표로 묶어 Kubernetes 스토리지 클래스를 vSphere 스토리지 정책과 연결합니다.kubectl create -f
로 전달합니다.kubectl describe storageclass <storageclass metadata.name>
을 실행하여 스토리지 클래스를 확인합니다.예를 들어 Kubernetes 설명서의 동적 프로비저닝 사용을 참조하십시오.
vSphere CSI 정보 및 리소스에 대한 자세한 내용은 VMware vSphere 컨테이너 스토리지 플러그인 설명서를 참조하십시오.
위에 설명된 기본 스토리지 클래스 중 하나를 사용하지 않는 클러스터 노드에 영구 스토리지를 프로비저닝하기 위해 클러스터 사용자는 다음과 같이 포드 구성에 사용자 지정 스토리지 클래스를 포함합니다.
kubectl
의 컨텍스트를 클러스터로 설정합니다. 예:
kubectl config use-context my-cluster-admin@my-cluster
스토리지 클래스를 선택하거나 생성합니다.
kubectl get storageclass
를 실행합니다.PVC 및 해당 PV를 생성합니다.
StorageClass
개체의 metadata.name
값으로 설정된 spec.storageClassName
으로 PersistentVolumeClaim
구성 .yaml
을 생성합니다. 예를 들어 Kubernetes 설명서의 동적 프로비저닝 사용을 참조하십시오.kubectl create -f
로 전달합니다.kubectl describe pvc <pvc metadata.name>
을 실행하여 PVC를 확인합니다.kubectl describe pvc
출력에 있는 이름을 Successfully provisioned volume
뒤에 기록합니다.kubectl describe pv <pv unique name>
을 실행하여 PV를 확인합니다.PVC를 사용하려면 포드를 생성합니다.
spec.volumes
을 persistentVolumeClaim.claimName
아래에 PVC를 포함하도록 설정하는 Pod
구성 .yaml
을 생성합니다. 예를 들어 vSphere 컨테이너 스토리지 플러그인 설명서의 vSphere 컨테이너 스토리지 플러그인을 사용하여 블록 볼륨 프로비저닝을 참조하십시오.kubectl create -f
로 전달합니다.kubectl get pod <pod metadata.name>
을 실행하여 포드를 확인합니다.워크로드 클러스터에서 사용하는 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 볼륨 확장을 참조하십시오.
변경 중인 워크로드 클러스터의 관리 클러스터에 로그인하고 워크로드 클러스터의 이름을 검색해야 하는 경우 tanzu cluster list
를 실행합니다.
레이블 선택기 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
암호 컨텐츠의 백업을 YAML 형식으로 vsphere-csi-secret.yaml
에 저장합니다.
kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
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>
편집기에서 vsphere-csi-secret.yaml
을 열고 다음을 수행하여 아래 코드처럼 보이게 합니다.
values.yaml
의 기존 정의를 삭제합니다.stringData
를 정의하는 줄을 추가하고 values.yaml
을 들여쓰기하여 첫 번째 요소로 만듭니다.data.values
출력을 복사합니다.data.values
출력에 붙여 넣고 values.yaml
값으로 들여쓰기합니다.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
...
kubectl apply
를 실행하여 수정된 정의로 클러스터의 암호를 업데이트하고 csi-controller
포드를 다시 생성합니다.
kubectl apply -f vsphere-csi-secret.yaml
vsphere-csi-controller
및 외부 리사이저가 클러스터에서 작동하는지 확인하려면 다음을 수행합니다.
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
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 볼륨 확장을 참조하십시오.
독립형 관리 클러스터에서 생성된 워크로드 클러스터의 경우 토폴로지 인식 로컬 스토리지 볼륨 프로비저닝을 구성할 수 있습니다. 토폴로지 인식 볼륨 프로비저닝을 사용하면 볼륨을 동적으로 프로비저닝할 때 Kubernetes가 지능적인 결정을 내릴 수 있습니다. Kubernetes는 포드에 대한 볼륨을 프로비저닝하기에 가장 좋은 위치에 스케줄러 입력을 가져옵니다.
가용성 영역 생성(AZ):
여러 가용성 영역에 클러스터 실행 지침에 따라 vSphere에서 다음을 생성합니다.
호스트 그룹의 VM 그룹을 제한하는 규칙을 추가합니다.
하나의 VM 그룹 및 호스트 그룹이 워크로드 클러스터에서 AZ를 실행하는 데 사용됩니다.
참고제한 규칙은 로컬 볼륨 구성에만 적용됩니다. 여러 가용성 영역에 배포하는 경우에는 제한 규칙을 생성할 필요가 없습니다.
독립형 관리 클러스터에서 사용자 지정 리소스 정의(CRD) VSphereFailureDomain
및 VSphereDeploymentZone
을 배포합니다.
AZ는 VSphereDeploymentZone
에 매핑된 후 vSphere의 호스트 그룹에 매핑됩니다.
새 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 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 기반 클러스터를 위한 노드 풀 구성의 설정(생성)을 참조하십시오.