컨테이너 liveness probe 필요성 점검

설명

컨테이너 프로세스가 살아 있어도 내부 데드락이나 무한 대기로 애플리케이션이 응답하지 않을 수 있습니다. liveness probe는 이런 상태를 확인해 kubelet이 컨테이너를 다시 시작하도록 돕습니다.

모든 워크로드에 반드시 필요한 것은 아닙니다. 프로세스 종료에 대한 restart_policy와는 별개이며, 잘못된 검사는 정상 컨테이너의 반복 재시작이나 연쇄 장애를 유발할 수 있습니다.

잠재적 영향

재시작으로 복구할 수 있는 장애가 수동 대응 전까지 지속될 수 있습니다.
공유 의존 서비스의 장애를 liveness 실패로 판단하면 여러 인스턴스가 불필요하게 재시작될 수 있습니다.

해결 방법

HTTP, TCP 또는 exec 등 지원되는 방식으로 재시작이 필요한 상태를 확인하는 liveness_probe를 구성하세요. 외부 의존 서비스의 상태만으로 실패하게 만들지 마세요.
실제 초기화와 복구 시간을 고려해 주기·임계값을 조정하고 필요하면 startup probe를 사용하세요. 트래픽 준비 여부는 readiness로 구분해 확인하세요.

예시

변경 후는 /health 경로를 별도로 구현한 애플리케이션을 전제로 합니다. 기본 nginx 이미지가 이 경로를 자동 제공하지 않으므로 설정을 준비하고 유지보수되는 이미지를 사용하세요.

변경 전

hcl

resource "kubernetes_pod" "app" {
  metadata {
    name = "app"
  }

  spec {
    container {
      name  = "app"
      image = "nginx:1.27"

      port {
        container_port = 80
      }
    }
  }
}

변경 후

hcl

resource "kubernetes_pod" "app" {
  metadata {
    name = "app"
  }

  spec {
    container {
      name  = "app"
      image = "nginx:1.27"

      port {
        container_port = 80
      }

      liveness_probe {
        http_get {
          path = "/health"
          port = 80
        }

        initial_delay_seconds = 10
        period_seconds        = 10
      }
    }
  }
}

설명:

변경 전: 응답 불가 상태를 판단하는 liveness 검사가 없습니다. 프로세스가 종료되면 restart_policy는 별도로 적용됩니다.
변경 후: HTTP 검사 실패가 지속되면 컨테이너 재시작을 유도합니다. 임계값과 경로가 실제 복구 기준에 맞아야 합니다.

컨테이너 liveness probe 필요성 점검

설명

잠재적 영향

해결 방법

예시

변경 전

변경 후

참조