bmctl로 클러스터 백업 및 복원

이 페이지에서는 bmctl을 사용하여 베어메탈용 Google Distributed Cloud(소프트웨어 전용)로 만든 클러스터를 백업 및 복원하는 방법을 설명합니다. 이 안내는 모든 클러스터 유형에 적용됩니다.

bmctl 백업 및 복원 프로세스에는 영구 볼륨이 포함되지 않습니다. 로컬 볼륨 프로비저닝 도구(LVP)로 생성된 모든 볼륨은 변경되지 않은 상태로 남습니다.

추가 지원이 필요하면 Cloud Customer Care에 연락합니다. 또한 다음을 포함한 지원 리소스에 대한 자세한 내용은 지원 받기를 참조하세요.

지원 케이스를 여는 요구사항
문제 해결에 도움이 되는 도구(예: 환경 구성, 로그, 측정항목)
지원되는 구성요소

클러스터 백업

bmctl backup cluster 명령어는 지정된 클러스터의 etcd 스토어와 PKI 인증서의 클러스터 정보를 tar 파일에 추가합니다. etcd 스토어는 모든 클러스터 데이터에 사용되는 Kubernetes에서 지원되는 스토어이며 클러스터 상태를 관리하는 데 필요한 모든 Kubernetes 객체와 커스텀 객체를 포함합니다. PKI 인증서는 TLS 인증에 사용됩니다. 이 데이터는 클러스터의 컨트롤 플레인이나 고가용성(HA) 배포에 사용되는 컨트롤 플레인 중 하나에서 백업됩니다.

백업 tar 파일에는 서비스 계정 키 및 SSH 키를 포함한 민감한 사용자 인증 정보가 포함됩니다. 안전한 장소에 백업 파일을 보관하세요. 의도치 않게 파일이 노출되는 일이 없도록 Google Distributed Cloud 백업 프로세스는 인메모리 파일만 사용합니다.

스냅샷 데이터를 비교적 최신 상태로 유지하기 위해 클러스터를 정기적으로 백업합니다. 클러스터의 중대 변경사항 빈도에 맞게 백업 빈도를 조정합니다.

클러스터 백업에 사용하는 bmctl 버전은 관리 클러스터의 버전과 일치해야 합니다.

클러스터를 백업하려면 다음 안내를 따르세요.

사용자 인증 정보 및 모든 노드에 대한 SSH 연결을 포함하여 클러스터가 올바르게 작동하는지 확인합니다.

백업 프로세스의 의도는 정상으로 알려진 상태에서 클러스터를 캡처해서 큰 문제가 발생했을 때 작업을 복원할 수 있도록 하기 위한 것입니다.

다음 명령어를 사용하여 클러스터를 확인합니다.
```
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 백업하려는 클러스터의 이름
- ADMIN_KUBECONFIG: 관리자 클러스터의 kubeconfig 파일 경로
다음 명령어를 실행하여 대상 클러스터가 조정 상태에 있지 않은지 확인합니다.
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 백업할 클러스터의 이름
- CLUSTER_NAMESPACE: 클러스터의 네임스페이스. 기본적으로 Google Distributed Cloud의 클러스터 네임스페이스는 cluster-가 앞에 표시된 클러스터 이름입니다. 예를 들어 클러스터 이름을 test로 지정한 경우 네임스페이스 이름은 cluster-test가 됩니다.
- ADMIN_KUBECONFIG: 관리자 클러스터의 kubeconfig 파일 경로

Reconciling 유형의 Conditions에 대한 명령어 출력에서 Status 섹션을 확인합니다.

다음 예시와 같이 Conditions의 False 상태는 클러스터가 안정적이고 백업할 준비가 되었음을 의미합니다.

...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

다음 명령어를 실행하여 클러스터를 백업합니다.
```
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 백업할 클러스터의 이름
- ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
기본적으로 백업 tar 파일은 관리자 워크스테이션에서 작업공간 디렉터리(기본적으로 bmctl-workspace)에 저장됩니다. tar 파일은 이름이 CLUSTER_NAME_backup_TIMESTAMP.tar.gz입니다. 여기서 CLUSTER_NAME은 백업되는 클러스터의 이름이고 TIMESTAMP는 백업이 수행된 날짜 및 시간입니다. 예를 들어 클러스터 이름이 testuser인 경우 백업 파일 이름은 testuser_backup_2006-01-02T150405Z0700.tar.gz가 됩니다.

백업 파일에 대해 다른 이름 및 위치를 지정하려면 --backup-file 플래그를 사용합니다.

백업 파일은 1년 후 만료됩니다. 만료된 백업 파일은 클러스터 복원 프로세스에 사용되지 않습니다.

클러스터 복원

백업에서 클러스터를 복원하는 것은 최후의 수단으로서, 클러스터에 치명적인 장애가 발생하여 그 밖의 다른 방법으로는 정상적인 서비스로 돌아갈 수 없을 때 사용해야 합니다. etcd 데이터가 손상되었거나 etcd 포드가 비정상 종료 루프에 있을 때가 그 예에 해당합니다.

백업 tar 파일에는 서비스 계정 키 및 SSH 키를 포함한 민감한 사용자 인증 정보가 포함됩니다. 의도치 않게 파일이 노출되는 일이 없도록 Google Distributed Cloud 복원 프로세스는 인메모리 파일만 사용합니다.

클러스터 복원에 사용하는 bmctl 버전은 관리 클러스터의 버전과 일치해야 합니다.

클러스터를 복원하려면 다음 안내를 따르세요.

백업 당시 클러스터에 제공된 모든 노드 머신이 올바르게 작동하고 연결되는지 확인합니다.
백업 당시 사용된 SSH 키로 노드 간 SSH 연결이 작동하는지 확인합니다.

이러한 SSH 키는 복원 프로세스 중에 복구됩니다.
백업 당시에 사용된 서비스 계정 키가 여전히 활성 상태인지 확인합니다.

이러한 서비스 계정 키는 복원 클러스터를 위해 복구됩니다.
관리자, 하이브리드, 독립형 클러스터를 복원하려면 다음 명령어를 실행합니다.
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
```
다음을 바꿉니다.
- CLUSTER_NAME: 복원할 클러스터의 이름
- BACKUP_FILE: 사용 중인 백업 파일의 경로 및 이름
사용자 클러스터를 복원하려면 다음 명령어를 실행합니다.
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG
```
다음을 바꿉니다.
- CLUSTER_NAME: 복원할 클러스터의 이름
- BACKUP_FILE: 사용 중인 백업 파일의 경로 및 이름
- ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로

복원 프로세스가 종료되면 복원된 클러스터에 대해 새로운 kubeconfig 파일이 생성됩니다.

복원이 완료되면 다음 단계를 수행하여 복원이 성공적으로 완료되었는지 확인합니다.

다음 명령어를 실행하여 생성된 kubeconfig 파일로 실행되는 노드 준비 상태와 시스템 포드를 확인합니다.

etcd 포드에는 두 가지 유형이 있습니다.
- etcd-HOST_NAME: 기본 etcd 포드에 해당합니다.
- etcd-events-HOST_NAME: etcd-events 포드에 해당합니다.
```
kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
```

etcd 포드마다 다음을 실행하여 etcd 상태를 확인합니다.

kubectl exec ETCD_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

정상적인 etcd 구성원의 경우 응답은 다음과 같습니다.

https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms

etcd-events 포드마다 다음 명령어를 실행하여 etcd-events 상태를 확인합니다.

kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

정상적인 etcd-events 구성원의 경우 응답은 다음과 같습니다.

https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms

문제 해결

백업 또는 복원 프로세스에 문제가 있는 경우 다음 섹션이 문제를 해결하는 데 도움이 될 수 있습니다.

추가 지원이 필요하면 Google 지원에 문의하세요.

백업 또는 복원 중 메모리 부족

백업 또는 복원 프로세스 중에 설명이 필요하지 않거나 다음 단계에서 명확하지 않은 오류 메시지가 표시될 수 있습니다. bmctl 명령어를 실행하는 워크스테이션에 RAM이 많지 않은 경우 백업 또는 복원 프로세스를 수행하기에 메모리가 충분하지 않을 수 있습니다.

Google Distributed Cloud 버전 1.13 이상에서는 백업 명령어에 --use-disk 매개변수를 사용할 수 있습니다. 파일 권한을 보존하려면 이 매개변수가 파일의 권한을 수정하므로 명령어를 실행하는 사용자가 루트 사용자(또는 sudo)여야 합니다.

복원 중 파일에 대한 권한 누락

복원 작업이 성공한 후 다음 예시와 비슷한 오류 메시지가 표시되면서 부트스트랩 삭제가 실패할 수 있습니다.

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

이 오류는 복원에 필요한 일부 디렉터리에 쓰기를 수행할 수 없음을 의미할 수 있습니다.

Google Distributed Cloud 버전 1.14 이상에는 디렉터리가 쓰기 가능해야 한다는 것에 대한 더욱 명확한 오류 메시지가 있습니다. 보고된 디렉터리가 쓰기 가능한지 확인하고 필요에 따라 디렉터리에 대한 권한을 업데이트합니다.

백업을 통해 복원 프로세스가 중단된 후 SSH 키 새로고침

백업 수행 후 SSH 키를 새로 고치면 복원 프로세스 중 SSH 관련 작업이 실패할 수 있습니다. 이 경우 새 SSH 키가 복원 프로세스에 유효하지 않게 됩니다.

이 문제를 해결하려면 임시로 원래 SSH 키를 추가한 후 복원을 수행합니다. 복원 프로세스가 완료되면 SSH 키를 순환할 수 있습니다.