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 기능 상태를 참조하십시오.

Velero 설정

오픈 소스 커뮤니티 표준 도구인 Velero를 사용하여 TKG 독립형 관리 클러스터 인프라와 워크로드를 백업하고 복원할 수 있습니다.

Velero는 백업을 저장하기 위해 다양한 스토리지 제공자를 지원합니다. Velero는 다음도 지원합니다.

백업 및 복원 이벤트 전후에 사용자 지정 프로세스를 실행하도록 백업과 복원용 전/후 후크.
백업/복원에 적합하지 않은 워크로드 또는 클러스터 상태의 측면을 제외합니다.

Tanzu Kubernetes Grid 구독에는 VMware의 테스트를 거친 Velero 호환 배포 지원이 포함되며, Tanzu Kubernetes Grid 다운로드 페이지에 있습니다.

TKG 클러스터를 백업하고 복원하려면 다음이 필요합니다.

로컬 워크스테이션에서 실행되는 Velero CLI v1.10.3. Velero CLI 설치를 참조하십시오.
백업을 저장할 위치가 있는 스토리지 제공자. 스토리지 제공자 설정을 참조하십시오.
백업하려는 클러스터에서 실행되는 Velero 서버:
- 워크로드 클러스터의 Velero는 아래 설명된 대로 워크로드 및 동적 스토리지를 백업합니다.
- 독립형 관리 클러스터의 Velero는 관리 및 워크로드 클러스터 인프라 백업 및 복원에 설명된 대로 워크로드 클러스터 개체를 백업합니다.

위의 사전 요구 사항을 완료한 후에는 Velero를 사용하여 클러스터 간에 워크로드를 마이그레이션할 수도 있습니다. 지침은 Velero 설명서의 클러스터 마이그레이션 및 리소스 필터링을 참조하십시오.

Velero CLI 설치

주의
이전 버전의 TKG와 함께 배포된 대로 Velero CLI v1.9.x 이하를 이미 설치한 경우 v1.10.3으로 업그레이드해야 합니다. 이전 Velero 버전은 v1.10 이상에서 사용되는 CRD에서 작동하지 않습니다. 자세한 내용은 아래의 Velero 업그레이드를 참조하십시오.

Velero CLI v1.10.3을 설치하려면 다음을 수행합니다.

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
1. 바이너리를 /usr/local/bin 폴더로 이동하고 이름을 velero로 바꿉니다.
2. 파일을 실행 파일로 만듭니다.
```
chmod +x /usr/local/bin/velero
```
Windows
1. 새 Program Files\velero 폴더를 생성하고 바이너리를 이 폴더로 복사합니다.
2. 바이너리 이름을 velero.exe로 바꿉니다.
3. velero 폴더를 마우스 오른쪽 버튼으로 클릭하고 속성(Properties) > 보안(Security)을 선택한 후 사용자 계정에 모든 권한(Full Control) 권한이 있는지 확인합니다.
4. Windows 검색을 사용하여 env를 검색합니다.
5. 시스템 환경 변수 편집(Edit the system environment variables)를 선택하고 환경 변수(Environment Variables) 버튼을 클릭합니다.
6. 시스템 변수(System variables) 아래에서 Path 행을 선택하고 편집(Edit)을 클릭합니다.
7. 새로 만들기(New)를 클릭하여 새 행을 추가하고 velero 바이너리에 경로를 입력합니다.

Velero 업그레이드

Velero v1.10.3은 v1.9.x와 다른 CRD를 사용합니다. 또한 Velero v1.10은 Kopia와 Restic을 업로드자로 채택했으며, 이로 인해 구성 요소 및 명령의 이름 지정과 Velero의 작동 방식이 몇 가지 변경되었습니다. v1.9.x와 v1.10 간의 변경 내용을 중단하는 방법에 대한 자세한 내용은 Velero v1.10 Changelog의 긴급 변경 사항을 참조하십시오. 이전 버전의 TKG를 사용하여 Velero v1.9.x를 설치한 경우 Velero를 업그레이드해야 합니다.

Velero CLI 설치 절차에 따라 Velero v1.10.3을 설치합니다.

CRD 정의를 Velero v1.10 바이너리로 업데이트합니다.

velero install --crds-only --dry-run -o yaml | kubectl apply -f -

Velero v1.10에서 발생한 구성 요소 이름 변경과 일치하도록 Velero 배포 및 데몬 집합 구성을 업데이트합니다.

아래 명령에서 uploader_type은 restic 또는 kopia일 수 있습니다.

kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -

(선택 사항) restic 데몬 집합을 사용하는 경우 해당 구성 요소의 이름을 변경합니다.

echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0

자세한 내용은 Velero 설명서의 Velero 1.10으로 업그레이드를 참조하십시오.

스토리지 제공자 설정

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.5.1 플러그인용 Vanilla Kubernetes 클러스터의 vSphere용 Velero 플러그인을 참조하십시오.

AWS용 스토리지

Velero on AWS용 스토리지를 설정하려면 AWS 저장소용 Velero 플러그인의 절차를 따르십시오.

각 플러그인에 대해 필요에 따라 S3 스토리지를 설정합니다. 개체 저장소 플러그인은 클러스터 개체 백업을 저장 및 검색하고 볼륨 스냅샷은 데이터 볼륨을 저장하고 검색합니다.

Azure용 스토리지

Velero on Azure용 스토리지를 설정하려면 Azure 저장소용 Azure 플러그인의 절차를 따르십시오.

관리 클러스터에 Velero 서버 배포

워크로드 클러스터 개체를 백업하려면 Velero v1.10.3 서버를 독립형 관리 클러스터에 설치하고 설치를 확인합니다.

Velero 설치 옵션

Velero를 설치하려면 다음 옵션과 함께 velero install을 실행합니다.

--provider $PROVIDER: 예: aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1
--bucket $BUCKET: S3 버킷의 이름
--backup-location-config region=$REGION: 버킷이 있는 AWS 지역
--snapshot-location-config region=$REGION: 버킷이 있는 AWS 지역
(선택 사항) --kubeconfig 현재 기본값이 아닌 클러스터에 Velero 서버를 설치.
(선택 사항) --secret-file ./VELERO-CREDS S3 버킷에 대한 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.2.0_vmware.1
```
참고
여러 옵션을 쉼표로 구분해서 추가할 수 있습니다. 예:
```
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.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 설명서의 백업 스케줄링을 참조하십시오.

복원 후 `kubeconfig` 파일 재생성

Velero를 사용하여 워크로드 클러스터를 복원한 후에는 새 kubeconfig 파일을 사용하는 모든 사용자에게 배포해야 합니다.

kubeconfig를 다시 생성합니다.

tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

위 명령의 출력을 클러스터를 사용하는 모든 사용자에게 배포하여 이전 kubeconfig 파일을 바꿉니다.
- kubeconfig 파일에는 ID나 자격 증명이 포함되어 있지 않으며, Pinniped 설명서의 Kubernetes 클러스터에 대한 연합 인증을 위해 Pinniped를 사용하는 방법 알아보기에 설명된 대로 배포해도 안전합니다.

완전한 복원

독립형 관리 클러스터 및 해당 클러스터가 관리하는 워크로드 클러스터 개체를 복원하려면 구성 파일에서 관리 클러스터를 다시 생성하고, Velero를 사용하여 워크로드 클러스터를 복원하고, 새 kubeconfig 파일을 사용하는 사용자에게 배포합니다.

워크로드 클러스터 개체의 최신 백업과 현재 실행 중 상태 간에 드리프트가 의심되는 경우 드리프트 감지기 도구를 사용하여 드리프트 감지기 사용에 설명된 대로 업데이트 적용 보고서를 생성합니다.
원래 배포된 후 관리 클러스터에 대해 수행된 구성 변경 사항이 해당 구성 파일 또는 환경 변수에 반영되는지 확인합니다. 그렇지 않으면 최신 상태로 복원되지 않습니다.
구성 파일에서 관리 클러스터 배포에 설명된 대로 구성 파일 mgmt-cluster-config.yaml에서 관리 클러스터를 다시 생성합니다.
- 여러 가용성 영역에서 클러스터 실행에 설명된 대로 관리 클러스터 또는 해당 워크로드 클러스터를 vSphere의 여러 가용성 영역에 배포한 경우 또한 VSphereDeploymentZone 및 --az-file vsphere-zones.yaml 개체 정의가 있는 파일을 포함합니다(예: VSphereFailureDomain 명령에 tanzu mc create 포함).

관리 클러스터가 생성된 직후에는 TKR이 하나만 있어야 합니다.

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.26.8---vmware.2-tkg.1  v1.26.8+vmware.1-tkg.1  True        True

백업된 워크로드 클러스터에서 사용하는 모든 TKR을 사용할 수 있게 될 때까지 몇 분 정도 기다립니다.

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.17---vmware.2-tkg.2  v1.24.17+vmware.2-tkg.2  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+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.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-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.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-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.26.8+vmware.1 <none>  v1.26.8---vmware.2-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를 사용하여 워크로드 클러스터를 관리할 수 있습니다.

관리 클러스터를 다시 생성하기 전에 드리프트 감지기를 실행한 경우 미디어 편차에 설명된 대로 드리프트 감지기 보고서에 플래그가 지정된 개체에 수동으로 업데이트를 적용하거나 조사합니다.
관리 클러스터 및 해당 워크로드 클러스터에 대해 새 kubeconfig 파일을 재생성하고 배포합니다.
1. 관리 클러스터 kubeconfig를 다시 생성합니다.
```
tanzu management-cluster kubeconfig get
```
2. 각 워크로드 클러스터에 대해 kubeconfig를 다시 생성합니다.
```
tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
```
3. 위 명령의 출력을 클러스터를 사용하는 모든 사용자에게 배포하여 이전 kubeconfig 파일을 바꿉니다.
  - kubeconfig 파일에는 ID나 자격 증명이 포함되어 있지 않으며, Pinniped 설명서의 Kubernetes 클러스터에 대한 연합 인증을 위해 Pinniped를 사용하는 방법 알아보기에 설명된 대로 배포해도 안전합니다.

드리프트 처리

드리프트는 가장 최근의 백업 후 클러스터 개체가 변경되면 발생하며, 복원 후 시스템의 상태가 예상된 최신 상태와 일치하지 않습니다.

드리프트를 최소화하기 위해 VMware는 자주 정기적으로 백업할 것을 권장합니다.

드리프트를 감지하고 업데이트를 적용하는 데 도움이 되도록 아래 섹션에 설명된 드리프트 감지기 도구를 사용할 수 있습니다.

드리프트 감지기 사용

드리프트 감지기는 다음과 같은 명령줄 도구입니다.

TKG 백업의 컨텐츠를 TKG 클러스터 개체 인프라의 현재 상태와 비교하고
잠재적인 문제 및 드리프트 업데이트 적용 단계를 나열하는 보고서를 생성합니다.

중요
드리프트 감지기가 지원되지 않는 실험 버전 상태입니다. 드리프트가 복잡하며 드리프트 감지기가 드리프트의 모든 인스턴스를 감지하지 못할 수 있습니다. 참조로만 사용해야 하며 일반 백업을 대신해서는 안 됩니다.

드리프트 감지기를 설치하고 사용하는 방법은 VMware KB 웹사이트의 Tanzu Kubernetes Grid 관리 클러스터용 드리프트 감지기를 참조하십시오. 전체 프로세스는 다음과 입니다.

백업에서 TKG를 복원하기 전에 drift-detector 명령을 실행하여 보고서를 생성합니다.
최신 백업에서 TKG를 다운로드하고 복원합니다.
드리프트 감지기 보고서를 참조하여 드리프트 업데이트 적용의 지침에 따라 TKG의 복원된 상태에 대한 업데이트 적용 작업을 수행합니다.

드리프트에 업데이트 적용

드리프트 케이스는 복잡할 수 있지만 드리프트 감지기 보고서가 있거나 마지막 백업 이후 클러스터 개체 상태에서 일부 드리프트를 감지하는 경우 다음과 같이 몇 가지 일반적인 패턴에 업데이트를 적용할 수 있습니다.

부실한 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.26.8+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.26.8+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.26.8+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.26.8+vmware.1  <none>  v1.26.8---vmware.2-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 노드의 경우:
1. 작업자를 예상 값으로 스케일 업합니다. 예를 들면 다음과 같습니다.
```
tanzu cluster scale ${cluster_name} --worker-machine-count 2
```
2. 클러스터 kubeconfig를 사용하여 고스트 노드를 드레이닝하면 워크로드를 TKG에서 관리하는 노드로 이동합니다.
```
kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
```
3. 클러스터에서 고스트 노드를 제거합니다.
```
kubectl delete node ${node_name}
```
4. vSphere 또는 다른 인프라에 로그인하고 VM을 수동으로 제거합니다.

제어부의 오래된 노드 및 고스트 인프라

제어부에 대한 사용되지 않는 노드 및 불필요한 노드 인프라
백업 후 제어부 노드를 교체한 경우 발생할 수 있음

완화:

워크로드 클러스터 kubeconfig를 가져와서 kubectl 컨텍스트로 설정합니다.