k8s) Cluster Maintenance

OS Upgrade

해당 내용은 OS Upgrade 뿐만 아니라 Kubelet Version Upgrade 등의 상황에서도 필요한 내용이다.

노드가 비활성화되었다가 활성화되면 즉시 Kubelet이 실행되고 노드에 배치된 파드는 다시 실행된다. 하지만 노드가 5분(`pod-eviction-timeout default value`) 이상 비활성화되면 파드는 다른 노드에 재배치되게 된다.

Cf. set Pod eviction timeout(노드에서 파드를 삭제하기 위한 대기 시간)

kube-controller-manager --pod-eviction-timeout=5m0s

Drain

노드에 존재하는 모든 파드를 제거하여 노드를 비운다. 해당 노드는 `SchedulingDisable` 상태가 되어 새로운 파드의 스케쥴링이 일어나지 않는다.

kubectl drain [node-name]

• Static Pod 들은 제거되지 않는다.
• 노드에서 제거되는 파드들 중 ReplicaSet에 의해 관리되는 파드들은 다른 노드에 재배치 된다. 그렇지 않은 경우에는 재배치되지 않는다.
  • DaemonSet에 의해 관리되는 파드는 삭제되어도 바로 다시 생성된다. 때문에 drain에 실패하는데, 이러한 데몬셋 파드들을 무시하고(유지하고) 진행하기 위해서는 `ignore-daemonsets` 옵션의 값을 참으로 줄 수 있다. (default: `false`)

kubectl drain [node-name] --ignore-daemonsets=true

• ReplicaSet으로 구성되지 않는 파드가 존재하면 Drain 실패 메세지가 나타난다.

Cordon

노드에 존재하는 파드들을 유지한 채 해당 노드는 SchedulingDisable 상태가 되어 새로운 파드의 스케쥴링이 일어나지 않는다.

kubectl cordon [node-name]

Uncordon

노드의 `SchedulingDisable` 상태를 제거하여 정상적으로 스케쥴링될 수 있도록 한다.

---

Cluster Upgrade Precess

Cf. 여기서는 Controlplane 구성 요소만을 다룬다. ETCD Cluster와 CoreDNS는 다루지 않는다.

• 쿠버네티스 구성 요소들의 버전은 꼭 다 같을 필요는 없다. 단, kube-apiserver의 경우 주요 구성 요소인데다 다른 구성 요소들과 통신하기 때문에 모든 요소들 버전보다 높거나 같아야 한다.

💡 쿠버네티스 구성 요소들: kube-apiserver, controller-manager, kube-scheduler, kubelet, kube-proxy, kubectl

허용되는 버전

• controller-manager, kube-scheduler: kube-apiserver 기준 -1 버전까지 가능
• kubelet, kube-proxy: kube-apiserver 기준 -2 버전까지 가능
• kubectl은 kube-apiserver기준 -1 ~ +1 버전 가능
• Ex) kube-apiserver 버전이 v1.10 인 경우
  • controller-manager, kube-scheduler: v1.9 또는 v1.10 가능
  • kubelet, kube-proxy: v1.8 또는 v1.9 또는 v1.10 가능
  • kubectl: v1.9 또는 v1.10 또는 v1.11 가능

---

Upgrade Kubernetes(Kubeadm 기준)

Kubeadm Upgrade → Master node Upgrade → Worker node Upgrade 순으로 진행

Worker node Upgrade Strategy

1. 한 번에 모든 워커 노드를 다운시키고 업그레이드하는 전략
2. 한 번에 하나의 워커 노드를 다운시키고 업그레이드하길 반복하는 전략
   • 업그레이드 하지 않는 워커 노드들로 deployment 이동
3. 새로운 버전의 워커 노드를 하나 생성하여 하나의 구 버전 워커 노드의 deployment를 새로운 버전의 워커 노드에서 실행하고, (빈 상태가 된) 구 버전 노드를 하나 제거(delete)하길 반복하는 전략

Upgrade process

💡 요약 마스터 노드: kubeadm과 클러스터, kubelet(없을 수 있음) 버전을 업그레이드 한다. 워커 노드: 하나씩 kubeadm과 kubelet 버전을 업그레이드 한다. (둘의 명령어는 조금 다르다.)

• 마스터 노드 업그레이드시 sudo 를 붙여야 할 수 있다.
• 노드에서 패키지 업데이트를 할 때는 항상 패키지 매니저의 업그레이드 가능한 패키지 목록을 업데이트 한 후에 시도 하자(`apt-get update` 한 후 `apt-get update [package-name]=[upgrade-version]`)
• 한 번에 하나의 마이너 버전 내에서만 업그레이드 가능하다. (Ex. 1.11.x → 1.12)
• `kubeadm upgrde plan` 을 통해 현재 클러스터 및 Kubeadm의 버전, lastest stable 버전 정보 확인 가능

kubeadm upgrade plan

controlplane 업그레이드 후 kubelet도 업그레이드 해줘야 한다는 메세지가 나타난다.

이미지의 버전은 노드의 서버 버전이 아닌 노드의 kubelet 버전이다.

마스터 노드 업그레이드

1. Kubeadm 업그레이드(마스터 노드)

apt-get upgrade -y kubeadm=1.12.0-00

2. 클러스터 업그레이드(마스터 노드)

kubeadm upgrade apply [-y] v1.12.0

3. 마스터 노드에 kubelet이 있는 경우 마스터 노드 업그레이드 마저 진행

Cf. 설정에 따라 마스터 노드에 kubelet이 있을 수도 있고 없을 수도 있음

이해가 안가는 부분(kubeadm의 클러스터 버전 업그레이드와 kubelet 버전 업그레이드의 관계)

 이 때, controlplane의 컴포넌트들의 버전은 올라가있었음(이건 클러스터 버전과 관련있는 것?)때문에 apt-get upgrade kubelet=1.27.0-00을 통해 kubelet 버전을 업그레이드하려하자, kubeadm 버전은 업데이트 될 것이지만 kubelet은 다운그레이드 될 것이라는 메세지가 뜬다.

• 다른 분이 작성한 블로그 포스트를 보면 kubeadm 업그레이드 후 kubeadm upgrade apply 를 통해서는 클러스터 업그레이드가 되는 것이고, 그 후에 kubeadm 버전을 업그레이드할 때 처럼 apt-get upgrade kubelet 을 해야하는게 맞는 것 같다. (만약 마스터 노드에 kubelet이 존재한다면, 이 kubelet 업그레이드까지 마치고나서 uncordon 해주어야 한다.)
• 그래서 다운그레이드 되는 것을 예상했지만 이후에 kubelet을 재시작하자 kubelet 버전이 올라간 것을 확인할 수 있었다.
• 이 때, 노드의 버전도 올라가있는지 확인 필요(노드의 버전 = kubelet 버전이니까)
• kubeadm upgrade plan에서는 이후에 kubelet 버전을 manully 하게 업그레이드 해야한다고 하며 제공하는 명령어로 kubeadm upgrade apply가 있음을 알려줬는데, 해당 명령어를 통해 ‘클러스터’를 업그레이드 한 후에는 사실상 kubelet이 업그레이드 되지 않았음(restart를 안해서 그런가?)

4. kubelet 버전 업그레이드

apt-get upgrade -y kubelet=1.12.0-00

5. kubelet restart

systemctl restart kubelet

Cf. restart 후 kubectl get nodes 실행시 해당 노드의 kubelet 버전이 올라간 것을 확인 가능)

워커 노드(들) 업그레이드

모든 워커 노드들을 하나씩 업그레이드 진행한다.

1. `kubectl drain [node-name]` 을 통해 노드에서 동작하는 파드 모두 퇴출시키기
2. `ssh [node-name]` 을 통해 노드에 접속
3. 마스터 노드 업그레이드와 같이 kubeadm 버전 업그레이드 & kubelet 업그레이드 진행

apt-get upgrade -y kubeadm=1.12.0-00
apt-get upgrade -y kubelet=1.12.0-00

4. 새 kubelet 버전을 위해 노드 구성 업데이트(필요한 과정이 아닌가..?)

kubeadm upgrade node config --kubelet-version v1.12.0

5. kubelet restart

systemctl restart kubelet systemctl daemon-reload

6. 노드의 `unSchedulabled` 상태 해제

kubectl uncordon [node-name]

---

Backup & Restore

query the Kube API server

• 오브젝트에 대한 config 파일을 만들어 이를 kube apply 하여 생성 및 업데이트할 수 있음 - 이 방법은 다른 사람들과 파일을 공유할 수 있으며, 이를 Git 등에 업로드하여 백업 가능
• 모든 리소스(오브젝트)의 config 파일을 백업할 수 있음

kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml

etcd

• 클러스터, 노드, 클러스터 내부에 생성된 모든 리소스에 대한 정보 저장
  • 데이터 저장 경로: etcd.service 파일에 --data-dir(ex. /var/lib/etcd) 정의되어 있음
  • Built-in 스냅샷 솔루션을 통해 데이터베이스의 스냅샷 생성 가능

스냅샷 생성

ETCDCTL_API=3 etcdctl snapshot save [snapshot-name] \
	--cacert=[trust-ca-file-name] \ # mandatory option
	--cert=[cert-file-name] \ # mandatory option
	--key=[key-file-name] # mandatory option

백업된 스냅샷 상태 조회

ETCDCTL_API=3 etcdctl snapshot status [snapshot-name]

Restore(etcd)

백업된 스냅샷을 통해 이전 버전의 클러스터를 복원하려할 경우

1. kube-apiserver 중단

service kube-apiserver stop

2. snapshot restore(certificate에 사용될 파일들은 필요없음)

ETCDCTL_API=3 etcdctl snapshot restore [snapshot-name] \
	--data-dir=/var/lib/etcd-from-backup

• etcd의 스냅샷을 통한 복구시, 새로운 클러스터 구성을 초기화하여 etcd의 구성 요소를 새로운 클러스터의 멤버로 구성(기존 클러스터에 합류하지 않도록)
• 새 데이터 경로가 생성되고, 이 경로를 etcd.service파일의 --data-dir 값에 작성하면 해당 위치로 새로운 데이터 경로를 사용하게 할 수 있다.

3. 데몬 서비스 재시작

systemctl daemon-reload

4.etcd 서비스 재시작

service etcd restart

5.멈추었던 kube-apiserver 재시작

service kube-apiserver restart

Cf. etcd snapshot 저장시 `trusted-ca-file`, `cert-file`, `key-file` 가 포함되어야 한다.(mandatory)

• `trusted-ca-file(--cacert)`: CA 번들(TLS 지원 보안 서버의 인증서 확인)
• `cert-file(--cert)`: TLS 인증서 파일
• `key-file(--key)`: TLS 키 파일(보안 클라이언트 식별)