쿠버네티스 내 컨테이너 상태 진단의 필요성

대규모 클라우드 환경에서 애플리케이션이 여러 노드에 분산 배치될 때, 컨테이너 내부의 실제 동작 상태를 파악하는 것은 핵심입니다. 네트워크 불안정, 메모리 부족, 또는 코드 오류 등으로 인해 컨테이너가 비정상적으로 종료되거나 응답하지 못하는 상황이 발생할 수 있습니다. 쿠버네티스는 이러한 문제를 해결하기 위해 kubelet이 컨테이너를 정기적으로 점검하는 프로브 (Probe) 메커니즘을 제공합니다. 이를 통해 시스템은 자가 치유 기능을 수행하고 서비스의 가용성을 유지할 수 있습니다.

주요 프로브의 역할과 구분

쿠버네티스는 컨테이너의 상태에 따라 세 가지不同类型的 진단探针을 정의합니다.

1. 운영 상태 확인 (Liveness Probe)

컨테이너 프로세스가 실제로 살아있는지 여부를 판별합니다. 진단 결과 실패로 판단될 경우, kubelet은 해당 컨테이너를 강제 종료시키며, 설정된 restartPolicy에 따라 재시작합니다. 이는 무한루프에 빠진进程이나 죽은 프로세스를 자동으로 복구하는 데 목적이 있습니다.

2. 서비스 제공 준비도 확인 (Readiness Probe)

컨테이너가 외부 트래픽을 수용할 준비가 되었는지 확인합니다. 실패 시에는 컨테이너를 종료하지는 않지만, 해당 Pod 의 IP 는 서비스 엔드포인트 (Service Endpoints) 에서 제거됩니다. 이로 인해 로드 밸런서는 트래픽을 해당 Pod 로 보내지 않아, 배포 중이거나 초기화 중인 서버가 사용자 요청을 받지 않도록 보호합니다.

3. 스타트업 확인 (Startup Probe)

느린 시작 시간을 가진 애플리케이션을 위해 추가되었습니다. 성공 신호가 올 때까지 생존/준비 프로브는 일시적으로 무시되며, 이 기간 동안 Pod 은 재시작되지 않습니다. 설정되지 않은 경우 기본값은 성공으로 간주됩니다.

진단 방법론과 기술적 구현

프로브는 컨테이너와의 통신 방식에 따라 세 가지 방법으로 분류됩니다.

• EXEC: 컨테이너 내부 shell 에서 명령어 실행. 리턴 코드가 0 일 때 정상.
• TCP Socket: 특정 포트에 TCP 연결 시도. 연결 수립 성공 시 정상.
• HTTP GET: HTTP 요청 전송. 상태 코드가 2xx 또는 3xx 범위에 있으면 정상.

각 진단은 Success, Failure, Unknown 중 하나의 결과를 반환하며, Unknown 인 경우 액션은 취해지지 않습니다.

설정 파라미터 최적화

다음 매개변수를 조정하여 진단의 민감도와 오버헤드를 균형 있게 맞출 수 있습니다.

실제 구성 예시 및 시나리오

경우 1: 파일 기반 생존 탐지 (Exec)

여러분은 컨테이너가 정기적으로 상태 파일을 생성하고 삭제하도록 설정하여 작동 여부를 확인할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: health-monitor-exec
  labels:
    app: backend-service
spec:
  containers:
  - name: worker-node
    image: busybox:1.35
    args:
    - /bin/sh
    - -c
    - |
      echo "Starting service simulation";
      while true; do 
        touch /var/state/alive; sleep 15; rm -f /var/state/alive; sleep 10;
      done
    livenessProbe:
      exec:
        command: ["/bin/sh", "-c", "test -f /var/state/alive"]
      initialDelaySeconds: 5
      periodSeconds: 10

동작 분석: 위 설정에서 컨테이너는 15 초마다 상태를 체크하고 파일을 만듭니다. 파일이 없으면 리턴 코드가 1 이 되어 Liveness Probe가 실패합니다. 이 경우 kubelet 은 컨테이너를 킬링하고 재시작합니다. 위 YAML 은 주기적인 재시작을 유발하는 시나리오로 활용됩니다.

경우 2: 웹 서비스 접근성 검증 (HTTP)

웹 서버의 경우 특정 엔드포인트의 HTTP 응답을 확인하는 것이 일반적입니다.

apiVersion: v1
kind: Pod
metadata:
  name: web-server-check
  namespace: prod-env
spec:
  containers:
  - name: nginx-app
    image: nginx:alpine
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /status/api
        port: 80
      initialDelaySeconds: 10
      failureThreshold: 2
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 15

여기서 readinessProbe는 /status/api 경로가 200 대 응답을 반환해야만 서비스를 활성화합니다. 만약 해당 경로가 404 를 반환하면 Pod 은 Running 상태이지만 Ready 가 안되어 Service 에 포함되지 않습니다. 반면 livenessProbe는 루트 경로 (/) 가 끊기지 않았는지 확인하여, 웹 서버가 멈추면 재시작하게 합니다.

경우 3: 포트 레벨 연결 테스트 (TCP)

HTTP 서블러가 아닌 소켓 통신만을 제공하는 애플리케이션의 경우 TCP 연결 여부로 상태를 확인합니다.

apiVersion: v1
kind: Pod
metadata:
  name: database-proxy
spec:
  containers:
  - name: proxy-svc
    image: my-custom-db:latest
    ports:
    - containerPort: 5432
    livenessProbe:
      tcpSocket:
        port: 5432
      initialDelaySeconds: 10
      timeoutSeconds: 5

이 구조는 특정 포트 (5432 번) 로의 커넥션이 통하는지만 확인합니다. 연결이 거부 (Connection Refused) 되면 이상 징후로 간주되고 재시작 트리거가 발생합니다.

라이프사이클 훅의 활용 (postStart 와 preStop)

프로브 외에도 컨테이너의 생명주기 이벤트에 반응하는 훅을 설정할 수 있습니다. postStart는 컨테이너가 시작된 직후 실행되며, preStop는 컨테이너가 정지되기 전에 실행되어 graceful shutdown 을 처리하거나 로그를 남길 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-example
spec:
  containers:
  - name: log-manager
    image: redis:alpine
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'Initialization triggered by postStart' >> /var/log/app.log"]
      preStop:
        exec:
          command: ["sh", "-c", "sleep 10 && echo 'Graceful shutdown signal sent' >> /var/log/app.log"]
    volumeMounts:
    - name: shared-storage
      mountPath: /var/log
  volumes:
  - name: shared-storage
    emptyDir: {}

이러한 설정은 컨테이너가 완전히 삭제되기 전 필수 정리 작업을 수행하거나, 외부 시스템에 알림을 보낼 때 유용하게 사용됩니다. 특히 preStop에서 잠시 대기 (sleep) 시간을 두는 것은 로드밸런서의 세션을 닫아주는 역할을 하여 트래픽 단절을 방지하는 데 효과적입니다.

핵심 요약 표