Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

bmctl로 클러스터 백업 및 복원

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

백업되는 항목과 백업되지 않는 항목

bmctl 백업 및 복원 프로세스는 Kubernetes 컨트롤 플레인 레이어에서 작동하며 다른 백업 솔루션과는 다릅니다. Kubernetes 이외의 백업 솔루션은 워크로드 데이터, 영구 스토리지, 실제 머신의 호스트 운영체제를 캡처합니다. bmctl 백업 및 복원 프로세스는 이러한 다른 구성요소를 백업하지 않고 Kubernetes 클러스터를 복원합니다.

컨트롤 플레인 상태 (`bmctl` 백업 프로세스에 의해 백업됨)

bmctl는 다음 객체를 백업합니다.

etcd 저장소 클러스터의 구성과 선택한 상태를 정의하는 모든 Kubernetes 리소스와 커스텀 객체 (예: 포드 사양, 배포, ConfigMap, 보안 비밀)
PKI 인증서 클러스터 내 보안 통신에 사용되는 인증서입니다.
노드 구성 파일 및 매니페스트 클러스터 노드와 관련된 구성입니다.

워크로드 및 VM 런타임 스토리지 (`bmctl` 백업 프로세스로 백업되지 않음)

bmctl에서는 다음 데이터를 백업하지 않습니다.

라이브 포드 및 컨테이너 런타임 상태입니다. bmctl는 활성 프로세스와 인메모리 애플리케이션 데이터를 저장하지 않습니다. 복원 후 Kubernetes는 etcd 사양에서 포드를 다시 시작합니다. 저장되지 않은 인메모리 상태가 손실됩니다.
영구 볼륨 스토리지입니다. bmctl는 영구 볼륨, 로컬 볼륨 프로비저닝 도구(LVP)로 생성된 볼륨 또는 외부 스토리지 드라이버에 저장된 데이터를 백업하지 않습니다.
가상 머신 디스크입니다. bmctl은 VM 내의 데이터베이스, 파일, 운영체제 상태와 같은 VM의 가상 하드 드라이브 콘텐츠를 백업하지 않습니다.

Kubernetes 네이티브 또는 게스트 내 백업 메커니즘을 사용하여 애플리케이션 데이터와 가상 머신 상태를 보호해야 합니다. 기본 스토리지 드라이버가 CSI 볼륨 스냅샷을 지원하는 경우 표준 Kubernetes 볼륨 스냅샷을 사용하여 영구 볼륨의 특정 시점 사본을 만드세요. 스토리지 구성에 대한 자세한 내용은 스토리지 개요를 참고하세요.

VM Runtime 가상 머신의 게스트 운영체제 내에서 백업 에이전트를 실행하거나 Kubernetes 워크로드 내에서 애플리케이션 네이티브 백업 도구를 배포합니다.

물리적 호스트 운영체제 (지원되지 않음)

Google Distributed Cloud 노드의 실제 Linux 운영체제를 일회용 인프라로 취급합니다. Kubernetes 네트워킹 아키텍처는 호스트 수준 OS 이미지 복원을 지원하지 않습니다. 따라서 Google은 호스트 OS에 서드 파티 호스트 수준 백업 에이전트를 직접 설치하거나 OS 수준 이미지 백업 또는 디스크 스냅샷에서 실제 노드를 복원하는 것을 지원하지 않습니다.

호스트 Linux OS에 서드 파티 실제 백업 에이전트를 직접 설치하면 심각한 위험이 발생할 수 있습니다.

많은 백업 에이전트는 스냅샷 작업 중에 변경사항을 추적하고 로컬 디스크 블록을 잠그기 위해 독점 커널 모듈이나 블록 수준 필터 드라이버를 설치하므로 다음과 같은 문제가 발생할 수 있습니다.

etcd 데이터베이스가 미리 쓰기 로그에 추가할 수 없고, 노드 하트비트가 시간 초과되고, Raft 컨센서스가 실패하고, 클러스터가 불안정해집니다.
지원되지 않는 서드 파티 커널 드라이버는 하위 수준 커널 루틴 및 컨테이너 런타임과 충돌하여 클러스터 업그레이드가 실패합니다.
이미지 백업 또는 디스크 스냅샷에서 실제 노드를 복원하면 Raft 컨센서스 프로토콜을 위반하게 됩니다. etcd 데이터베이스가 컨트롤 플레인 노드의 로그와 동기화되지 않고 심각한 클러스터 상태 손상이 발생합니다.
워커 노드가 API 서버의 정보 소스와 동기화되지 않고, Dataplane V2 (Cilium) IP 주소가 충돌하며 트래픽이 삭제됩니다.

운영체제 또는 하드웨어 오류가 발생한 실제 노드를 복구하려면 OS 이미지를 복원하지 마세요. 대신 클러스터에서 노드를 완전히 삭제하고, 깨끗한 기본 운영체제를 재설치하고, 노드 풀에 노드를 다시 추가하세요. 자세한 복구 안내는 실패한 노드 재설정을 참고하세요.

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

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

클러스터 백업

bmctl backup cluster 명령어는 클러스터의 etcd 데이터와 PKI 인증서를 tar 파일로 패키징합니다. etcd 데이터베이스는 모든 클러스터 데이터의 중앙 데이터 스토어로, 클러스터 상태를 관리하는 데 필요한 모든 Kubernetes 객체와 커스텀 리소스가 포함되어 있습니다. PKI 인증서는 TLS를 통해 인증합니다. 이 데이터는 클러스터의 컨트롤 플레인이나 고가용성(HA) 배포에 사용되는 컨트롤 플레인 중 하나에서 백업됩니다.

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

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

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

클러스터에 노드 에이전트를 설치한 경우 관리자 노드와 모든 타겟 노드의 /tmp 디렉터리에 12GB의 여유 공간이 있어야 합니다. 타겟 노드의 /tmp 디렉터리 크기를 변경할 수 없는 경우 타겟 노드의 로컬 스토리지 용량 변경을 참고하세요. 관리 노드의 /tmp 디렉터리 크기를 변경할 수 없는 경우 관리 노드의 로컬 스토리지 용량 변경을 참고하세요.

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

사용자 인증 정보 및 모든 노드에 대한 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 키를 순환할 수 있습니다.

Node Agent 노드의 백업을 만들 수 없음

노드 에이전트를 사용하고 백업을 만들 때 다음과 같이 보관 파일이 생성되지 않는다는 오류가 표시되는 경우

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

관리자 노드와 모든 타겟 노드의 /tmp 디렉터리에 여유 공간이 12GB 있는지 확인합니다. 타겟 노드의 /tmp 디렉터리 크기를 변경할 수 없는 경우 노드 에이전트 백업을 위한 로컬 스토리지 용량 늘리기를 참고하세요.

관리 노드와 모든 타겟 노드의 /tmp 디렉터리에 12GB의 여유 공간이 있는지 확인한 후 백업을 다시 시도합니다.