정적 사이트용 쿠버네티스 Liveness·Readiness 프로브: 404 트래픽 차단

Source: Dev.to

정적 사이트(HTML, CSS, JS)를 nginx:alpine 이미지로 컨테이너화했고, 쿠버네티스에 배포했습니다. 로컬에서는 정상적으로 동작합니다.
그런데 롤링 업데이트 중에 502 Bad Gateway 혹은 무작위 Connection Refused 오류가 발생합니다.
왜일까요? 쿠버네티스는 Nginx 프로세스가 실행 중이라는 이유만으로 컨테이너가 “alive”(살아있음)하고 “ready”(준비됨)하다고 판단합니다—설정이 깨졌거나 디스크가 가득 찼거나 사이트가 아직 컴파일 중이라도 말이죠.

이 문제를 해결해봅시다. 정적 사이트용 Liveness와 Readiness 프로브에 대한 유일한 가이드를 소개합니다.

정적 사이트의 황금 규칙

• Readiness: “지금 이 Pod에 트래픽을 보내도 될까?” (시작 및 재로드 시점)
• Liveness: “Pod이 복구 불가능하게 손상됐는가?” (심각한 충돌)

정적 사이트에서는 Readiness를 시작 지연에, Liveness를 교착 상태에 사용합니다.

순진한 접근법 (절대 하지 마세요)

# 예시 코드

• 느린 빌드: 사이드카 혹은 initContainer를 사용해 거대한 정적 번들을 받아오면, 프로브가 즉시 실패합니다. 쿠버네티스는 다운로드가 끝나기도 전에 Pod를 강제 종료합니다.
• 404 발생: 루트 /는 200 OK를 반환하지만, CSS 번들 main.css가 손상된 경우는 어떨까요? Pod는 “alive”하지만 사이트는 깨져 있습니다.

올바른 설정: 두 개의 프로브와 하나의 헬스 엔드포인트

Nginx(정적 사이트의 왕)를 사용한다면 nginx.conf에 다음을 추가합니다:

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ /index.html;
}

# 헬스 체크 엔드포인트
location /health {
    access_log off;
    return 200 "healthy\n";
    add_header Content-Type text/plain;
}

Step 2: Readiness Probe 설정 (“느린 시작자”)

# 예시 yaml

Step 3: Liveness Probe 설정 (“좀비 킬러”)

중요: Liveness 프로브는 Readiness보다 더 보수적으로 설정해야 합니다. 짧은 고부하 스파이크 동안 쿠버네티스가 Pod를 재시작하지 않도록 해야 합니다.

# 예시 yaml

흔히 저지르는 정적 사이트 실수

정적 사이트 99%는 커스텀 /health 엔드포인트에 대한 기본 httpGet만 있으면 충분합니다. exec 명령어나 TCP 프로브로 복잡하게 만들 필요 없습니다.

당신만의 정적 사이트 공포 이야기가 있나요? 댓글로 알려주세요. 🚀