26장 rolling update·PDB·autoscaling을 하나의 가용성 계약으로 본다

FlowNote Deployment는 replica 3, maxUnavailable: 0, maxSurge: 1이다. 새 Pod가 Ready가 되기 전 old Pod를 줄이지 않아 application capacity를 보존하지만 rollout 순간 Pod가 4개가 되어 quota와 compute 여유가 필요하다.

Kubernetes API object 이름으로는 PDB가 PodDisruptionBudget, HPA가 HorizontalPodAutoscaler다. 약어만 외우지 말고 각각 eviction 허용량과 replica 목표를 조정하는 서로 다른 control loop라는 점을 구분한다.

PDB의 maxUnavailable: 1은 node drain 같은 voluntary disruption에서 동시에 unavailable 가능한 Pod를 제한한다. node hard failure까지 막는 보증이 아니다. replica 1에 PDB 0을 두면 maintenance가 영원히 막힐 수 있다.

HPA는 CPU utilization 65%를 목표로 3~10 replica를 조정한다. CPU request가 utilization 계산의 분모이므로 request가 부정확하면 scaling도 왜곡된다. HPA가 Pod를 늘리면 Auto Mode가 unschedulable Pod를 보고 node를 만들 수 있다. 이 두 control loop의 시간차를 고려해 latency spike와 cold start를 관찰한다.

kubectl apply -f examples/k8s/20-availability.yaml
kubectl -n flownote get deployment,hpa,pdb
kubectl -n flownote rollout restart deployment/flownote
kubectl -n flownote rollout status deployment/flownote

test environment에서는 의도적으로 readiness를 실패시키고 rollout이 멈추는지, 이전 Pod가 traffic을 유지하는지 본다. 단, production에서 장애 실험을 즉흥적으로 하지 않는다.