← 문제 라이브러리
K8s 고급 K8S 1192 · 21분

새 노드에 배포하면 liveness probe가 기동 중인 앱을 계속 죽임

주문 조회 서비스(JVM)에 인터넷에서 찾은 공개 예제의 probe 설정을 그대로 붙여 두었습니다.

검수된 문제무료
시나리오

주문 조회 서비스(JVM)에 인터넷에서 찾은 공개 예제의 probe 설정을 그대로 붙여 두었습니다. 평소에는 몇 달째 잘 돌았는데, 오늘 노드 교체 작업으로 파드들이 새 노드로 옮겨 가자 재시작이 끝없이 반복되며 주문 조회가 절반쯤 실패합니다. 새 노드에는 이미지와 로컬 캐시가 없어 기동이 평소보다 한참 느립니다. 담당자는 메모리가 부족해 죽는 것 같다며 메모리 limit을 두 배로 올리자고 합니다. 같은 이미지를 쓰는 기존 노드의 파드는 아직 멀쩡히 돌고 있습니다.

단서
kubectl describe pod (이벤트 일부)
Warning  Unhealthy  kubelet  Liveness probe failed: Get "http://10.2.3.14:8080/actuator/health/liveness": dial tcp 10.2.3.14:8080: connect: connection refused
Normal   Killing    kubelet  Container app failed liveness probe, will be restarted

Last State:  Terminated
  Reason:    Error
  Exit Code: 143
kubectl logs <pod> --previous (끝부분)
00:00:03 INFO  Starting OrderQueryApplication
00:00:21 INFO  Warming product cache (1,200,000 entries)...
# 약 25초 뒤 SIGTERM, 'Started OrderQueryApplication' 로그는 한 번도 없음
# 기존 노드에서는: Started OrderQueryApplication in 78.4 seconds
probe 설정
livenessProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

과제 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.

먼저 볼 것
  • 기동 중 실패와 운영 중 실패 구분하기
  • liveness·readiness·startup probe의 역할 차이
점검 체크리스트
  1. kubectl describe pod 에서 종료 이유(liveness 실패인지 OOMKilled인지)
  2. --previous 로그에서 기동이 어디까지 갔는지
  3. probe가 첫 실패로 컨테이너를 죽이기까지 걸리는 시간 계산(initialDelay + period × failureThreshold)