K8S Operating System Upgrade

이번 포스팅에서는 클러스터 내의 노드 패치 또는 업그레이드시 노드를 unschedule하는 방법에 대해 다룬다.  

 

다음 상황을 가정한다. 

 

나는 쿠버네티스 클러스터 내 node를 패치하거나 업그레이드하고 싶다. 

 

이때 노드 내의 포드는 노드 업그레이드 시 문제가 생길 수 있기 때문에 우선 노드를 unscheule한 상태로 만들어준다. 

 

이때 노드내 포드가 만약 replicas로 지정된 포드라면 노드에 장애가 생겨도 self-healing되어 문제가 없으므로 

노드 내 모든 포드를 지운 후, unschedulable하게 해도 괜찮다. 

 

하지만 replicaset이 지정되어 있지 않은 포드가 노드 내 존재한다면

노드 내 포드만 그대로 놔두고 노드를 Unschedule하게 한다.   

 

이번 포스팅에서는 Replicas가 설정되어 있을 때의 노드 업데이트, 그렇지 않은 경우의 노드 업데이트에 대해 실습해본다. 

 

 

 

1. replicas가 설정되어 있는 경우 

 

다음과 같이 두개의 노드가 있다. 

 

 

 

먼저 blue라는 어플리케이션은 replicas=3인 디플로이먼트에 의해 node01에 배포된다. 

 

 

 

node01을 업데이트 할것이므로 drain 커맨드를 통해 node01을 unschedule해준다.  

drain 커맨드를 이용하면 node01는 unschedule상태로 바뀌고,

node01에 존재하던 모든 포드들은 replicaset에 의해 다른 node로 이동된다. 

 

 

 

Replicas에 의해 controlplane node에 새로 배포되었다.

(이 때 controlplane node의 taint 설정은 없다.)

 

 

 

node01의 업그레이드를 마친 후,

node01을 schedulable하게 하고 pods의 위치를 확인해보자.

 

 

 

node01에서 schedule이 가능함에도 불구하고 controlplane node에 pod가 존재한다. 

이는 포드 생성시에 node01로 schedule이 되기 때문에 그런것이므로

다른 포드를 생성해 node01로 schedule이 되는지 확인해보자. 

hr-app pod는 node01로 잘 스케줄링이 된다. 

 

 

 

 

2. Replicas가 설정되어 있지 않은 경우

 

위 실습에서 이어서 실습한다. 

 

다시 한번 node01을 drain command를 통해서 unschedule상태로 만들어보자.

 실패한다. 

 

이는 Replicaset이 지정되어 있지 않은 포드 때문에 실패한다. 

 

만약 강제적으로 drain한다면 hr-app포드는 사라질 것이다. 

 

hr-app 포드가 중요한 포드라면 노드를 unschedule 상태로 만들고 포드는 지우거나 이동시키지 않는게 이상적이다.  

 

이때 cordon을 사용하여 node01을 unschedule하게 하자. 

 

 

 

hr-app pod는 node01에 여전히 존재하고 node01은 unschedule한 상태로 이제 업데이트가 하기 좋다