CNPG 관측·장애 진단·업그레이드

결론부터

정상 여부를 Pod 상태 하나로 판단하지 않고 쿼리·복제·복구 능력을 함께 확인한다.

Pod가 Running이어도 앱은 권한 오류를 겪을 수 있고, SQL이 빨라도 백업은 며칠째 실패 중일 수 있다. 일상 점검에서는 사용자 요청과 데이터 보호의 상태를 분리해서 본다.

이 장에서 처음 나오는 말2개

PodMonitor

Prometheus Operator에 어떤 Pod의 메트릭을 수집할지 알려 주는 리소스.

minor · major 업그레이드

같은 PostgreSQL 주 버전 안의 패치와 주 버전 사이의 데이터 이행을 구분한다.

증상에서 확인 위치로

실습 Cluster가 있는 환경에서 읽기 진단을 시작한다.

kubectl cnpg status -n pg-study study-pg
kubectl get pods,pvc -n pg-study -o wide
kubectl get events -n pg-study --sort-by=.metadata.creationTimestamp

증상	먼저 확인할 것	다음 판단
Pod Pending	노드·anti-affinity·자원·PVC 바인딩	DB 파라미터보다 배치 조건부터 해결
앱 쓰기 실패	접속 서비스·role·primary 상태·TLS	standby 접속과 인증·네트워크 문제 구분
커밋이 오래 대기	동기 standby 상태·잠금·디스크 지연	복제 정책 때문에 대기하는지 구분
DB 디스크 증가	데이터·인덱스·WAL 각각의 증가	slot과 아카이브 실패, 보존 설정 확인
replica 지연 증가	쓰기량·네트워크·standby I/O	장애 전환 후보와 읽기 신선도 판단
Backup 실패	플러그인·저장소·Secret·CA·권한	연속 WAL과 베이스 백업 모두 확인

진단 결과에 맞춰 연결, 동시성, 유지 관리의 SQL을 함께 사용한다. (CNPG 문제 해결)

메트릭을 수집하는 경로

CNPG는 DB Pod에서 메트릭을 제공한다. Prometheus Operator를 쓰는 환경이라면 다음처럼 별도 PodMonitor를 둘 수 있다. pod-monitor.yaml로 저장하되 실제 Prometheus의 namespace·label 선택 조건에 맞춘다.

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: study-pg
  namespace: pg-study
spec:
  namespaceSelector:
    matchNames:
      - pg-study
  selector:
    matchLabels:
      cnpg.io/cluster: study-pg
  podMetricsEndpoints:
    - port: metrics

kubectl apply -f pod-monitor.yaml이 성공해도 Prometheus가 이 객체를 선택하고 scrape하는지 확인해야 한다. 위 예제는 기본 메트릭 포트를 전제로 하며 메트릭 TLS를 켰다면 해당 인증 설정을 더한다. 기존 spec.monitoring.enablePodMonitor 자동 생성 필드는 deprecated라 새 예제는 별도 객체를 사용한다. (CNPG 모니터링)

알림은 메트릭 이름을 나열하기보다 행동으로 연결할 상태부터 정한다. 준비된 인스턴스 감소, 연속 아카이브 실패, 복구 가능 시점의 지연, 디스크 여유, 복제 지연, 연결·잠금 대기를 본다. 임계값은 데이터 손실·복구 시간 목표와 평소 부하를 기준으로 정한다. Prometheus 자체 구성은 관측 덱에서 다룬다.

업그레이드할 대상부터 구분

대상	바뀌는 것	준비할 것
CNPG operator	관리 로직·CRD·지원 범위	릴리스 노트, 현재 Cluster와 플러그인 호환성
PostgreSQL minor	같은 major 계열의 서버·이미지	확장·이미지 변경 확인, 롤링 업데이트와 연결 중단 검증
PostgreSQL major	카탈로그·데이터 호환성과 서버 동작	지원되는 pg_upgrade 또는 논리 이행 등 경로, 다운타임·복구 계획
Barman Cloud 플러그인	백업·복원 실행 경로	CNPG 호환성, 기존 아카이브 읽기와 새 백업·복원 검증

CNPG는 지원 조건에 따라 offline in-place major upgrade 등의 경로도 제공한다. 따라서 “이미지 태그만 바꾸면 모든 major 업그레이드가 된다”고 가정하지 말고, 선택한 방식의 사전 검사·확장 호환성·정지 시간을 확인한다. (PostgreSQL 업그레이드, operator 업그레이드)

변경을 끝냈다는 증거

업그레이드 전 복원 가능한 백업과 기준 쿼리를 확보한다. 실습 환경에서 변경 후 앱 쓰기·읽기, 복제 상태, 새 백업과 그 백업의 복원을 확인한다. 버전 문자열이 바뀌거나 Pod가 준비된 것만으로는 부족하다. major 변경 뒤 이전 이미지로 되돌리는 것과 이전 데이터로 복구하는 것도 다른 작업이다.

이해 확인: DB가 정상인데 operator·백업 플러그인을 며칠째 점검하지 않았다면 어떤 위험이 남을까? 다음 장애에서 자동 조정이 작동하지 않거나 필요한 시점의 백업·WAL이 없을 수 있다. 운영의 정상은 지금의 응답뿐 아니라 다음 장애에 대응할 능력도 포함한다.