Running Workloads With Controllers

목표

Deployment, ReplicaSet, DaemonSet, StatefulSet 네 컨트롤러의 차이를 손으로 확인하고, 롤링 업데이트 파라미터를 조정해 실제 롤아웃과 롤백을 수행합니다.

왜 중요한가

시험에서 "이미지를 올리고 문제가 생기면 되돌려라" 는 단골 문제입니다. 그런데 되돌리기가 되는 이유를 모르면 함정에 빠집니다. rollout undo 는 마법이 아니라 레플리카 0 으로 남아 있는 옛 ReplicaSet 을 다시 키우는 것입니다. 그래서 revisionHistoryLimit 을 0 으로 두면 되돌릴 수 없고, 이미지를 손으로 되돌리면 되돌린 게 아니라 리비전이 하나 더 쌓입니다.

네 컨트롤러의 선택 기준도 명확합니다. 서로 구분할 필요 없는 복제본이면 Deployment, 노드마다 정확히 하나면 DaemonSet, 이름·순서·볼륨이 고정돼야 하면 StatefulSet 입니다. StatefulSet 이 헤드리스 서비스를 요구하는 이유는 파드마다 DNS 이름을 주기 위해서입니다.

단계

1. 네임스페이스 cka-workloads 를 만들고 Deployment web 을 만든다. 이미지 nginx:1.25, 레플리카 2.
2. web 을 레플리카 4로 스케일하고 4/4 Ready 를 확인한다.
3. web 의 전략을 RollingUpdate 로 두고 maxSurge: 2, maxUnavailable: 0, revisionHistoryLimit: 3 으로 설정한다.
4. Deployment api 를 만든다 (이미지 nginx:1.25, 레플리카 3). 그 다음 이미지를 nginx:1.27 로 교체하고 롤아웃이 끝날 때까지 기다린다.
5. api 의 롤아웃 히스토리를 /root/cka-workloads/history.txt 에 저장한다. 리비전이 2개 이상 보여야 한다.
6. api 를 직전 리비전으로 되돌린다. 되돌린 뒤 이미지는 다시 nginx:1.25 여야 한다.
7. cka-workloads 에 DaemonSet node-agent 를 만든다. 이미지 busybox:1.36, 컨테이너가 바로 종료되지 않도록 오래 도는 명령을 준다. 모든 노드에 하나씩 Ready 여야 한다.
8. 헤드리스 서비스 db-headless (clusterIP None, 포트 5432, 셀렉터 app=db)를 만들고, StatefulSet db 를 만든다. serviceName db-headless, 레플리카 2, 이미지 nginx:1.27, updateStrategy 는 RollingUpdate 에 partition: 1. 2/2 Ready 를 확인한다.

참고

• kubectl rollout status deployment/api -n cka-workloads 로 완료를 기다릴 수 있습니다.
• kubectl get rs -n cka-workloads 로 리비전마다 ReplicaSet 이 남는 것을 눈으로 확인해 보세요.
• 흔한 실수 1: 6단계에서 set image 로 옛 태그를 다시 넣는 것. 그건 롤백이 아니라 새 리비전입니다.
• 흔한 실수 2: 8단계에서 StatefulSet 의 파드 라벨과 헤드리스 서비스 셀렉터를 어긋나게 두는 것. app=db 로 맞춰야 합니다.

Deployment 만들기

네임스페이스 cka-workloads 를 만들고 Deployment web 을 만든다. 이미지 nginx:1.25, 레플리카 2.

kubectl create deployment 로 뼈대를 만들고 필요한 값만 고치는 편이 빠릅니다. 이미지 태그까지 정확히 맞춰야 합니다.

스케일하고 Ready 확인하기

web 을 레플리카 4로 스케일하고 4/4 Ready 를 확인한다.

scale 명령이 가장 빠르지만 매니페스트를 고쳐 적용해도 됩니다. status.readyReplicas 가 목표치에 닿을 때까지 잠시 걸립니다.

롤링 업데이트 파라미터 조정하기

web 의 전략을 RollingUpdate 로 두고 maxSurge: 2, maxUnavailable: 0, revisionHistoryLimit: 3 으로 설정한다.

strategy.rollingUpdate 아래에 두 값이 들어갑니다. 정수와 퍼센트 모두 쓸 수 있지만 이번에는 정수여야 합니다. revisionHistoryLimit 은 strategy 바깥, spec 바로 아래입니다.

이미지 교체하고 롤아웃 완료 기다리기

Deployment api 를 만든다 (이미지 nginx:1.25, 레플리카 3). 그 다음 이미지를 nginx:1.27 로 교체하고 롤아웃이 끝날 때까지 기다린다.

set image 로 바꾸면 새 ReplicaSet 이 생깁니다. rollout status 로 완료를 기다리세요. 채점은 새 리비전의 존재와 observedGeneration 을 봅니다.

리비전 히스토리 확인하고 저장하기

api 의 롤아웃 히스토리를 /root/cka-workloads/history.txt 에 저장한다. 리비전이 2개 이상 보여야 한다.

rollout history 는 REVISION 컬럼이 있는 표를 출력합니다. 리비전이 2개 이상 보여야 되돌릴 수 있다는 뜻입니다.

이전 리비전으로 되돌리기

api 를 직전 리비전으로 되돌린다. 되돌린 뒤 이미지는 다시 nginx:1.25 여야 한다.

이미지를 손으로 되돌리지 마세요. 그러면 되돌린 것이 아니라 새 리비전을 하나 더 만든 것이고, 채점은 그 차이를 봅니다. rollout 되돌리기 명령을 쓰세요.

DaemonSet 배포하기

cka-workloads 에 DaemonSet node-agent 를 만든다. 이미지 busybox:1.36, 컨테이너가 바로 종료되지 않도록 오래 도는 명령을 준다. 모든 노드에 하나씩 Ready 여야 한다.

DaemonSet 은 replicas 를 쓰지 않습니다. 노드마다 하나씩 뜨는지 status 의 desiredNumberScheduled 와 numberReady 로 확인합니다. 컨테이너가 바로 끝나지 않도록 오래 도는 명령을 주세요.

헤드리스 서비스와 StatefulSet 묶기

헤드리스 서비스 db-headless (clusterIP None, 포트 5432, 셀렉터 app=db)를 만들고, StatefulSet db 를 만든다. serviceName db-headless, 레플리카 2, 이미지 nginx:1.27, updateStrategy 는 RollingUpdate 에 partition: 1. 2/2 Ready 를 확인한다.

StatefulSet 의 serviceName 은 반드시 존재하는 헤드리스 서비스를 가리켜야 합니다. partition 은 updateStrategy.rollingUpdate 아래에 있고, 그 서수 이상만 업데이트한다는 뜻입니다.