PostgreSQL 컨테이너 liveness·readiness 설정 핵심

소개

쿠버네티스에서 데이터베이스는 단순한 애플리케이션과 다르다. 상태를 유지하고 연결성을 보장해야 하며, 프로브 설정이 이를 좌우한다. 이 글은 k8s postgres liveness probe와 postgres readiness probe 설정을 중심으로 기본 개념과 실무에서 쓰이는 예시를 설명한다.

프로브의 기본 개념

liveness와 readiness의 차이

liveness는 컨테이너가 살아있는지 여부를 판단한다. 프로세스가 응답하지 않으면 재시작 대상이 된다. 반면 readiness는 요청을 받을 준비가 되었는지 판단한다. 준비되지 않은 파드는 서비스 엔드포인트에서 제외된다.

왜 PostgreSQL에 중요할까

데이터베이스는 초기 시작 시간이 길고 간헐적 잠김이 발생할 수 있다. 잘못된 프로브는 불필요한 재시작이나 트래픽 손실을 초래한다. 따라서 k8s postgres liveness probe와 postgres readiness probe 설정을 상황에 맞게 조정해야 한다.

프로브 타입과 권장 선택

쿠버네티스는 tcpSocket, httpGet, exec 등 세 가지 기본 타입을 제공한다. PostgreSQL에는 tcpSocket과 exec(pg_isready 또는 psql 체크)가 주로 사용된다. 간단한 연결 확인에는 tcpSocket, 상세 상태 검증에는 exec 사용이 적절하다.

liveness 프로브 설정 예시

liveness는 프로세스가 멈췄는지 확인하기 위한 용도이다. 포트 열림만으로 충분한 경우 tcpSocket을 사용한다. 다음은 기본적인 liveness 설정 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: postgres
spec:
  containers:
  - name: postgres
    image: postgres:13
    ports:
    - containerPort: 5432
    livenessProbe:
      tcpSocket:
        port: 5432
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 6

위 설정은 초기 지연을 길게 잡고 실패 임계값을 높여 불필요한 재시작을 줄이는 방향이다. 데이터베이스 초기 부팅 속도에 따라 initialDelaySeconds를 더 늘릴 수 있다.

readiness 프로브 설정 예시

readiness는 실제로 쿼리를 처리할 준비가 되었는지 확인한다. pg_isready는 클라이언트의 연결 수락 가능 여부를 빠르게 검사한다. 아래는 pg_isready를 이용한 exec 예시이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:13
        readinessProbe:
          exec:
            command:
            - sh
            - -c
            - pg_isready -U postgres
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 6

exec 방식은 단순 연결 확인보다 더 정확한 결과를 준다. 그러나 컨테이너에 필요한 유틸리티가 포함되어 있어야 한다는 점을 고려해야 한다.

설정 팁과 주의사항

초기 지연과 임계값 조정

PostgreSQL은 WAL 복구, 대용량 데이터 로딩 등으로 시작이 느릴 수 있다. initialDelaySeconds를 서비스 특성에 맞춰 충분히 크게 설정하고 failureThreshold를 높여 일시적 문제로 인한 재시작을 방지한다.

검사 방식 선택

• tcpSocket: 가장 가볍고 빠르다. 연결 가능성만 확인한다.
• exec (pg_isready): 연결 수용 가능 여부를 정확히 체크한다.
• exec (psql -c 'SELECT 1'): 내부 쿼리 실행까지 확인하여 더 엄격한 검사 가능.

트래픽 전환과 데이터 일관성

레플리카 구조에서는 readiness가 특히 중요하다. 준비되지 않은 파드를 서비스에서 제거하면 쓰기/읽기 트래픽이 안정적으로 분배된다. 프로브가 너무 느려서 준비 상태 전송이 지연되면 연결 실패가 발생할 수 있다.

모니터링과 알림

프로브 결과만으로 모든 상황을 판단하기 어렵다. Prometheus 같은 모니터링 도구로 liveness/readiness 실패 빈도, 재시작 횟수, 연결 지연 등을 수집하여 경고 조건을 설정하는 것이 바람직하다.

실무 권장 설정 요약

• 초기 시작이 느린 환경에서는 initialDelaySeconds를 충분히 크게 설정.
• failureThreshold를 늘려 일시적 오류에 대한 관용성 확보.
• 가능하면 pg_isready 또는 간단한 쿼리로 readiness를 확인.
• 모니터링과 경고를 병행하여 문제의 원인을 빠르게 파악.

마무리

k8s postgres liveness probe와 postgres readiness probe 설정은 서비스 안정성에 직접적인 영향을 준다. 기본 개념을 이해하고 컨테이너 이미지, 초기 부하, 레플리카 구성에 맞춰 프로브 타입과 파라미터를 조정하면 더 안정적인 운영이 가능하다. 적용 후에는 모니터링을 통해 설정을 점진적으로 튜닝하는 접근이 권장된다.