본문 바로가기

프로그래밍/kubernetes

ETCD Backup과 Restore 정리(CKA 시험 대비용)

CKA 시험에 대비해서 내가 작성한 글들에 보면 ETCD Backup과 Restore에 대해 정리해놓은게 있는데 그게 서로 제각각인 부분이 있어서 이 부분만 아예 따로 하나의 글로 정리했다(혹시나 기존에 내가 작성한 글을 보고 실습한대로 했다가 안되었을 경우엔 죄송합니다..ETCD Backup에 대해서는 실제 연습문제로 Backup이 나온게 있어서 그걸 푸는 과정에서 정리를 했지만 Restore의 경우 연습문제로 출제가 되질 않아서 강좌 동영상에서 보여준 내용으로 설명하다보니 검증이 안된 점이 있었습니다..) 이 과정의 모든 진행은 Master Node에서 진행한다.

(지금 이 글로 소개하는 방법은 ETCD가 Kubernetes의 kube-system namespace 에서 Pod으로 동작하는 경우에 대해 해당된다. 만약 Kubernetes 밖에 ETCD가 설치되어 있고 Kubernetes가 이 ETCD를 연동하는 구조로 되어 있을 경우 이 내용이 적용 안될수도 있음을 미리 밝혀둔다)

 

ETCD Backup과 ETCD Restore를 하기 위해서는 etcdctl이 설치되어 있어야 한다. etcdctl --help를 입력해보도 명령어가 없다는 식의 결과가 나오면 설치를 해주면 된다. Ubuntu 에서는 다음과 같이 해주면 된다.

sudo apt update
sudo apt install etcd-client

이렇게 한뒤 ETCDCTL_API 환경변수를 다음과 같이 등록해준다

export ETCDCTL_API=3

여기까지는 Backup이든 Restore든 반드시 해야 하는 작업이며 한번만 해주면 다시 해줄 필요는 없다. 그럼 본격적으로 Backup에 대해 설명하겠다.

 

ETCD Backup을 진행할려면 다음과 같이 etcdctl을 실행해주면 된다.

etcdctl --cacert=옵션값 \
--cert=옵션값 \
--key=옵션값 \
snapshot save 백업파일경로 및 파일명

Backup에 필요한 옵션은 3개가 필요한데 --cacert, --cert, --key 이렇게 3개가 필요하다. 이 3개의 옵션에 대한 각 옵션값을 찾는 방법을 지금부터 설명하도록 하겠다

 

먼저 아래의 명령어를 실행시켜서 현재 실행중인 프로세스중 etcd란 문자열을 어떤 형태로든 가지고 있는 프로세스가 실행된 문자열을 조회한다

ps -aux | grep -i etcd

그러면 아래 그림과 같이 나오게 된다. 프로세스가 2개가 잡히는데 하나는 kube-apiserver가 실행하는 과정에서 옵션에 etcd 문자열이 들어가다보니 grep으로 잡히게 된거라 이거는 패스하고 다른 하나인 etcd 프로세스가 grep으로 잡힌 것을 보면 된다.

현재 실행중인 etcd 프로세스

여기서 우리가 봐야 할 부분은 노란색 박스로 표시되어 있는 3개의 옵션을 살펴봐야 한다. --cert-file 옵션, --key-file 옵션, 그리고 --trusted-ca-file 옵션 이렇게 3개의 옵션 값을 위에서 언급했던 etcdctl을 이용한 Backup 명령에서 사용해야 한다. 이걸 아래의 도표와 같이 그냥 외우면 된다(비고란에는 좀더 외우기 쉽게 정리를 했다)

etcdctl
명령 옵션
etcd
프로세스 옵션
비고
--cacert --trusted-ca-file /etc/kubernetes/pki/etcd/ca.crt 옵션 이름에 ca가 들어가며 etcd 프로세스에 ca가 들어가는 옵션이 2개(--peer-trusted-ca-file, --trusted-ca-file)가 있는데 가장 마지막 것을 사용
--cert --cert-file /etc/kubernetes/pki/etcd/server.crt 옵션 이름에 공통적으로 cert가 들어가며 cert가 옵션명의 맨 앞에 나옴
--key --key-file /etc/kubernetes/pki/etcd/server.key 옵션 이름에 공통적으로 key가 들어가며 key가 옵션명의 맨 앞에 나옴

이렇게 외우기 쉽게 머릿속에 정리를 해두고 이러한 옵션을 사용해서 /opt/etcdbackup 파일로 Backup 파일을 만들 경우 아래와 같이 etcdctl 명령어를 사용하면 된다

etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /opt/etcdbackup

이렇게 /opt 디렉토리의 etcdbackup 파일에 ETCD를 백업하게 된다. 약간 암기성으로 접근을 했는데 옵션에 사용된 값 자체를 외우면 안된다. 값은 상황에 따라 달라질수 있기 땜에 반드시 옵션명을 기준으로 작업하도록 하자.

 

그러면 이제 이 백업된 파일을 이용해서 ETCD Restore를 진행해보도록 하자. ETCD Restore를 진행할려면 다음과 같이 etcdctl을 실작업해주면 된다

etcdctl --cacert=옵션값 \
--cert=옵션값 \
--key=옵션값 \
--data-dir=옵션값 \ 
--initial-advertise-peer-urls=옵션값 \
--initial-cluster=옵션값 \
--name=옵션값 \
snapshot restore 파일경로가 포함된 백업파일 이름

Backup 했을때보다 사용해야 할 옵션이 4개가 늘어났다. 그러나 --cacert, --cert, --key 옵션은 ETCD Backup 할때도 사용되는 옵션이기 때문에 설정하는데 큰 문제는 없다고 생각한다. 문제는 나머지 4개인데 Backup 할때는 옵션명이 ca, cert, key 요런 단순 문자열이나 그것들의 조합이라 큰 문제가 없지만 Restore는 마땅한 공통점을 찾기 어려워서 외우기 까다로울수도 있다. 그럴땐 아래의 그림과 같이 etcdctl snapshot restore --help 를 실행하여 snapshot restore에 대한 도움말을 보도록 하자. 아래 그림은 실행한 결과이다.

etcdctl snapshot restore --help 실행결과 화면

위의 그림에서 노란색 박스료 표기한 것을 보자. 그러면 7개의 옵션이 나열되어 있음을 알 수 있다. 여기서 --help 옵션은 지금 이 화면을 보기 위해 사용하는 옵션이니 Restore 와는 무관하고 나머지 6개의 옵션중 Token 안쓰고 HashCheck를 Skip하지 않는다 라는 문장에 맞춰보면 --initial-cluster-token 옵션과 --skip-hash-check 옵션은 사용안하게 된다. 그럼 남은 옵션은 --data-dir--initial-advertise-peer-urls--initial-cluster--name 옵션 이렇게 4가지를 사용하게 된다. 이 옵션들의 값을 설정하는 방법에 대해 설명하겠다. 아래 그림은 위에서 한번 보여줬던 etcd 프로세스 실행시 사용했던 옵션들을 보여주는 그림이다. 다만 아래 그림은 위의 그림과는 달리 붉은색 박스와 녹색 박스가 추가로 그려져 있음을 알 수 있다.

현재 실행중인 etcd 프로세스(붉은색 박스와 녹색 박스 추가)

주의 : --initial-cluster 옵션에 설정된 값은 Master Node 이름=주소 형태를 가지고 있기 때문에 =가 두번 들어간다. 오타나 오류가 아니니 그냥 그대로 사용한다

 

Backup때 사용되었던 노란색 박스로 표기된 것도 Restore에 동일한 방법으로 사용한다(Backup때 사용되었던 옵션명과 동일한 옵션명을 주고 값 또한 동일하게 준다) 녹색 박스로 표기된 것은 Restore에서만 사용되는 Option으로 Restore시 옵션명과 값을 그대로 사용하면 된다. 붉은색 박스로 표기된 것은 옵션값을 다르게 줄 수도 있는 부분을 표시한 것이다. 붉은색 박스로 표기된 옵션인 --data-dir은 Backup된 파일을 Restore 하게 되면 Data 파일이 생성될텐데 그 Data 파일의 위치를 정하는 것이다. etcd 프로세스를 사용했을때 설정한 값인 /var/lib/etcd 로 설정하게 되면 Restore 파일이 기존 파일을 덮어 씌울수 있기 때문에 바람직한 Restore 방법은 아니라고 본다(왜냐면 Restore 했을때 문제가 발생하면 그 이전에 사용한 파일로 돌아갈 수 없기 때문이다) 그래서 이 옵션은 etcd 프로세스를 실행했을때 사용한 값과는 다르게 설정하는 것이 만약의 경우를 대비할 수 있는 방법이 되리라 생각한다. 이와 같은 설명을 모두 감안하고 명령어를 구성하게 되면 아래와 같이 ETCD Restore 명령을 구성하게 된다.

etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--data-dir=/var/lib/etcd_backup \ 
--initial-advertise-peer-urls=https://172.17.0.22:2380 \
--initial-cluster=controlplane=https://172.17.0.22:2380 \
--name=controlplane \
snapshot restore /opt/etcdbackup

--data-dir 옵션을 제외한 나머지 옵션은 etcd 프로세스 실행시 사용된 값들이기 때문에 위에서 설명한 내용만 숙지했으면 큰 문제는 없을것이다. --data-dir 옵션에는 etcd 프로세스 사용시 --data-dir 옵션에 사용되었던 값은 /var/lib/etcd 대신 /var/lib/etcd_backup으로 설정함으로써 restore 시에는 현재 사용중인 Data 파일을 덮어씌우지 않게 했다. 

 

이 과정으로 Restore가 끝난 것은 아니다. 왜냐면 현재 실행중인 etcd의 Data 파일은 /var/lib/etcd 디렉토리 것을 바라보기 때문에 우리가 Restore 하면서 만든 디렉토리인 /var/lib/etcd_backup 디렉토리를 보게끔 해야 한다. 이를 하기 위해서는 ETCD Pod을 생성하는 yaml 파일을 수정할 필요가 있다.

 

ETCD Pod은 Static Pod 이기 때문에 Static Pod 위치를 별도로 수정하지 않았으면 /etc/kubernetes/manifests 디렉토리에 가면 ETCD Pod을 생성하는 yaml 파일인 etcd.yaml 파일을 찾을 수 있다. 이 파일을 열어보면 다음과 같은 내용이 있다. 아래의 내용은 spec.volumes 항목의 내용을 가져온것이다.

volumes:
- hostPath:
    path: /etc/kubernetes/pki/etcd
    type: DirectoryOrCreate
  name: etcd-certs
- hostPath:
    path: /var/lib/etcd
    type: DirectoryOrCreate
  name: etcd-data

여기서 우리가 봐야 할 부분은 hostPath.path가 /var/lib/etcd 이고 name이 etcd-data 인 volume이다. etcd-data 란 이름으로 etcd.yaml의 containers.volumeMounts 항목에서 mountPath를 /var/lib/etcd로 설정하고 있기 때문에 etcd가 실행되는 container가 /var/lib/etcd를 참조하게 되면 최종적으로는 hostPath의 /var/lib/etcd를 참조하는 그런 구조로 되어 있다. 이 부분을 우리가 ETCD Restore시 --data-dir 옵션의 값으로 사용된 /var/lib/etcd_backup 으로 설정해주면 된다. 이렇게 설정된 값은 아래와 같다.

volumes:
- hostPath:
    path: /etc/kubernetes/pki/etcd
    type: DirectoryOrCreate
  name: etcd-certs
- hostPath:
    path: /var/lib/etcd_backup
    type: DirectoryOrCreate
  name: etcd-data

이렇게 바꾸고 yaml 파일을 저장하면 ETCD Pod이 static pod 인 관계로인해 ETCD Pod을 다시 재생성하게 되며 이때 Data 파일이 있는 디렉토리를 /var/lib/etcd_backup을 바라보게 된다. 이렇게 해서 ETCD Restore 과정이 모두 끝나게 된다.

 

이것을 테스트 해볼 수 있는 방법은 간단하다.

1. 임의의 Pod을 하나 생성한다(ex: nginx 이미지를 사용하는 Pod을 하나 생성)

2. ETCD를 백업한다

3. 1번에서 생성한 Pod을 삭제한다

4. ETCD를 Restore 한다

5. 3번에서 삭제한 Pod이 존재하는지 확인(Pod을 생성한 뒤에 ETCD를 Backup 했기 때문에 Pod에 대한 정보가 ETCD 안에 있는 상태에서 Backup이 되므로 ETCD Restore시 삭제한 Pod의 정보가 ETCD에 존재하게 되기 때문에 kube-controller가 이를 감지하고 Pod을 생성한다)

 

참고 : ps -aux | grep -i etcd 명령을 실행시켰을때 etcd 프로세스가 나오질 않는다면 /etc/kubernetes/manifests/etcd.yaml 파일을 열어서 spec.containers.command 항목을 보면 etcd를 실행하면서 그때 사용되는 파라미터 이름과 값들을 같이 확인할 수 있다. 그걸 보고 대응해도 된다.