노드 비우기와 업그레이드 계획 세우기

목표

노드 한 대를 안전하게 비우고 되돌리는 절차를 손으로 수행하고, 버전 스큐 규칙과 카나리 롤아웃 계획을 문서가 아니라 검증 가능한 산출물로 만듭니다.

왜 중요한가

업그레이드 사고의 대부분은 명령을 몰라서가 아니라 순서와 범위를 몰라서 납니다. 되돌릴 수 없는 작업(kubeadm upgrade apply) 앞에는 반드시 etcd 스냅샷이 와야 합니다. 컨트롤 플레인 다운그레이드는 지원되지 않으므로, 잘못됐을 때의 탈출구는 "내리기"가 아니라 "스냅샷으로 복구하기"뿐이기 때문입니다. 범위 문제는 버전 스큐가 담당합니다. kubelet 은 apiserver 보다 낮을 수는 있어도 높을 수 없고, kubectl 만 유일하게 위로 한 칸을 허용합니다. 이 비대칭을 모르면 "kubectl 은 최신으로 써도 되는데 왜 kubelet 은 안 되지" 같은 질문에서 막힙니다. 마지막으로 노드 작업의 3단계(cordon → drain → uncordon)와 PDB 는 짝입니다. PDB 가 없으면 drain 이 서비스를 통째로 내릴 수 있고, PDB 가 지나치게 빡빡하면 drain 이 영원히 끝나지 않습니다.

단계

1. /root/ops/upgrade/out/versions.json 을 만드세요. 최상위 키는 server(v1.x.y 형식의 서버 버전 문자열)와 nodes 입니다. nodes 는 lab-node-0, lab-node-1, lab-node-2 세 개를 키로 갖고 값은 각 노드의 실제 kubelet 버전 문자열이어야 합니다.
2. lab-node-1 만 cordon 하고, 직후의 노드 목록을 /root/ops/upgrade/out/cordon.txt 에 저장하세요. 파일에 lab-node-1 과 SchedulingDisabled 가 보여야 하며 lab-node-0 은 차단되면 안 됩니다. 그리고 /root/ops/upgrade/out/cordon-note.txt 에 cordon 이 이미 떠 있는 파드는 건드리지 않는다는 점을 한 줄로 적으세요.
3. 네임스페이스 ops-upgrade 를 만들고 그 안에 replicas: 3 인 Deployment web(파드 라벨 app=web)을 만드세요. 이어서 PodDisruptionBudget web-pdb 를 같은 네임스페이스에 만들되 spec.minAvailable: 2, spec.selector.matchLabels.app: web 으로 하고 maxUnavailable 은 쓰지 마세요.
4. lab-node-1 을 drain 하고 그 출력을 /root/ops/upgrade/out/drain.txt 에 저장하세요. drain 이 끝난 뒤 ops-upgrade 네임스페이스 파드가 어느 노드에 있는지를 /root/ops/upgrade/out/after-drain.txt 에 세 줄 이상으로 남기세요. 이 파일에 lab-node-1 이 들어 있으면 안 되고 lab-node-0 또는 lab-node-2 가 보여야 합니다.
5. lab-node-1 을 uncordon 하고 그 출력을 /root/ops/upgrade/out/uncordon.txt 에 저장하세요. 세 노드 모두 스케줄 가능 상태여야 하며 Deployment web 의 준비된 복제본이 다시 3개가 되어야 합니다.
6. /opt/lab/fixtures/k8s/skew-template.yaml 을 /root/ops/upgrade/skew.yaml 로 복사한 뒤 answers 아래 물음표를 채우세요. apiserver: "1.34" 는 문제의 전제이므로 그대로 둡니다. 정답 형식은 "1.31" 처럼 마이너 버전 문자열이며, downgrade_supported 만 "yes" 또는 "no" 입니다. 채워야 할 키는 min_kubelet, max_kubelet, max_kubectl, min_kubectl, max_controller_manager, next_upgrade_target, downgrade_supported 입니다.
7. /root/ops/upgrade/runbook.md 를 500바이트 이상으로 쓰세요. 각 항목은 서로 다른 줄에 두고 다음 순서를 지켜야 합니다. (1) etcd 스냅샷 백업, (2) kubeadm upgrade plan, (3) 첫 컨트롤 플레인에서 kubeadm upgrade apply, (4) 나머지 노드에서 kubeadm upgrade node, 그리고 노드 작업 구간에서 drain 이 uncordon 보다 먼저 나와야 합니다. 마이너 버전을 건너뛸 수 없다는 제약도 문장으로 적으세요(예: "한 번에 하나").
8. 세 노드에 upgrade.labhub.io/stage 라벨을 붙이세요. lab-node-0 은 canary, lab-node-1 은 batch1, lab-node-2 는 batch2 입니다. 그리고 /root/ops/upgrade/out/rollout.json 에 계획을 쓰세요. stages 는 길이 3의 배열이고 각 원소는 stage(canary/batch1/batch2)와 nodes(노드 이름 배열)를 갖습니다. 첫 단계는 canary 이며 노드가 정확히 1대여야 하고, 세 노드가 모두 어딘가에 배정돼야 합니다. 최상위에 verify_between_stages 키를 두고 단계 사이에 무엇을 확인할지 적으세요.

참고

• 서버 버전은 kubectl version -o json 의 .serverVersion.gitVersion, 노드의 kubelet 버전은 kubectl get nodes -o json 의 .items[].status.nodeInfo.kubeletVersion 에 있습니다. jq 의 from_entries 를 쓰면 이름을 키로 하는 객체를 쉽게 만들 수 있습니다.
• drain 은 데몬셋 파드나 emptyDir 를 쓰는 파드가 있으면 그냥은 거부합니다. --ignore-daemonsets, --delete-emptydir-data, 필요하면 --force 를 붙이세요.
• 파드가 어느 노드에 있는지는 kubectl get pods -n ops-upgrade -o wide --no-headers 로 한 줄에 하나씩 볼 수 있습니다.
• 라벨에 점과 슬래시가 들어가면 jsonpath 에서 이스케이프가 필요합니다. 확인은 kubectl get nodes -L upgrade.labhub.io/stage 가 가장 간편합니다.
• 흔한 실수 1: 7번 런북에서 kubeadm upgrade apply 와 kubeadm upgrade node 를 한 줄에 같이 쓰는 것. 두 명령의 첫 등장 줄 번호로 순서를 판정하므로 같은 줄이면 통과하지 못합니다. drain 과 uncordon 도 마찬가지입니다.
• 흔한 실수 2: 6번에서 kubectl 의 상한을 apiserver 와 같은 값으로 적는 것. kubectl 은 유일하게 위로 한 칸을 허용합니다.
• 실습 파드는 실습마다 새로 뜨므로 앞 실습의 클러스터 상태는 남아 있지 않습니다. ops-upgrade 네임스페이스와 Deployment 는 3번에서 직접 만드세요. 운영 절차를 기억이 아니라 런북과 매니페스트로 남겨야 하는 이유가 바로 이것입니다.

단계 8개

1. 컨트롤 플레인과 노드 버전 수집하기
2. 노드 한 대만 스케줄 차단하기
3. 가용성을 지킬 PDB 만들기
4. 노드 비우고 파드 이동 확인하기
5. 작업 끝난 노드 되돌리기
6. 버전 스큐 표 채우기
7. 업그레이드 런북 쓰기
8. 카나리 롤아웃 계획 세우고 라벨 붙이기