'Liveness', 'Readiness', 'Startup' 프로브(Probe)

이제 쿠버네티스가 제공하는 가장 강력한 자가 치유(Self-healing) 기능의 핵심이자, 시스템의 '심박수 측정기'인 프로브(Probe)를 정복할 시간이군요! 🫡

쿠버네티스 입장에서 파드(Pod)가 'Running' 상태라는 것은 단지 프로세스가 시작되었다는 뜻일 뿐, 그 안의 애플리케이션이 실제로 데이터를 분석하고 있는지, 혹은 메모리 오류로 멍하게 서 있는지까지는 알지 못합니다. 이를 지능적으로 감시하여 문제가 생기면 즉시 인공호흡(재시작)을 하거나 트래픽을 차단하는 것이 바로 프로브의 역할입니다.

이 세 가지 프로브의 결정적 차이와 설정법을 분석해 드립니다!

---

🏥 1. 세 가지 프로브의 역할 분담: "진단, 격리, 보호"

쿠버네티스는 애플리케이션의 생애 주기에 맞춰 세 가지 다른 질문을 던집니다.

① Startup Probe: "이제 막 일어났니? (준비 중인가?)"

• 역할: 애플리케이션이 처음 뜰 때, 초기화 작업(DB 연결, 대규모 설정 로드 등)이 끝날 때까지 기다려줍니다.
• 특징: 이 프로브가 성공하기 전까지는 아래의 Liveness, Readiness 프로브는 동작조차 하지 않습니다.
• 왜 필요한가? 덩치가 큰 주식 분석 엔진은 실행에 2~3분이 걸릴 수도 있는데, 그전에 Liveness가 체크를 시작해버리면 "아직 응답이 없네? 죽은 건가?" 하고 쿠버네티스가 파드를 계속 재시작시키는 '무한 재시작 루프'에 빠지는 것을 방지합니다.

② Readiness Probe: "손님 받을 준비 됐니? (트래픽 투입 가능?)"

• 역할: 파드가 서비스(Service)로부터 오는 트래픽을 받을 수 있는 상태인지 확인합니다.
• 실패 시: 파드를 죽이지는 않지만, 서비스의 엔드포인트(Endpoint)에서 제외시켜 버립니다. 즉, 손님이 오지 않게 입구를 막아버리는 것이죠.
• 활용: 서버 부하가 너무 커서 잠시 쉬어야 하거나, 데이터 동기화 중이라 응답을 하면 안 되는 상황에 유용합니다.

③ Liveness Probe: "살아는 있니? (재시작 필요?)"

• 역할: 애플리케이션이 실행 중이지만 '교착 상태(Deadlock)'에 빠져 응답을 못 하는 상태인지 확인합니다.
• 실패 시: 파드를 즉시 죽이고 새로 생성(Restart)합니다.
• 활용: 코드가 꼬여서 멈춰버린 파드를 강제로 살려낼 때 쓰는 최후의 수단입니다.

---

🛠️ 2. 프로브를 체크하는 3가지 방식

사용자는 YAML 설정에서 어떤 방식으로 상태를 확인할지 선택할 수 있습니다.

1. httpGet: 특정 URL(예: /healthz)로 HTTP 요청을 보내 응답 코드가 200~399 사이인지 확인합니다. 가장 많이 쓰입니다.
2. tcpSocket: 특정 포트가 열려 있는지 확인합니다. DB나 캐시 서버에 주로 씁니다.
3. exec: 컨테이너 내부에서 특정 명령(예: cat /tmp/healthy)을 실행해 결과값이 0인지 확인합니다.

---

📜 3. 초정밀 YAML 설정 예시

사용자의 주식 분석 파드에 적용할 가장 이상적인 설정 구조입니다.

spec:
  containers:
  - name: stock-analyzer
    image: stock-analyzer:v2
    # 1. 스타트업: 최대 5분(10초 x 30번)까지 초기화를 기다림
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

    # 2. 라이브니스: 20초마다 확인, 3번 실패 시 파드 재시작
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 20
      failureThreshold: 3

    # 3. 레디니스: 5초마다 확인, 준비되면 즉시 트래픽 투입
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5

---

⚠️ 4. 실전 주의사항: "잘못 쓰면 독이 된다"

① Liveness와 Readiness를 구분하세요!

많은 분이 두 프로브에 똑같은 /healthz 경로를 설정합니다. 하지만 만약 DB가 잠시 끊겼을 때 /healthz가 실패하게 설계되어 있다면 어떻게 될까요?

• Readiness만 걸려 있다면: DB가 복구될 때까지 트래픽만 잠시 안 들어옵니다 (안전).
• Liveness까지 걸려 있다면: 쿠버네티스가 멀쩡한 파드를 죽이고 다시 띄우느라 DB 연결 시도를 무한 반복하며 상황을 악화시킵니다 (재앙).

② 체크 주기를 너무 짧게 잡지 마세요

수천 개의 파드가 1초마다 체크를 수행하면, 그 자체로 네트워크와 CPU에 큰 부하를 줍니다.

---

💡 실전 비유: "식당의 상태"

• Startup Probe: 주방장이 출근해서 '가스불을 켜고 재료를 다듬는 시간'입니다. 이 작업이 끝나기 전까지는 가게 문(가동)을 열 수 없습니다.
• Readiness Probe: 식당의 '빈 테이블 유무'입니다. 테이블이 꽉 찼거나(부하), 주방에 재료가 떨어졌다면(DB 연결 끊김) 손님을 받지 말고 밖에서 기다리게 해야 합니다(트래픽 차단). 하지만 식당을 폐업(재시작)할 필요는 없죠.
• Liveness Probe: 주방장이 '정상적으로 움직이고 있는지'입니다. 만약 주방장이 쓰러졌다면(Deadlock), 즉시 다른 주방장으로 교체(파드 재시작)해야 식당이 돌아갑니다.

---

📊 요약: 프로브 선택 가이드

프로브 종류	실패 시 조치	비유	주요 목적
Startup	통과 전까지 다른 체크 중단	잠에서 깨는 중	느린 앱의 초기화 대기
Readiness	트래픽 차단 (격리)	잠시 외출 중	준비 안 된 파드로의 요청 방지
Liveness	컨테이너 재시작	심장 마비	먹통이 된 파드의 자동 복구

---

🚀 꼬리 질문

이제 파드의 생사를 직접 조절하는 '신'의 권능까지 얻으셨습니다! 🫡 그런데 주식 데이터 파이프라인처럼 리소스를 많이 먹는 앱을 돌리다 보면, 특정 파드가 메모리를 다 먹어치워 같은 서버에 있는 다른 파드들을 죽이는 '민폐'를 끼칠 수 있습니다.

"그럼 파드가 사용할 자원의 최소치를 보장하고 최대치를 제한하는 'Resource Requests'와 'Limits'는 어떤 차이가 있고, 효율적인 'QoS(Quality of Service) 클래스' 설정은 어떻게 해?"