[Kubernetes] Cordon & Drain
🚀 Cordon & Drain
🚀 Cordon
스케줄링 금지
kubectl cordon <NODENAME>스케줄링 허용
kubectl uncordon <NODENAME>
vagrant@k8s-node1 ~/schedule/affinity kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready control-plane,master 10d v1.22.8
node2 Ready <none> 10d v1.22.8
node3 Ready <none> 7d23h v1.22.8node의 STATUS를 주의깊게 보자
vagrant@k8s-node1 ~/schedule/affinity kubectl cordon node2
node/node2 cordonednode2에 cordon을 걸었다.
vagrant@k8s-node1 ~/schedule/affinity kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready control-plane,master 10d v1.22.8
node2 Ready,SchedulingDisabled <none> 10d v1.22.8
node3 Ready <none> 7d23h v1.22.8상태에 SchedulingDisabled가 추가됐다. 이제부터 스케줄러가 해당 노드에 배치시키지 않는다.
해당 노드에 이미 존재하는 파드들은 무관하며 새롭게 생성되는 파드부터 적용된다.
vagrant@k8s-node1 ~/schedule/affinity kubectl create -f myweb-a.yaml
replicaset.apps/myweb-a created
vagrant@k8s-node1 ~/schedule/affinity kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myweb-a-5dqcz 1/1 Running 0 7s 10.233.90.103 node1 <none> <none>
myweb-a-6j4xt 1/1 Running 0 7s 10.233.92.162 node3 <none> <none>
nfs-client-provisioner-758f8cd4d6-wpjbt 1/1 Running 0 2d22h 10.233.92.110 node3 <none> <none>node에 cordon이 걸린 상태에서 새로운 파드를 생성해보았다.
복제본이 2개이며 antiAffinity 정책과 SchedulingDisabled에 의해 node1, 3에 배치될 수 밖에 없다.
vagrant@k8s-node1 ~/schedule/affinity kubectl create -f myweb-b.yaml
replicaset.apps/myweb-b created
vagrant@k8s-node1 ~/schedule/affinity kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myweb-a-5dqcz 1/1 Running 0 94s 10.233.90.103 node1 <none> <none>
myweb-a-6j4xt 1/1 Running 0 94s 10.233.92.162 node3 <none> <none>
myweb-b-9rz7w 0/1 ContainerCreating 0 3s <none> node3 <none> <none>
myweb-b-wg8vv 1/1 Running 0 3s 10.233.90.104 node1 <none> <none>
nfs-client-provisioner-758f8cd4d6-wpjbt 1/1 Running 0 2d22h 10.233.92.110 node3 <none> <none>myweb-b 또한 affinity 정책에 의해 myweb-a와 같은 노드에 배치될 수 밖에 없다.
vagrant@k8s-node1 ~/schedule/affinity kubectl scale rs myweb-a --replicas=3
replicaset.apps/myweb-a scaled
vagrant@k8s-node1 ~/schedule/affinity kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myweb-a-5dqcz 1/1 Running 0 4m23s 10.233.90.103 node1 <none> <none>
myweb-a-6j4xt 1/1 Running 0 4m23s 10.233.92.162 node3 <none> <none>
myweb-a-rzxsf 0/1 Pending 0 4s <none> <none> <none> <none>
myweb-b-9rz7w 1/1 Running 0 2m52s 10.233.92.163 node3 <none> <none>
myweb-b-wg8vv 1/1 Running 0 2m52s 10.233.90.104 node1 <none> <none>
nfs-client-provisioner-758f8cd4d6-wpjbt 1/1 Running 0 2d22h 10.233.92.110 node3 <none> <none>이때 복제본 개수를 3으로 늘리면 myweb-a 파드끼리는 antiAffinity이기 때문에 마지막에 생성된 myweb-a-rzxsf는 반드시 node2에 배치될 수 밖에 없다.
하지만 현재 node2는 스케줄링이 금지되어 있어 Pending상태가 된다.
vagrant@k8s-node1 ~/schedule/affinity kubectl describe po myweb-a-rzxsf
Warning FailedScheduling 3m24s default-scheduler 0/3 nodes are available: 1 node(s) were unschedulable, 2 node(s) didn't match pod anti-affinity rules.describe 명령을 통해 확인하면 1개의 노드는 스케줄링이 안되고 2개는 anti-affinity 때문에 안된다는 메세지가 출력된다.
즉, node1, 3은 anti-affinity 때문에 안되고 node2는 스케줄링이 금지된 것이다.
vagrant@k8s-node1 ~/schedule/affinity kubectl uncordon node2
node/node2 uncordoned
vagrant@k8s-node1 ~/schedule/affinity kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myweb-a-5dqcz 1/1 Running 0 9m52s 10.233.90.103 node1 <none> <none>
myweb-a-6j4xt 1/1 Running 0 9m52s 10.233.92.162 node3 <none> <none>
myweb-a-rzxsf 1/1 Running 0 5m33s 10.233.96.143 node2 <none> <none>
myweb-b-9rz7w 1/1 Running 0 8m21s 10.233.92.163 node3 <none> <none>
myweb-b-wg8vv 1/1 Running 0 8m21s 10.233.90.104 node1 <none> <none>
nfs-client-provisioner-758f8cd4d6-wpjbt 1/1 Running 0 2d22h 10.233.92.110 node3 <none> <none>이제 uncordon하면 스케줄링이 정상적으로 완료되어 node2에 배치되는 것을 볼 수 있다.
🚀 Drain
Cordon → 기존 파드를 제거
kubectl drain <NODENAME> --ignore-daemonsets vagrant@k8s-node1 ~/schedule/affinity kubectl drain node2
node/node2 cordoned
DEPRECATED WARNING: Aborting the drain command in a list of nodes will be deprecated in v1.23.
The new behavior will make the drain command go through all nodes even if one or more nodes failed during the drain.
For now, users can try such experience via: --ignore-errors
error: unable to drain node "node2", aborting command...
There are pending nodes to be drained:
node2
error: cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): ingress-nginx/ingress-nginx-controller-2jrhn, kube-system/calico-node-ft9lf, kube-system/kube-proxy-zmm5n, kube-system/nodelocaldns-mq9nm, metallb-system/speaker-fnpnbThere are pending nodes to be drained:
만약 노드가 3개 있는데 node2에 drain을 걸면
복제본을 다루는 컨트롤러에 의해 만들어진 파드는 삭제되었다가 affinity 정책에 위반되지 않는다면 다른 노드에 생성된다.
이렇게 복제본을 제공하는 워크로드들은 아무 상관이 없으나,
데몬셋이나 파드들은 노드에서 쫓아내면 다른 노드로 갈 수가 없다.
따라서 출력된 에러를 해석해보면
데몬셋에 의해 관리되는 ingress-nginx/ingress-nginx-controller-2jrhn,
kube-system/calico-node-ft9lf, kube-system/kube-proxy-zmm5n, kube-system/nodelocaldns-mq9nm, metallb-system/speaker-fnpnb와 같은 파드들은 해당 노드에서 drain되면 다른 노드에서 생성되지 않아 삭제할 수 없다는 것이다.
이 문제를 무시하기 위해서는 --ignore-daemonsets 옵션을 사용한다.
kubectl drain node2 --ignore-daemonsets
해당 명령을 실행하면 node2의 모든 파드들이 evicting하며 node2에 자동으로 cordon이 걸린다.
따라서 drain은 기존 파드들을 삭제하고 동시에 cordon 시켜버린다.
더이상 새로운 파드가 배치되면 안되기 때문이다.
node2에 패치를 하거나 커널 업데이트를 해야 할 때 안전하게 작업하기 위해서 drain을 시켜주는 것이 좋다.
즉, RS, RC, Deploy, STS에 의해 생성되는 파드는 다른 노드에 재배치하고 그다음 패치하고 재부팅하는 것이 안전하다.
한가지 꼭 기억해야할 것은 drain 하게되면 자동으로 cordon이 걸리는데 시스템을 재부팅해도 여전히 cordon 상태이다.
따라서 배치를 시키기 위해서는 반드시 uncordon 해줘야한다.