1.9.3 On Demand Node Cycling로 Worker Nodes 업데이트/업그레이드 하기
Worker Nodes의 속성을 변경하거나 OS 버전을 변경하기 위해 Node Pool을 업데이트 하면, 이후 새로 생성되는 Node에 변경된 값이 적용됩니다. 기존 Worker Nodes에는 변경 적용되지 않기 때문에, 적용을 위해서는 Drain 작업을 포함한 재생성 작업이 필요합니다.
또한 쿠버네티스 버전 업그레이드를 위해 Node Pool의 쿠버네티스 버전을 업그레이드 한 경우에도 Node Pool내에 새로 새로 생성되는 Node는 새 버전으로 생성되지만, 기존 Worker Nodes에는 변경 적용되지 않기 때문에, 적용을 위해서는 Drain 작업을 포함한 업그레이드 작업이 필요합니다.
관련 내용은 1.7 Kubernetes 지원 버전 및 업그레이드을 참조 바랍니다. 여기서 설명하는 Node Cycling은 Enhanced Cluster에서만 사용 가능하기 때문에, OKE Basic Cluster에서는 기존 방법대로 업그레이드를 수행합니다.
Node Cycling을 통해 기존 Worker Nodes 업그레이드
기존 Node Pool의 Worker Nodes를 사이클링하는 방식이기 때문에 1.7 Kubernetes 지원 버전 및 업그레이드에서 설명한 내용중 in-place 방식 업그레이드와 동일한 방식입니다.
예시는 동일한 상황으로, 1.25.4 버전을 사용 중에 새로운 버전이 출시되었다고 가정합니다
Control Plane 업그레이드
Worker Nodes를 업그레이드 하기전에 Control Plane을 먼저 업그레이드 합니다.
Worker Node 업그레이드 - in-place 업그레이드
OKE 클러스터가 업그레이드로 인해 Control Plane 만 업그레이드 된 상태이며, 이제 Node Pool 단위로 업그레이드 가능한 상태입니다.
Node Pool 업그레이드
업그레이드 하려는 Node Pool의 상세 페이지로 이동합니다.
수정을 위해 Edit를 클릭하면, 오른쪽에 수정 페이지가 뜹니다.
Version 항목에, 클러스터 버전과 Node Pool의 버전이 표시되며, 업그레이드 가능한 버전이 표시됩니다.
클러스터와 동일한 1.26.2로 선택하고 Save Change를 클릭하여 저장합니다.
Resources > Work Requests에 가서 보면, 15초 정도 지난뒤 Node Pool 업그레이드가 완료됩니다.
아직 실제 Worker Node가 업그레이드 된 것은 아닙니다.
Node Cycling
Node Pool 상세화면에서 Cycle nodes를 클릭합니다.
Cycle nodes 방식을 지정할 수 있습니다.
- Maximun surge: 동시에 최대 몇 개의 새 노드를 만들지 지정합니다.
- Maximun unavailable: 동시에 최대 몇 개 기존 노드를 사용불가 상태로 변경해도 괜찮을 지를 지정합니다.
- 예시
- 새 노드 생성후, 기존 노드 제거 방식: 새 노드가 준비되면, 기존 노드를 제거(cordons, drains, terminates) 방식이라, 안정적이지만, 일시적으로 Node Pool에 지정한 노드 수 보다 더 많은 상황이 발생하여, 비용이 추가 발생할 수 있습니다. 설정 예, maxSurge=1, maxUnavailable=0
- 기존 노드 제거후, 새 노드 생성 방식: 기존 노드를 제거(cordons, drains, terminates)하고 새 노드를 생성하는 방식이라, Node Pool에 지정한 노드 수에서, 즉 비용이 늘어나지 않는 상태에서 업데이트/업그레이드 할 수 있음. 하지만, 기존 노드에서 제거된 Pod들은 나머지 기존 노드에 이관된 상태라, 새 노드가 준비되는 시점에는 해당 노드에는 애플리케이션 Pod가 위치하지 않을 수 도 있음. 설정 예, maxSurge=1, maxUnavailable=1
- 미입력시, 디폴트 값은 maxSurge=1, maxUnavailable=0 입니다.
maxSurge=1, maxUnavailable=0로 Cycle nodes를 수행합니다.
설정한 규칙에 따라 업그레이드된 버전으로 새 노드가 먼저 생성됩니다.
새 노드가 준비가 되면, 기존 노드 하나가 스케줄링에서 제외됩니다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION 10.0.10.143 Ready node 2m v1.26.2 10.0.10.184 Ready,SchedulingDisabled node 25h v1.25.4 10.0.10.191 Ready node 25h v1.25.4 10.0.10.239 Ready node 25h v1.25.4다음으로 기존 노드 하나가 삭제되기 시작합니다.
$ kildong@cloudshell:~ (ap-chuncheon-1)$ kubectl get nodes NAME STATUS ROLES AGE VERSION 10.0.10.143 Ready node 3m22s v1.26.2 10.0.10.191 Ready node 25h v1.25.4 10.0.10.239 Ready node 25h v1.25.4기존 노드 하나가 삭제되면, 다시 새 노드를 생성합니다.
새 노드가 준비되면, 다시 스케줄링 제외, 노드 삭제 순으로 동일한 순서로 모든 노드를 업그레이드 할때까지 계속 진행됩니다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION 10.0.10.142 Ready node 2m12s v1.26.2 10.0.10.143 Ready node 7m6s v1.26.2 10.0.10.191 Ready node 25h v1.25.4 10.0.10.239 Ready,SchedulingDisabled node 25h v1.25.4
업그레이드가 완료되었습니다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION 10.0.10.142 Ready node 13m v1.26.2 10.0.10.143 Ready node 17m v1.26.2 10.0.10.184 Ready node 7m37s v1.26.2 $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-docker-hub-5bfd857f89-djnmx 1/1 Running 0 6m23s 10.244.2.130 10.0.10.184 <none> <none> nginx-ocir-86bcf7867c-db8xb 1/1 Running 0 11m 10.244.2.2 10.0.10.142 <none> <none>
Node cycling을 이용하면, 매뉴얼로 직접 이관하는 것에 비해 자동화된 업그레이드를 통해 보다 편리하게 업그레이드 할 수 있습니다.
안정적으로 업그레이드하면서, 노드 수가 많을 때 빠르게 진행하기 위해서는 배포된 애플리케이션의 특성에 따라 설정이 필요합니다. 또한 Disruption Budget for your Application을 통해 애플리케이션 자체이 대해서도 안정적인 이관에 대해 사전에 고려하여 설계하여야 합니다.
Node Cycling을 통해 기존 Worker Nodes 업데이트
Node Pool 수정 페이지에서 Kubernetes 버전이외에, 노드의 OS Image, 노드 태그, 속성, SSH Key 등록 등 Node Pool의 설정을 변경할 수 있습니다. Node Pool 속성 변경을 Worker Nodes에 적용하는 것도 Node Cycling을 통해 기존 Worker Nodes 업그레이드와 동일한 과정입니다.
이 글은 개인으로서, 개인의 시간을 할애하여 작성된 글입니다. 글의 내용에 오류가 있을 수 있으며, 글 속의 의견은 개인적인 의견입니다.