리전 장애에 대비해 GKE 클러스터를 다른 리전에도 준비한다면, 어떤 리소스를 백업하고 어디까지 복원할 수 있는지 확인해야 한다. 고객 DR 구성을 검토하면서 싱가포르(asia-southeast1)의 GKE 클러스터를 백업하고, 자카르타(asia-southeast2)의 다른 클러스터에 워크로드를 복원했다. 백업 범위와 복원 정책을 설정한 순서대로 설명한다.
Backup for GKE의 백업·복원 대상#
Backup for GKE는 Kubernetes 리소스의 구성과 지원되는 영구 볼륨 데이터를 백업해, 이미 만들어진 다른 GKE 클러스터에 복원할 수 있다. 대상 클러스터 자체의 제어 영역, 노드 풀, 네트워크 설정을 백업에서 새로 생성하는 서비스는 아니다. 컨테이너 이미지 파일과 Cloud SQL 같은 클러스터 외부 서비스도 백업 대상이 아니다. 따라서 DR 클러스터, 이미지 저장소, 외부 데이터베이스의 복구 절차는 따로 준비한다. Backup for GKE 개요
백업·복원 구성은 다음과 같다.
| 역할 | 구성 |
|---|---|
| 원본 클러스터 | 싱가포르 test-cluster-3 |
| 백업 위치 | 자카르타 asia-southeast2 |
| 복원 대상 | 자카르타 dr-cluster-3 |
| 백업 방식 | 백업 계획을 만든 뒤 수동 백업 실행 |
| 복원 방식 | 대상 클러스터를 지정한 복원 계획으로 백업을 복원 |
아래 구성도에서는 싱가포르의 원본 클러스터에서 자카르타 리전에 백업을 저장하고, 자카르타의 DR 클러스터에서 그 백업으로 워크로드를 복원하는 흐름을 볼 수 있다. 두 클러스터는 각각 먼저 만들어야 하며, 그림의 Backup for GKE 에이전트는 백업·복원 작업을 수행한다.
비용을 산정할 때는 Backup for GKE 이용료와 백업 저장 비용, DR 클러스터 운영비를 함께 확인한다. 백업 위치와 원본 클러스터의 리전이 다르면 리전 간 데이터 전송 비용도 포함한다. 백업 위치와 전송 비용 안내
1. 백업 계획: 원본 클러스터·저장 리전·백업 범위#
백업 계획에는 원본 클러스터, 백업 저장 리전, 백업할 Kubernetes 리소스·볼륨, 일정과 보관 정책을 지정한다. 아래 화면에서는 원본으로 싱가포르 클러스터를, 백업 위치로 자카르타를 선택했다.
범위는 전체 클러스터를 선택했고, Kubernetes 리소스와 영구 볼륨 데이터가 포함된다. 보안 비밀(Secret)은 포함하지 않았다. 따라서 복원 후 Secret이 필요한 워크로드라면 별도 공급 절차가 필요하다. 백업 계획 공식 안내
검토 화면에서 선택한 리전·범위·볼륨 설정을 다시 확인했다. 일정은 설정되지 않았으므로 이 구성에서는 수동 백업을 실행해야 한다.
2. 수동 백업 실행 및 상태 확인#
백업 계획을 만든 다음 수동 백업을 실행했다. 백업 목록에는 대상 백업의 상태가 성공으로 표시되어 있다. 이 화면에서 확인되는 백업 크기는 435.5KiB이고, 생성 시간은 17초다. 이 값은 당시 테스트 워크로드의 결과이지 운영 환경의 백업 시간이나 비용을 예상하는 기준은 아니다.
백업 성공만으로 복원이 완료된 것은 아니다. 다음 단계에서 대상 클러스터와 리소스 충돌·볼륨 정책을 지정한다.
3. 복원 계획: 대상 클러스터와 리소스 충돌 정책#
복원 계획은 위 백업 계획을 참조하고, 대상 클러스터로 자카르타의 dr-cluster-3을 지정했다. 대상 클러스터는 복원 전에 존재해야 하며, Backup for GKE 에이전트도 사용할 수 있어야 한다. 서비스 구성과 복원 조건
이 구성에서는 네임스페이스 리소스를 모두 복원하도록 선택했다. 캡처의 ‘롤백(파괴적)’은 대상 클러스터에서 충돌하는 네임스페이스와 그 안의 리소스를 삭제한 뒤 복원하는 설정이다. 같은 이름의 개별 리소스만 교체하는 것으로 이해하면 안 된다. 기존 서비스가 있는 클러스터에서는 해당 네임스페이스에 무엇이 실행 중인지 먼저 확인해야 한다. 볼륨 데이터는 새 볼륨을 프로비저닝하고 백업에서 복원하도록 지정했다.
복원 계획 검토 화면에서 대상 클러스터와 볼륨 데이터 복원 정책을 확인했다. 클러스터 범위 리소스의 충돌 처리도 이 화면에 표시된다.
4. 백업 선택 및 복원 실행#
복원 계획은 대상과 처리 방식을 정의하며, 계획을 만드는 것만으로 복원이 실행되지는 않는다. 백업 목록에서 복원할 백업을 선택하고 ‘복원 설정’으로 이동한다.
백업 이름과 생성 시점을 확인한 뒤, 앞에서 만든 dr-cluster-3-restore 복원 계획을 선택하고 복원 이름을 입력한다. 복원 계획의 대상이 자카르타의 dr-cluster-3인지 다시 확인하고 실행한다.
실행 후에는 복원 작업의 상태와 오류 내역을 확인하고 대상 클러스터의 워크로드 상태를 점검한다.
5. 복원 후 노드·Pod 상태 확인#
원본과 대상 클러스터에서 각각 노드 3개가 Ready, 예제 hello-server Pod 7개가 Running인 상태를 확인했다. 대상 클러스터의 Pod 실행 상태를 확인한 뒤에는 서비스 접속과 데이터도 점검해야 한다.
복원 후에는 대상 클러스터에서 다음을 확인한다.
kubectl get nodes와kubectl get pods -A로 노드·Pod의 상태를 확인한다.- Service·Ingress 주소와 DNS 전환, 외부 클라이언트의 접속을 확인한다.
- Secret과 이미지 접근 권한, 영구 볼륨의 실제 데이터가 필요한 워크로드를 확인한다.
- Cloud SQL 등 클러스터 밖의 서비스를 별도 DR 구성으로 복구한다. 데이터베이스는 Cloud SQL 리전 간 DR 구성을 참고할 수 있다.
GCP가 기능을 업데이트하면서 UI가 조금씩 변경되므로 현재 화면 구성이나 메뉴는 캡처와 다를 수 있다. 백업 계획의 범위·저장 위치와 복원 계획의 대상·충돌 정책을 기준으로 현재 콘솔을 확인하면 된다.
수동 백업을 생성하고 자카르타 클러스터에서 예제 Pod가 실행된 상태를 확인했다. 운영용 DR을 완성하려면 클러스터 외부 리소스와 애플리케이션 접속까지 포함해 복구 시간을 측정해야 한다.