Readiness Probe 미구성

설명

readinessProbe는 컨테이너가 실제로 요청을 받을 준비가 되었는지 확인하는 설정입니다. 이 값이 없으면 애플리케이션이 아직 초기화 중이어도 서비스 트래픽이 들어갈 수 있습니다.

롤링 업데이트나 재시작 상황에서는 준비되지 않은 파드를 일반적인 Service의 트래픽 대상에서 제외하도록 적절한 readiness probe를 구성하세요. readiness 실패는 컨테이너 재시작이나 직접 파드 접근 차단을 뜻하지 않습니다.

잠재적 영향

• 준비되지 않은 컨테이너로 요청이 전달돼 오류가 발생할 수 있습니다.
• 배포 중 일시 장애나 응답 실패가 늘어날 수 있습니다.
• 초기화 시간과 실제 서비스 가능 시점을 분리해 제어하기 어렵습니다.

해결 방법

• 요청을 처리하는 서비스 컨테이너에 readinessProbe를 설정하세요.
• 애플리케이션 특성에 맞게 HTTP, TCP, command 등 적절한 검사를 선택하세요. TCP 연결 성공만으로 업무 요청 처리가 가능한지는 별도로 판단하세요.
• 초기화 시간에 맞춰 주기와 지연 시간을 조정하고 배포·장애 상황에서 실제 Service 트래픽을 시험하세요.

예시

기존 TCP 점검 예제입니다. 사용 가능한 이미지를 선택하고 서비스가 실제로 8080 포트에서 수신하도록 구성하세요. 지연과 점검 주기는 예시입니다.

변경 전

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
spec:
  containers:
    - name: goproxy
      image: k8s.gcr.io/goproxy:0.1
      ports:
        - containerPort: 8080
      livenessProbe:
        tcpSocket:
          port: 8080

변경 후

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
spec:
  containers:
    - name: goproxy
      image: k8s.gcr.io/goproxy:0.1
      ports:
        - containerPort: 8080
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        tcpSocket:
          port: 8080

설명:

• 변경 전: liveness probe만 있으며 별도 readiness 기준이 없어 초기화가 끝나기 전에 Service 대상이 될 수 있습니다.
• 변경 후: TCP 연결 성공을 준비 기준으로 사용합니다. 준비되지 않은 동안 일반적인 Service 경로에서 제외되지만 직접 접근을 차단하는 보안 제어는 아닙니다.

참조

• CWE-754
• Kubernetes 문서