운영 매뉴얼을 쓰면서 Pod replica를 언제 늘려도 되는지 정리함.
처음에는 replica를 늘리면 HA가 되는 줄 알기 쉬운데, 실제로는 그렇지 않음.
Pod 개수만 늘려도 같은 worker에 몰리면 worker 장애 때 같이 죽을 수 있음.
또 앱이 상태를 가지고 있으면 Pod를 여러 개 띄우는 게 오히려 문제를 만들 수 있음.
먼저 서비스 성격을 나눠야 함.
Stateless
= Pod 안에 중요한 상태를 오래 저장하지 않음
= Pod가 다시 떠도 큰 문제가 없음
= 여러 Pod가 같은 요청을 처리해도 안전함
예:
일반 웹
API 서버
정적 페이지
단순 worker
Stateful
= 데이터, 세션, 파일, DB 상태처럼 중요한 상태를 가짐
= Pod를 막 늘리거나 지우면 문제가 생길 수 있음
예:
DB
Redis
Grafana SQLite
Loki
Prometheus
Alertmanager
replica를 늘려도 되는 후보.
Pod가 로컬 디스크에 중요한 데이터를 저장하지 않음
로그인 세션을 Pod 내부에만 저장하지 않음
여러 Pod가 동시에 떠도 같은 요청을 처리할 수 있음
Service가 여러 Pod로 트래픽을 보내도 문제 없음
ConfigMap이나 Secret을 여러 Pod가 같이 읽어도 괜찮음
반대로 바로 늘리면 위험한 경우.
SQLite 같은 파일 DB를 씀
Pod 내부 emptyDir에 중요한 상태를 저장함
세션 값이 Pod마다 다르면 문제가 됨
DB, Loki, Prometheus, Alertmanager처럼 저장 데이터가 중요함
PVC를 한 Pod만 쓰도록 설계함
leader 선출이나 클러스터링 구조가 없음
Grafana가 대표적인 주의 대상.
현재 구조가 emptyDir + SQLite + 세션 서명값이면 replica를 2로 늘렸을 때 로그인 리다이렉션 문제가 생길 수 있음.
replica를 늘릴 때는 Pod 개수만 보지 않고 배치 노드도 같이 봐야 함.
# 전체 Pod가 어느 노드에 떠 있는지 확인한다.
kubectl get pods -A -o wide
# 특정 namespace의 Pod가 어느 노드에 떠 있는지 확인한다.
kubectl -n <namespace> get pods -o wide
replica 2인데 둘 다 같은 worker에 있으면 worker 장애 때 같이 죽음.
분산 규칙도 바로 강하게 걸면 안 됨.
preferred
= 가능하면 지키는 조건
= 노드나 자원이 부족해도 Pod가 뜰 가능성이 높음
required
= 반드시 지켜야 하는 조건
= 조건을 만족하지 못하면 Pod가 Pending될 수 있음
홈랩처럼 노드 수와 자원이 제한된 환경에서는 처음부터 required를 강하게 걸기보다 preferred부터 보는 게 안전함.
replica 변경 전 기준선 확인.
# 대상 Deployment의 현재 replica와 Pod 배치 상태를 확인한다.
kubectl -n <namespace> get deployment <deployment-name> -o wide
# 대상 Deployment의 selector label을 확인한다.
kubectl -n <namespace> get deployment <deployment-name> \
-o jsonpath='{.spec.selector.matchLabels}{"\n"}'
# 대상 Deployment가 만든 Pod들이 어느 노드에 떠 있는지 확인한다.
kubectl -n <namespace> get pods -l <label-key>=<label-value> -o wide
변경 후에는 Pod 숫자만 보지 않음.
# 대상 Deployment의 replica 수와 준비 상태를 확인한다.
kubectl -n <namespace> get deployment <deployment-name>
# 새 Pod가 어느 노드에 떴는지 확인한다.
kubectl -n <namespace> get pods -l <label-key>=<label-value> -o wide
# Service가 새 Pod를 실제 트래픽 대상으로 보고 있는지 확인한다.
kubectl -n <namespace> get svc,endpointslice -o wide
웹 서비스면 Ingress VIP 직접 확인.
# 외부 DNS와 보호 프록시를 우회하고 Ingress VIP로 직접 HTTPS 응답을 확인한다.
curl -k -I --connect-timeout 3 --max-time 10 \
--resolve "$host:443:192.168.200.49" \
"https://$host/"
정리.
replica는 Pod 개수일 뿐이고, HA는 Pod 개수만으로 완성되지 않음.
먼저 Stateful인지 Stateless인지 나누고, Pod가 여러 노드에 나뉘는지, Service가 Ready Pod를 보는지, 실제 응답이 정상인지까지 확인해야 함.