[CKA] CKA 자격증 준비 자료 정리 5 (Cluster Maintenance)

본 포스팅은 CKA 자격증 준비를 위해 해당 강의를 보고 정리한 자료입니다.

일부 생략되었으니 꼭 강의를 수강하시고 내용 정리 용도로만 참고하시길 바랍니다. 

---

OS Upgrades

software 업그레이드 또는 security patch 등 node를 내려야할 일이 있을 때, 어떻게 안정적으로 클러스터를 유지할까?

• 노드가 5분(--pod-eviction-timeout) 안에 정상화되지 않을 경우 pod은 종료됨
• replicaset 의 pod이었을 경우, 다른 노드에 재생성됨
• 그냥 pod일 경우 사라지게됨

안전하게 노드를 작업하기 위해, drain을 통해 모든 workload를 다른 노드로 옮길 수 있음

$ kubectl drain node-1

• 기존 노드에서 pod들이 종료되고, 다른 노드에서 재생성됨
• 또한 노드가 cordon되고, unshedulable 로 마크됨
  • 제약을 삭제할 때까지, 아무 pod도 스케줄되지 않음
• pod이 다른 노드에서 안전하면, 노드를 reboot할 수 있음
• 다시 돌아왔을 때도, 노드가 unschedulable 하기 때문에, uncordon 해주어야함

$ kubectl uncordon node-1

• 이동했던 pod들이 자동으로 돌아오는 것은 아님

$ kubectl cordon node-2

• cordon의 경우, 노드를 unschedulable로 마크하지만, drain과 다르게 pod을 종료/이동시키지 않음
• 그저 새로운 pod이 더 이상 스케줄링 되지 않도록 처리

---

Cluster Upgrade Process

쿠버네티스의 구성요소들이 버전이 모두 같을 필요는 없지만,

kube api 서버는 control plane의 핵심 구성요소로, 다른 구성요소들은 kube api 서버보다 버전이 높으면 안됨

• kube-apiserver 버전이 v1.10 일때
• controller-manager과 kube-scheduler는 v1.9, v1.10 이 가능하고,
• kubelet과 kube-proxy 는 그보다 하나씩 더 낮은 v1.8, v1.9, v1.10 까지 가능함

쿠버네티스는 새 버전이 릴리즈되면(v1.13), 두 버전 이전까지만 지원됨 (v1.13 ~ v1.11) → 이에 맞춰 버전을 업그레이드해주어야함

• 업그레이드시에는, minor 버전 하나씩 올리는 것이 권장됨
  • v1.10 → v1.11 → v1.12

클러스터 업그레이드 방법

master node 업그레이드

• master node가 업그레이드 되는 동안, api server, scheduler, controller manager 등 control plane 구성요소들이 다운됨
• master node가 다운된다는 것이 worker node나 application들이 영향받는다는 것은 아님

worker node 업그레이드

1. worker node들을 한번에 업그레이드
   • application 접근 불가
2. worker node 하나씩 업그레이드
   • 업그레이드할 노드의 pod들을 옮겨놓고, 업그레이드 후 다시 옮김 → worker node 마다 반복
3. 새 노드를 추가하고 원래 노드를 evict
   • 클라우드 환경에서 편리하게 가능

upgrade command

참고: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

업그레이드시 도움이 되는 정보

$ kubeadm upgrade plan

 

클러스터 업그레이드시 kubeadm 버전을 업그레이드 해준다

$ apt-get upgrade -y kubeadm=1.18.0-00

클러스터 업그레이드

$ kubeadm upgrade apply v1.18.0

→ 위 과정을 진행한 후, kubectl get nodes 시 클러스터 버전이 변하지 않은 걸 볼 수 있음 → api 서버 버전 자체가 아닌, api 서버에 등록된 kubelet 의 버전이기 때문

 

kubelet 업그레이드

$ apt-get upgrade -y kubelet=1.18.0-00
$ systemctl restart kubelet

worker node 업그레이드

1. worker node 하나씩 접속/진행
2. kubectl drain node1(--ignore-daemonsets) 을 통해 pod 이동
3. kubectl cordon node1 을 통해 pod을 unschedulable 로 마크
4. kubeadm 업그레이드(apt-get upgrade -y kubeadm=1.18.0-00)
5. kubelet 업그레이드 (apt-get upgrade -y kubelet=1.18.0-00)
6. 새로운 버전 설정 및 kubelet 재시작
   • kubeadm upgrade node config --kubelet-version v1.18.0
   • systemctl restart kubelet
7. 다시 스케줄될 수 있도록 설정 (kubectl uncordon node1)
8. → worker node마다 과정 반복

→ 잘 안되면 apt install kubeadm=1.20.0-00 같이 apt install 로 설치

---

Backup and Restore Methods

declarative 방식 (파일로 object를 생성하는 것)이 backup 에 있어서는 imperative보다 선호됨

모든 리소스를 백업하는 방법으로 모든 object 를 yaml 파일로 남기는 방법이 있음

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

ETCD

• ETCD는 클러스터의 모든 정보를 저장하고 있음
• 위 방법처럼 리소스를 백업하는 대신, ETCD 서버 자체를 백업하는 방법이 있음
• ETCD 서버는 마스터 노드에 host 됨
• 모든 데이터가 저장되는 data directory 는 etcd.service 에서 설정 가능 → --data-dir

ETCD Snapshot

스냅샷 생성

$ ETCDTL_API=3 etcdctl snapshot save snapshot.db

• ls 시 현재 directory에 스냅샷 파일이 생성된 것을 확인할 수 있음

스냅샷 상태 확인

$ ETCDTL_API=3 etcdctl snapshot status snapshot.db

ETCD Backup

참고: https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/

$ ETCDCTL_API=3 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 /tmp/snapshot-pre-boot.db

• 위 옵션은 etcd 프로세스에서 확인 가능

$ ps -aux | grep -i etcd

• --cert-file
• --key-file
• --trusted-ca-file
• 위 명령어로 나오지 않는다면, /etc/kubernetes/manifests/etcd.yaml 에 spec.containers.command 필드를 보면 ETCD 실행시 사용되는 parameter들을 확인할 수 있음

ETCD Restore

1. kube-apiserver 중지

$ service kube-apiserver stop

 

2. etcd restore

$ ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --data-dir /var/lib/etcd-from-backup

• etcd config 파일을 보면 해당 --data-dir가 적용된 걸 볼 수 있음

$ ETCDCTL_API=3 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 \
    --name=master \
    --data-dir /var/lib/etcd-from-backup \
    --initial-cluster-token=etcd-cluster-1 \
    --initial-cluster=master=https://127.0.0.1:2380 \
    --initial-advertise-peer-urls=https://127.0.0.1:2380 \
    snapshot restore /tmp/snapshot-pre-boot.db # 백업파일경로

3. daemon reload

$ systemctl daemon-reload

4. etcd 재시작

$ service etcd restart

5. kube-apiserver 재시작

$ service kube-apiserver start

참고: https://github.com/jonnung/cka-practice/blob/master/5-cluster-maintenance.md

• ETCD POD은 기본적으로 static POD 이기 때문에, /etc/kubernetes/manifests/etcd.yaml 에 생성 파일이 존재함
• 해당 yaml 에서 restore시 자신이 지정한 --data-dir /var/lib/etcd-from-backup 로 수정해주어야함

volumes:
- hostPath:
    path: /etc/kubernetes/pki/etcd
    type: DirectoryOrCreate
  name: etcd-certs
- hostPath:
    path: /var/lib/etcd-from-backup # 이 부분 수정
    type: DirectoryOrCreate
  name: etcd-data

• 수정 후 저장하면 쿠버네티스가 ETCD POD을 재생성하고, data 디렉토리로 /var/lib/etcd-from-backup 를 바라보게 됨

---

[DevOps/Kubernetes] - [CKA] CKA 자격증 준비 자료 정리 6 (Security)

[CKA] CKA 자격증 준비 자료 정리 6 (Security)