kubernetes cluster를 update 하기 위해서는 node를 내릴 수 밖에 없는 상황이 생기게 된다. 그런 상황에서 kubernetes의 작동을 이해하고 그 때 사용할 수 있는 drain, cordon 등을 정리해보자.
Node가 내려갔을 때 Kubernetes의 작동
- replica pod가 있을 경우 다른 node의 pod들이 서비스를 제공한다면 사용자에게는 영향이 없을 수 있다. 내려간 node에 있던 pod가 replica가 따로 없다면 사용자는 서비스 중단 영향을 받는다.
- node가 pod eviction timeout(기본값은 5분) 이상 내려가 있을 경우, kuberntes는 해당 node가 죽은 것으로 간주하고 강제종료한다. (이 때 pod가 replica set의 일부일 경우 다른 node에 새 파드를 생성) 죽었던 node가 다시 올라오면 빈 상태로 올라온다. (반면 pod eviction timeout 내에 node가 즉시 올라온다면 그 안의 pod는 그대로 존재)
Pod Eviction Timeout이 발생할 수도 있으니 node의 workload들을 다른 node로 이동시키기
- kubectl drain <node 이름> : 해당 node의 모든 pod 들을 종료한다. (replica set의 pod라면 다른 node에 다시 생긴다.) 이후부터는 해당 node는 cordoned 상태가 되어서 새로운 pod가 해당 node에 스케줄링되지 않는다.
- kubectl cordon <node 이름> : 해당 node를 cordoned 상태로 만들어서 새로운 pod가 스케줄링 되는것을 막지만 drain과 달리 기존 pod들을 종료하지는 않는다.
- kubectl uncordon <node 이름> : 해당 node의 cordoned 상태를 해제하여 pod가 스케줄링될 수 있도록 한다.
kubernetes cluster의 backup과 restore 방법에 대해 알아보자.
Kubernetes에서의 backup 대상
- 리소스 yaml 파일 : 이 yaml 파일들을 github 같은 곳에 저장하면 클러스터가 완전히 다운되어도 쉽게 복구할 수 있다. 하지만 선언형이 아닌 명령형으로 생성한 리소스들은 yaml파일이 없기에 backup에서 누락된다.
- kube api 서버 쿼리 결과 : 아래와 같이 명령을 스크립트로 만들어 모든 리소스 설정을 파일로 저장할 수 있다. 명령형으로 생성한 리소스들도 백업이 가능하다. (관리형 k8s 서비스를 사용할 경우 이 방법을 사용. 직접 마스터 노드와 etcd를 관리하지 않으므로..)
kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml
- etcd : cluster의 모든 상태를 저장한는 etcd를 백업한다. etcd의 데이터 디렉토리를 직접 백업할 수도 있지만, 내장된 스냅샷 기능을 사용하는 것이 권장된다. (on premise k8s일 경우 이 방식이 권장)
etcdctl --endpoints=https://[127.0.0.1]:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /opt/snapshot-pre-boot.db
etcdutl snapshot restore /opt/snapshot-pre-boot.db --data-dir /var/lib/etcd-from-backup
나도 요즘 쿠버네티스 공부해