vSphere 관리 및 워크로드 클러스터 인프라 백업 및 복원(기술 미리보기)
이 항목에서는 vSphere 독립형 관리 클러스터를 사용하여 TKG(Tanzu Kubernetes Grid)의 클러스터 인프라를 백업하고 복원하는 방법을 설명합니다.
- Velero를 사용하여 독립형 관리 클러스터의 워크로드 클러스터 개체를 백업 및 복원하고,
- 해당 구성 파일에서 독립형 관리 클러스터 다시 생성합니다.
참고
- VMware는 Velero를 사용하여 TKG 독립형 관리 클러스터를 백업하는 것을 지원하지 않습니다.
- 독립형 관리 클러스터가 배포된 후 재구성되면 여기에 설명된 대로 다시 생성해도 모든 리소스가 복구되지 않을 수 있습니다.
독립형 관리 클러스터를 사용하여 TKG(Tanzu Kubernetes Grid) 워크로드 클러스터에서 호스팅되는 워크로드 및 동적 스토리지 볼륨을 백업하고 복원하려면 클러스터 워크로드 백업 및 복원을 참조하십시오.
Supervisor 클러스터, 그리고 Supervisor 클러스터가 생성하는 워크로드 클러스터 등 vSphere with Tanzu 클러스터를 백업하고 복원하려면 VMware vSphere 8.0 설명서의 vSphere with Tanzu 백업 및 복원을 참조하십시오.
주의
이 기능은 지원되지 않는 기술 미리보기 상태입니다. TKG 기능 상태를 참조하십시오.
관리 클러스터를 다시 생성한 후 워크로드 클러스터의 Pinniped 인증이 작동하지 않습니다.
Velero 설정
오픈 소스 커뮤니티 표준 도구인 Velero를 사용하여 TKG 독립형 관리 클러스터 인프라와 워크로드를 백업하고 복원할 수 있습니다.
Velero는 백업을 저장하기 위해 다양한 스토리지 제공자를 지원합니다. Velero는 다음도 지원합니다.
Tanzu Kubernetes Grid 구독에는 VMware의 테스트를 거친 Velero 호환 배포 지원이 포함되며, Tanzu Kubernetes Grid 다운로드 페이지에 있습니다.
TKG 클러스터를 백업하고 복원하려면 다음이 필요합니다.
- 로컬 워크스테이션에서 실행되는 Velero CLI v1.9.7. Velero CLI 설치를 참조하십시오.
- 백업을 저장할 위치가 있는 스토리지 제공자. 스토리지 제공자 설정을 참조하십시오.
- 백업하려는 클러스터에서 실행되는 Velero 서버:
- 워크로드 클러스터의 Velero는 아래 설명된 대로 워크로드 및 동적 스토리지를 백업합니다.
- 독립형 관리 클러스터의 Velero는 관리 및 워크로드 클러스터 인프라 백업 및 복원에 설명된 대로 워크로드 클러스터 개체를 백업합니다.
위의 사전 요구 사항을 완료한 후에는 Velero를 사용하여 클러스터 간에 워크로드를 마이그레이션할 수도 있습니다. 지침은 Velero 설명서의 클러스터 마이그레이션 및 리소스 필터링을 참조하십시오.
Velero CLI 설치
주의이전 버전의 TKG와 함께 배포된 대로 Velero CLI v1.8.1 이하를 이미 설치한 경우 v1.9.7로 업그레이드해야 합니다. 이전 Velero 버전은 v1.9 이상에서 사용되는 CRD에서 작동하지 않습니다.
Velero CLI v1.9.7을 설치하려면 다음을 수행합니다.
- Tanzu Kubernetes Grid 다운로드 페이지로 이동한 후 VMware Customer Connect 자격 증명으로 로그인합니다.
- 제품 다운로드에서 다운로드로 이동을 클릭합니다.
- Velero 항목으로 스크롤하고 워크스테이션 OS용 Velero CLI
.gz파일을 다운로드합니다. 파일 이름은velero-linux-,velero-mac-또는velero-windows64-로 시작합니다. -
gunzip명령 또는 선택한 추출 도구를 사용하여 다음의 바이너리 압축을 풉니다.gzip -d <RELEASE-TARBALL-NAME>.gz -
플랫폼의 CLI 바이너리 이름을
velero로 변경하고 실행 가능한지 확인한 후PATH에 추가합니다.-
macOS 및 Linux 플랫폼:
- 바이너리를
/usr/local/bin폴더로 이동하고 이름을velero로 바꿉니다. - 파일을 실행 파일로 만듭니다.
chmod +x /usr/local/bin/velero - 바이너리를
-
Windows 플랫폼:
- 새
Program Files\velero폴더를 생성하고 바이너리를 이 폴더로 복사합니다. - 바이너리 이름을
velero.exe로 바꿉니다. velero폴더를 마우스 오른쪽 버튼으로 클릭하고 속성(Properties) > 보안(Security)을 선택한 후 사용자 계정에 모든 권한(Full Control) 권한이 있는지 확인합니다.- Windows 검색을 사용하여
env를 검색합니다. - 시스템 환경 변수 편집(Edit the system environment variables)를 선택하고 환경 변수(Environment Variables) 버튼을 클릭합니다.
- 시스템 변수(System variables) 아래에서
Path행을 선택하고 편집(Edit)을 클릭합니다. - 새로 만들기(New)를 클릭하여 새 행을 추가하고
velero바이너리에 경로를 입력합니다.
- 새
-
스토리지 제공자 설정
Tanzu Kubernetes Grid 워크로드 클러스터 컨텐츠를 백업하려면 다음을 위한 스토리지 위치가 필요합니다.
- 클러스터의 Kubernetes 메타데이터를 위한 클러스터 개체 스토리지 백업
- 클러스터에서 사용하는 데이터의 볼륨 스냅샷
Velero 설명서의 백업 스토리지 위치 및 볼륨 스냅샷 위치를 참조하십시오. Velero는 다양한 스토리지 제공자를 지원합니다. 다음 중 하나일 수 있습니다.
- 온라인 클라우드 스토리지 제공자.
- 프록시된 환경 또는 에어갭 환경을 위한 MinIO와 같은 온-프레미스 개체 스토리지 서비스.
VMware는 각 클러스터에 고유한 스토리지 버킷을 전용으로 사용할 것을 권장합니다.
MinIO를 설정하려면 다음을 수행합니다.
-
minIO 자격 증명과 스토리지 위치를 사용하여
minio컨테이너 이미지를 실행합니다. 예를 들면 다음과 같습니다.$ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7 -
자격 증명을 로컬 파일에 저장하여
velero install의--secret-file옵션에 전달합니다. 예를 들면 다음과 같습니다.[default] aws_access_key_id=minio aws_secret_access_key=minio123
vSphere용 스토리지
vSphere에서 클러스터 개체 스토리지 백업과 볼륨 스냅샷은 동일한 스토리지 위치에 저장됩니다. 이 위치는 AWS(Amazon Web Services)의 S3 호환 외부 스토리지이거나 MinIO와 같은 S3 제공자여야 합니다.
vSphere Velero용 스토리지를 설정하려면 v1.4.3 플러그인용 Vanilla Kubernetes 클러스터의 vSphere용 Velero 플러그인을 참조하십시오.
AWS용 스토리지
Velero on AWS용 스토리지를 설정하려면 AWS 저장소용 Velero 플러그인의 절차를 따르십시오.
각 플러그인에 대해 필요에 따라 S3 스토리지를 설정합니다. 개체 저장소 플러그인은 클러스터 개체 백업을 저장 및 검색하고 볼륨 스냅샷은 데이터 볼륨을 저장하고 검색합니다.
Azure용 스토리지
Velero on Azure용 스토리지를 설정하려면 Azure 저장소용 Azure 플러그인의 절차를 따르십시오.
각 플러그인에 대해 필요에 따라 S3 스토리지를 설정합니다. 개체 저장소 플러그인은 클러스터 개체 백업을 저장 및 검색하고 볼륨 스냅샷은 데이터 볼륨을 저장하고 검색합니다.
관리 클러스터에 Velero 서버 배포
워크로드 클러스터 개체를 백업하려면 Velero v1.9.7 서버를 독립형 관리 클러스터에 설치하고 설치를 확인합니다.
Velero 설치 옵션
Velero를 설치하려면 다음 옵션과 함께 velero install을 실행합니다.
--provider $PROVIDER: 예:aws--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1--bucket $BUCKET: S3 버킷의 이름--backup-location-config region=$REGION: 버킷이 있는 AWS 지역--snapshot-location-config region=$REGION: 버킷이 있는 AWS 지역- (선택 사항)
--kubeconfig현재 기본값이 아닌 클러스터에 Velero 서버를 설치. -
(선택 사항)
--secret-file ./VELERO-CREDSS3 버킷에 대한 Velero 액세스 권한을 부여하는 한 가지 방법은 다음과 같은 로컬VELERO-CREDS파일을 이 옵션으로 전달하는 것입니다.[default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> -
추가 옵션은 Velero 설치 및 시작을 참조하십시오.
velero install 명령을 실행하면 클러스터에 velero라는 네임스페이스를 생성하고 velero라는 배포를 클러스터에 배치합니다.
다음 설정이 필요합니다.
- 관리 클러스터 플러그인: 다음 플러그인이 필요합니다. 이 옵션은 클러스터를 일시 중지하고 백업 중인 클러스터와 관련된 리소스를 수집합니다.
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1참고
여러 옵션을 쉼표로 구분해서 추가할 수 있습니다. 예:
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1 - 스냅샷 위치 없음: 클러스터 인프라 백업의 경우
--snapshot-location-config를 설정하지 마십시오.
Velero 설치 확인
velero install 명령이 완료된 후 Velero가 성공적으로 설치되었는지 확인합니다.
-
Velero 포드의 상태가
Running인지 확인합니다.kubectl -n velero get pod NAME READY STATUS RESTARTS AGE velero-78fdbcd446-v5cqr 1/1 Running 0 3h41m -
백업 위치가
Available상태에 있는지 확인합니다.velero backup-location get NAME PROVIDER BUCKET/PREFIX PHASE LAST VALIDATED ACCESS MODE DEFAULT default aws mgmt Available 2022-11-11 05:55:55 +0000 UTC ReadWrite true
워크로드 클러스터 개체 백업
독립형 관리 클러스터에서 관리하는 모든 워크로드 클러스터 개체를 백업하려면 다음을 실행합니다.
velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
참고
--exclude-namespaces tkg-system은 관리 클러스터 자체를 제외합니다.
--include-resources cluster.cluster.x-k8s.io는 워크로드 클러스터 개체를 포함합니다.VMware는 스케일 업 또는 다운과 같은 구조적 변경을 수행한 후 즉시 워크로드 클러스터를 백업하는 것을 권장합니다. 이렇게 하면 복원 프로세스가 실패할 수 있는 백업 개체와 물리적 인프라 간의 불일치를 방지할 수 있습니다.
백업 예약
가장 최근의 백업 후 클러스터 개체가 변경되면 복원 후 시스템의 상태가 예상된 최신 상태와 일치하지 않습니다. 이 문제를 "드리프트"라고 합니다. 몇 가지 일반적인 유형의 드리프트에서 복구하는 방법은 아래의 드리프트 처리 섹션을 참조하십시오.
드리프트를 완화하기 위해 VMware는 Velero를 사용하여 정기적인 백업을 스케줄링하는 것을 권장합니다. 예를 들어 모든 워크로드 클러스터를 매일 백업하고 14일 동안 각 백업을 유지하려면 다음을 수행합니다.
velero create schedule daily-bak --schedule="@every 24h" --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s
Velero 스케줄링 옵션에 대한 자세한 내용은 Velero 설명서의 백업 스케줄링을 참조하십시오.
완전한 복원
독립형 관리 클러스터 및 해당 클러스터가 관리하는 워크로드 클러스터 개체를 복원하려면 다음을 수행합니다.
-
구성 파일에서 관리 클러스터 배포에 설명된 대로 구성 파일
mgmt-cluster-config.yaml에서 관리 클러스터를 다시 생성합니다.참고
배포 후 관리 클러스터에 적용된 모든 구성 변경 사항은 구성 파일 또는 환경 변수에 반영되어야 하며 그렇지 않으면 복원되지 않습니다.
-
관리 클러스터가 생성된 직후에는 TKR이 하나만 있어야 합니다.
tanzu kubernetes-release get NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE v1.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True -
백업된 워크로드 클러스터에서 사용하는 모든 TKR을 사용할 수 있게 될 때까지 몇 분 정도 기다립니다.
tanzu kubernetes-release get NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE v1.23.17---vmware.2-tkg.2 v1.23.17+vmware.2-tkg.2 True True v1.24.11---vmware.1-tkg.1 v1.24.11+vmware.1-tkg.1 True True v1.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True -
위의 클러스터에 Velero 서버 배포 지침에 따라 관리 클러스터에 Velero를 설치합니다. 자격 증명 및 백업 위치 구성 설정이 백업이 수행되었을 때와 동일한 값을 갖는지 확인합니다.
-
Velero를 설치한 후 백업이 동기화되고 사용하려는 백업이 나열될 때까지
velero backup get을 실행합니다.velero backup get NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR my-backup Completed 0 0 2022-12-07 17:10:42 +0000 UTC 24d default <none> -
velero restore create를 실행하여 워크로드 클러스터 리소스를 복원합니다. VMware는 최신 백업을 사용하는 것을 권장합니다.velero restore create my-restore --from-backup my-backup --wait복원이 완료되면 클러스터가
createdStalled상태가 됩니다.tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR tkg-vc-antrea default createdStalled 0/3 0/3 v1.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1 -
클러스터 개체에 패치를 적용하여
paused속성을false로 설정합니다. 클러스터 개체가 새 관리 클러스터의paused상태로 다시 생성되어 컨트롤러가 조정을 시도하지 못하도록 하기 때문에 이 작업이 필요합니다.-
클러스터가 복원된 후 일시 중지를 해제하려면 다음을 실행합니다.
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}' -
여러 네임스페이스의 모든 클러스터를 일시 중지 해제하려면 다음 스크립트를 실행합니다.
#!/bin/bash for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system"); do clusters=$(kubectl -n $ns get cluster -o name) if [[ -n $clusters ]];then kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}' fi done
-
-
예를 들어 모든 워크로드 클러스터가
running상태인지 확인합니다.tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR tkg-vc-antrea default running 3/3 3/3 v1.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1 -
각 워크로드 클러스터에 대해
tanzu cluster get CLUSTER-NAME을 실행하여 모든 구성 요소가running상태에 있는지 확인합니다. 예를 들면 다음과 같습니다.tanzu cluster get tkg-vc-antrea NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR tkg-vc-antrea default running 3/3 3/3 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1 Details: NAME READY SEVERITY REASON SINCE MESSAGE /tkg-vc-antrea True 4h14m ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5 True 4h36m ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn True 4h14m │ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt True 4h14m │ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp True 4h23m │ └─Machine/tkg-vc-antrea-ch5hn-x7nmm True 4h32m └─Workers ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn True 4h23m │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9 True 4h24m ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh True 4h24m │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667 True 4h28m └─MachineDeployment/tkg-vc-antrea-md-2-brm2m True 4h21m └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn True 4h23m모든 워크로드 클러스터가 실행된 후에는 Tanzu CLI를 사용하여 워크로드 클러스터를 관리할 수 있습니다.
드리프트 처리
드리프트 사례는 복잡할 수 있지만 몇 가지 일반적인 패턴 및 완화에는 다음이 포함됩니다.
-
부실한 Worker 노드:
- 사용되지 않는 추가 노드
- 백업 후 Worker 노드 수가 스케일 다운된 경우 발생할 수 있음
- 완화는 종종 불필요합니다. 복원 후 시스템 상태 점검이 오래된 시스템 개체를 삭제하고 원하는 시스템 수를 충족하기 위해 새 노드가 생성됩니다.
-
Ghost Worker 노드 인프라:
- 불필요하고 관리되지 않는 노드 인프라
- 백업 후 Worker 노드 수가 스케일 업된 경우 발생할 수 있음
-
완화:
- 워크로드 클러스터
kubeconfig를 가져와서kubectl컨텍스트로 설정합니다. -
다음
kubectl및tanzu명령의 출력을 비교합니다.# Get the actual worker nodes of the workload cluster $ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node NAME STATUS ROLES AGE VERSION tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9 Ready <none> 44m v1.25.7+vmware.1 tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.25.7+vmware.1 tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.25.7+vmware.1 # Get the worker nodes managed by the TKG $ tanzu cluster get tkg-vc-antrea NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR tkg-vc-antrea default running 1/1 1/1 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1-zshippable Details: NAME READY SEVERITY REASON SINCE MESSAGE /tkg-vc-antrea True 13m ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9 True 13m ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx True 13m │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp True 13m └─Workers └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5 True 13m └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt True 13m -
tanzu cluster get에서Workers>Machine목록이 없던kubectl에 의해 나열된 각 Worker 노드의 경우:-
작업자를 예상 값으로 스케일 업합니다. 예를 들면 다음과 같습니다.
tanzu cluster scale ${cluster_name} --worker-machine-count 2 - 클러스터
kubeconfig를 사용하여 고스트 노드를 드레이닝하면 워크로드를 TKG에서 관리하는 노드로 이동합니다.kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets -
클러스터에서 고스트 노드를 제거합니다.
kubectl delete node ${node_name} -
vSphere 또는 다른 인프라에 로그인하고 VM을 수동으로 제거합니다.
-
- 워크로드 클러스터
-
제어부의 오래된 노드 및 고스트 인프라
- 제어부에 대한 사용되지 않는 노드 및 불필요한 노드 인프라
- 백업 후 제어부 노드를 교체한 경우 발생할 수 있음
-
완화:
- 워크로드 클러스터
kubeconfig를 가져와서kubectl컨텍스트로 설정합니다. -
다음
kubectl및tanzu명령의 출력을 비교합니다.# Get the actual control plane nodes of the workload cluster $ kubectl --context wc-admin@wc get node NAME STATUS ROLES AGE VERSION wc-2cjn4-4xbf8 Ready control-plane 107s v1.25.7+vmware.1 wc-2cjn4-4zljs Ready control-plane 26h v1.25.7+vmware.1 wc-2cjn4-59v95 Ready control-plane 26h v1.25.7+vmware.1 wc-2cjn4-ncgxb Ready control-plane 25h v1.25.7+vmware.1 wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.25.7+vmware.1 wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.25.7+vmware.1 wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.25.7+vmware.1 # Get the control plane nodes managed by the TKG $ tanzu cluster get wc NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR wc default updating 4/3 3/3 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1-zshippable Details: NAME READY SEVERITY REASON SINCE MESSAGE /wc True 24m ├─ClusterInfrastructure - VSphereCluster/wc-9nq7v True 26m ├─ControlPlane - KubeadmControlPlane/wc-2cjn4 True 24m │ ├─Machine/wc-2cjn4-4xbf8 True 24m │ ├─Machine/wc-2cjn4-4zljs True 26m │ └─Machine/wc-2cjn4-59v95 True 26m └─Workers ├─MachineDeployment/wc-md-0-nl928 True 26m │ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w True 26m ├─MachineDeployment/wc-md-1-j4m55 True 26m │ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc True 26m └─MachineDeployment/wc-md-2-sd4ww True 26m └─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv True 26m -
tanzu cluster get에서ControlPlane>Machine목록이 없던kubectl에 의해 나열된 각control-plane노드의 경우:-
노드를 삭제합니다.
kubectl delete node ${node_name} - vSphere 또는 다른 인프라에 로그인하고 VM을 수동으로 제거합니다.
-
- 워크로드 클러스터
