12. CKA udemy 강의 정리 - Section 6 [Cluster Maintenance]

0. OS Upgrades

"pod-eviction-timeout"

kube-controller-manager에 전달된 인수(default=5분) 보다 더 길게 Unknown 또는 False로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 되는 것

 

유지 관리의 목적으로 클러스터의 일부 소프트웨어를 업그레이드 하거나 패치를 적용할 때 등의 이유로 노드가 다운되었을 때 

노드 안에 있는 파드에 접근할 수 없게 된다.  이때 노드가 죽어있는 시간이 5분 이상일 경우, 쿠버네티스는 노드가 죽었다고 판단하여 노드 안에 있는 파드는 종료 된다.

만일 replicaset의 자동복구화 기능 때문에 파드 수가 유지된다면 해당 파드는 다른 노드에서 파드를 기동시켜주기 때문에 영향 받지 않는다. 

 

pod-eviction-timeout 설정

마스터 노드의 kube-system 네임스페이스에 있는 kube-controller-manager-master을 edit

# static pod이므로 이를 생성한 yaml 수정해야함. defualt는 5분
spec.containers.command.- kube-controller-manager- --pod-eviction-timeout=5m0s

 

1. Kubernetes Software Versions

버전

쿠버네티스는 가장 최근 3개의 마이너 버전만 지원한다. 1.10버전에 있었다고 가정할때 1.12가 릴리즈 되었다고 해보자
이때 바로 1.12로 업그레이드 시키는 것보다 한단계 한단계씩 차례차례로 업그레이드 하는 것을 추천한다고 한다. 

 

쿠버네티스 버전은 x.y.z로 표현된다. x(메이저).y(마이너).z(시맨틱용어에 따른 패치)
z는 버그 수정되고 릴리즈 되기 때문에 업데이트가 빈번하고, 이후 순서대로 업데이트 기간이 잦다. 

ETCD CLUSTER과 CoreDNS만 자체 버전이 있다.

kube-apiserver가 버전의 주축이 되고 ETCD CLUSTER과 CoreDNS만 자체 버전이 있어서 버전이 다를 수 있다. 

• kubelet : kubelet은 kube-apiserver보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원 
  예) kube-apiserver가 1.26 이면, kubelet은 1.26, 1.25 및 1.24 을 지원한다.
• kube-controller-manager, kube-scheduler, cloud-controller-manager : kube-apiserver보다 최신일 수 없으며, 실시간 업그레이드를 지원하기 위해 최대 1단계 낮은 마이너 버전까지 지원함. 
  예) kube-apiserver 인스턴스는 1.26 및 1.25 이면, 1.25 에서 지원.
• kubectl : kube-apiserver은 1.26 이면, kubectl은 1.27, 1.26 및 1.25 을 지원
• kube-proxy : 
  
  • kube-proxy(버전이 1.24)는 반드시 kubelet과 동일한 마이너 버전(버전이 1.24)이어야 한다.
  • kube-proxy는 반드시 kube-apiserver 보다 최신 버전이면 안 된다.
  • kube-proxy는 kube-apiserver(버전이 1.24~1.26) 보다 2단계 낮은 마이너 버전 이내여야 한다.

2. Cluster Upgrade Process

업그레이드 방법

쿠버네티스 환경을 어떻게 구성하였는가에 따라 업그레이드 방법이 다양하다.

• 구글의 GKE, AWS의 EKS등의 kubernete를 지원하는 cloud의 경우
  • 간단한 클릭 몇번으로 업그레이드 가능
• kubeadm과 같은 도구로 클러스터 배포한 경우 

kubeadm upgrade plan
kubeadm upgrade apply

• The hard way
  • 다른 컴포넌트들을 수동으로 업그레이드 해야한다. 

아래 예시는 kubeadm을 통한 업그레이드 방법이다.

 

업그레이드 프로세스  (2단계)

• 마스터 노드(컨트롤 플레인) 업그레이드
  • 마스터 노드(컨트롤 플레인)가 업그레이드 되는 동안에는 api서버와 같은 컨트롤 플레인 구성요소, 스케줄러 및 컨트롤러 관리자가 다운된다.  워커 노드는 다운되지 않지만, 마스터노드에 있는 컴포넌트들이 다운되기 때문에 kubectl(통상 마스터에 존재) 사용하여 클러스터에 접근 할 수 없다. -> 파드 자동 복구 및 생성이 되지 않음
  • 클러스터 업그레이드 전에 kubeadm부터 최신 버전으로 업그레이드 해야한다. 
• 워커노드 업그레이드(3)
  • 모든 노드 한번에 업그레이드, 순차적으로 업그레이드, 클라우드 환경에서 새로운 노드를 추가하고 이전 버전노드는 삭제하는 방법
  • kubelet은 kubeadm으로 설치가 불가능하다. kubectl이 없을 경우 kubelet만 업그레이드

순서: 마스터 노드 업그레이드 -> 워커노드 업그레이드 (모든 노드는 업그레이드 전 drain, 업그레이드 후 uncordon을 실행)

1. [마스터 노드/워커노드]  drain
2. [마스터 노드/워커노드] 의 kubeadm 업그레이드
3. [마스터 노드/워커노드] 의 kubectl, kubelet 업그레이드
4. [마스터 노드/워커노드]  uncordon

명령어

$kubectl drian [노드명]

• 노드에서 실행 중인 파드를 다른 노드로 옮겨 재시작 시키고, 해당 노드를 unschedulable하게 만든다. 
• 업그레이드 중인 노드 내부에는 데몬셋을 제외한 파드가 없어야 하고 새로운 파드 생성 시 업그레이드 중인 노드에 스케줄링이 되면 안되기 때문에 업그레이드 전 해당 명령을 수행해야 한다.

$ kubectl uncordon [노드명]

• 해당 노드를 schedulable하게 만든다. 
• 해당 명령은 단순히 스케줄링만 허가하기 때문에, drain시 다른 노드로 배치되었던 파드가 다시 돌아오지는 않는다. 

 

업그레이드 예시 (1.11 -> 1.13)

1) Master Node

업그레이드 정보 확인하기
출력되는 문구에는 현재 클러스터의 각 노드들의 버전이 몇이고, 지금 가진 kubeadm의 버전으로 업그레이드가 가능한지 여부를 확인할 수 있다.

kubeadm upgrade plan

컨트롤 플레인 컴포넌트를 수동으로 업그레이드 해야한다.

1.11 버전이기 때문에 차례로 업데이트 하기 위해서 1.12버전으로 업그레이드를 해야한다.

 

업그레이드 적용시키기

# upgrade 관련 정보 확인
# 클러스터 버전, kubeadm 버전, 최신 버전, 컴포넌트별 버전 등
kubeadm upgrade plan

# 파드 이전, unschedulable
kubectl drain master

# kubeadm 업그레이드
apt-get upgrade -y kubeadm-1.12.0-00

# 클러스터 업그레이드
kubeadm upgrade apply v1.12.0
'''[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.0". Enjoy!'''

# kubelet 업그레이드
apt-get upgrade -y kubelet-1.12.0-00 #kubelet이 있는 경우 업데이트 
systemctl restart kubelet #kubelet재시작

# 업데이트가 종료되었으므로, master노드를 다시 schedulable하게 만듦
kubectl uncordon master

2) Worker Node

# node-1 파드 이전, unschedulable 변경
kubectl drain node-1

# kubeadm 업그레이드
apt-get upgrade -y kubeadm-1.12.0-00

# kubelet 업그레이드
apt-get upgrade -y kubelet-1.12.0-00
kubeadm upgrade node config --kubelet-version v1.12.0
systemctl restart kubelet

# node-1 schedulable 변경
kubectl uncordon node-1

---

참고

1. 클러스터 유지보수