Section 6 : Cluster Maintenance

1. Operating System Upgrade

 

 만약 여러개의 노드 중 하나가 다운됐다면, 쿠버네티스는 어떤 행동을 할까요?
1. 노드가 즉시 다시 시작된다면, kubelet process가 시작되고, pod가 다시 online으로 돌아옵니다.

2. 만약 node 다운이 5분 되었다면, 해당 노드에서 pod가 종료됩니다. 쿠버네티스가 죽은 것으로 여기고, pod가 replicaSet으로 생성되었다면, 다른 노드에 다시 생성할 것입니다.

 

 

 pod-eviction-timeout이라고 알려진 controller manager에 놓여진 것은, 기본적으로 5분이라는 디폴트 값을 설정해 놓습니다.

다시 말해 노드가 오프라인이 될 때마다 마스터 노드는 최대 5분까지 기다립니다. 만약 pod-eviction-timeout 명령이 내려진 후 노드가  다시 활성되면, 노드는 공백이 됩니다.

 

파란색 pod는 replicaSet으로 생성되었다면, 다른 노드에 새 pod를 생성합니다. 따라서 노드에서 실행할 maintenance 작업이 있다면, 그리고 노드에서 실행되는 workLoads가 다른 replicaSet을 가지고 있다면, 단기간은 중단되어도 괜찮습니다.

 

하지만 그 노드가 5분 후 다시 온라인 상태가 될지는 확신할 수 없기에, 더 안전한 방법이 있습니다. 모든 작업을 Drain할 수 있습니다. 작업이 클러스터 내 다른 노드로 이동할 수 있도록요. 엄밀히 말하면 다른 노드로 옮긴게 아니라, 한 노드를 Drain하면 해당 노드에서 pod가 정상 종료되고, 다른 노드에 재현됩니다. 

 

그럼 다운되었던 노드는, 다른 pod를 Drain 했으니 재부팅합니다. 다시 온라인에 접속되어도 여전히 제한이 되어있는데, uncordon의 명령을 통해 제한을 풀 수 있게 됩니다. cordon이라는 명령도 있는데 Drain과 달리 기존 노드에서 pod를 종료하거나 이동하지 않고, 단순히 해당 노드에서 새 pod가 스케줄링 되지 않도록 합니다.

 

 

정리

 

Drain : 적용된 노드는 ScheDulingDisabled 상태가 되고, 이후 새롭게 생성되는 어떤 Pod도 해당 노드에 생성되지 않는다. 예외적으로, drain을 한 후에 CoreDNS POD를 제외한, kube-system 네임스페이스에 존재하는 Pod들은 사라지지 않고 남아있다. 이유는, kube-apiserver, kube-proxy 같은 pod들은 kubelet이 local에 저장된 pod의 설정 파일을 읽어 자체적으로 관리하는 Static Pod이기 때문이다.

 

Cordon : 현재 노드에 배포된 pod는 그대로 유지, 추가적인 pod의 배포를 제한하는 명령이다.

 

Uncordon : Drain 후 ScheDulingDisabled 상태를 제거하여 노드에 Pod가 정상적으로 스케줄링 될 수 있도록 복구하는 명령이다.

 

 

2. Kubernetes Releases

 

쿠버네티스 버전은 3부분을 나뉩니다. (v1.11.3 예로 들면)

 

 

 첫 번째가 major 버전, 다음이 minor 버전, 다음이 patch 버전입니다. 새로운 기능을 갖춘 minor 버전이 몇 달마다 출시되는 반면 중요한 버그 fix는 patch에서 더 자주 출시됩니다. 컨트롤 플레인에는 버전 번호가 다른 구성 요소들이 있습니다. 이는 ETCD Cluster, CoreDNS인데, 각각 다른 프로젝트로 고유 버전을 갖고 있습니다. 

 

 

3. Cluster upgrade

 kube-apiserver 컨트롤 플레인의 주요 구성요소이고 다른 구성요소들과 통신하는 구성요소이기 때문에 어떤 다른 구성요소도 kube-apiserver보다 높은 버전으로 되어 있어서는 안 돼요. 하지만 kubectl은 편차가 허용되는 값 내에서 이보다 높을 수 있습니다. 

1) 클러스터 업그레이드는 두 가지 주요 단계를 수반하죠.

먼저 마스터 노드를 업그레이드하세요. 그다음 작업자 노드를 업그레이드하세요. 마스터가 업그레이드되는 동안 컨트롤 플레인의 구성 요소는 API 서버 스케줄러나 컨트롤러 관리자와 같은 건 잠시 다운돼요. 마스터가 다운된다고 클러스터 상의 작업자 노드와 앱이 영향을 받는 건 아니죠. 작업자 노드에 호스트된 모든 작업은 평소처럼 사용자를 돕습니다.

 

 

2) Worker 노드 업그레이드는 다양한 전략이 사용됩니다.

 

1) 한꺼번에 업그레이드 : 하지만 Pod가 다운되면 사용자는 앱에 접속할 수 없습니다. 가동 중지 시간이 필요하게 되는 것이죠.

2) 한번에 노드 하나씩 업그레이드 : 하나의 노드씩 업그레이드 하면서 작업을 대기중인 노드와 업그레이드가 완료된 노드에게 분배하여 진행됩니다.

3) 클러스터에 새 노드를 추가 : 특히 클라우드 환경에서 편리하고, 새 노드를 프로비전 후 오래된 것을 해제할 수 있기에 편합니다. 

 

 

4. Backup and Restore

 

1) deploy, pod 등 definition file을 git repo로 백업 및 복원, 모든 리소스를 백업하는 방법으로 모든 object를 yaml 파일로 남기는 방법이 있다. ( kubectl get all -all-namespaces -o yaml > all-deploy-services.yaml )

 

2) ETCD Backup

ETCD 클러스터는 모든 object 정보를 저장하고 있고, 1) 처럼 리소스를 백업하는 대신, ETCD 서버 자체를 백업하는 방법이 있다. ETCD 서버는 마스터 노드에 호스팅 된다. 또한 모든 데이터가 저장되는 위치를 확인할 수 있다.

 

또한 ETCD 서버를 snapshot 형태로 저장할 수 있다.