requests와 limits의 차이

이 둘을 헷갈리면 클러스터가 이상하게 동작합니다.

• requests — "최소 이만큼은 보장해 달라". 스케줄러가 이 값을 기준으로 파드를 어느 노드에 배치할지 정합니다. 너무 크게 잡으면 노드에 자리가 없어 Pending에 빠집니다.
• limits — "이 이상은 못 쓴다". 메모리가 이 값을 넘으면 컨테이너가 OOMKilled로 강제 종료됩니다. CPU는 죽이지 않고 속도만 제한(throttle)합니다.

파드가 자꾸 재시작된다면 kubectl describe pod에서 OOMKilled가 보이는지 먼저 확인하세요. 메모리 limit이 너무 낮다는 뜻입니다.

liveness와 readiness는 역할이 다릅니다

• readiness — "지금 트래픽 받을 준비가 됐나?" 실패하면 Service가 이 파드로 요청을 보내지 않습니다. 재시작하지는 않습니다.
• liveness — "살아있나?" 실패하면 컨테이너를 재시작합니다.

기동이 느린 앱에 liveness만 짧게 걸면, 아직 뜨는 중인데 죽었다고 판단해 무한 재시작 루프에 빠집니다. 그래서 initialDelaySeconds를 넉넉히 주거나 startupProbe를 따로 쓰는 것이 안전합니다.

이미지 태그에 latest를 쓰지 마세요

nginx:latest처럼 쓰면 지금 어떤 버전이 떠 있는지 알 수 없고, 롤백도 불가능합니다. 버전 태그나 커밋 해시를 쓰는 것이 원칙입니다.

적용과 확인

kubectl apply -f deployment.yaml
kubectl rollout status deployment/이름 -n 네임스페이스
kubectl get pods -n 네임스페이스 -w
kubectl logs -f deployment/이름 -n 네임스페이스

# 문제가 생겼을 때 되돌리기
kubectl rollout undo deployment/이름 -n 네임스페이스

이 Deployment를 외부에 노출하려면 Service 생성기와 Ingress 생성기를 이어서 사용하세요.