설명
컨테이너 프로세스가 떠 있다고 해서 애플리케이션이 정상 동작하는 것은 아닙니다. 내부 데드락, 무한 대기, 응답 불가 상태가 생기면 프로세스는 살아 있어도 서비스가 멈출 수 있습니다. livenessProbe는 이런 상태를 확인해 kubelet이 컨테이너를 재시작하도록 돕습니다.
모든 워크로드에 반드시 필요한 것은 아닙니다. 프로세스 종료에 적용되는 restartPolicy와는 별개이며, 잘못된 검사는 정상 컨테이너의 반복 재시작이나 연쇄 장애를 유발할 수 있습니다.
잠재적 영향
- 재시작으로 복구할 수 있는 장애가 수동 대응 전까지 지속될 수 있습니다.
- 공유 의존 서비스의 장애를 liveness 실패로 판단하면 여러 인스턴스가 불필요하게 재시작될 수 있습니다.
해결 방법
- HTTP, TCP나 exec 등 지원되는 방식으로 재시작이 필요한 상태를 확인하는 livenessProbe를 구성하세요. 외부 의존 서비스의 상태만으로 실패하게 만들지 마세요.
- 실제 초기화와 복구 시간을 고려해 주기·임계값을 조정하고 필요하면 startup probe를 사용하세요. 트래픽 준비 여부는 readiness probe로 구분해 확인하세요.
예시
변경 후는 /health 경로를 별도로 구현한 애플리케이션을 전제로 합니다. 기본 nginx 이미지는 이 경로를 자동 제공하지 않으므로 필요한 설정을 준비해야 합니다. 기존 이미지와 시간 값은 예시입니다.
변경 전
yaml
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
응답 불가 상태를 확인하는 liveness 검사가 없습니다. 프로세스가 종료되면 restartPolicy는 별도로 적용됩니다.
변경 후
yaml
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: nginx:1.27
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 10
periodSeconds: 10
HTTP 검사 실패가 임계값까지 계속되면 컨테이너 재시작을 유도합니다. 경로와 시간 설정은 실제 복구 기준에 맞아야 합니다.