CNPG가 관리하는 것

결론부터

CNPG는 PostgreSQL의 복제 기능을 Kubernetes의 리소스와 연결해 DB의 원하는 상태를 유지한다.

Pod 세 개를 띄운다고 데이터가 자동으로 복제되지는 않는다. 반대로 PostgreSQL 복제만 설정했다고 장애 감지·승격·앱의 연결 대상 갱신이 모두 해결되지도 않는다. CNPG는 이 운영 절차를 연결한다. 온프렘 CNPG 페이지가 플랫폼에서의 자리를 설명한다면, 여기서는 내부 책임을 나눈다.

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

CNPGCloudNativePG

Kubernetes에서 PostgreSQL 클러스터의 생명주기를 관리하는 오퍼레이터.

ClusterCNPG 사용자 정의 리소스

DB 인스턴스 수·저장 공간·설정·복구 방식 등 원하는 상태를 선언한다.

reconcile상태 조정

관찰한 상태와 선언한 상태를 비교하고 필요한 변경을 수행하는 반복 과정.

데이터 경로와 관리 경로

실선은 앱과 복제의 경로, 점선은 관리 경로다. operator가 SQL을 중계하지 않는다. operator를 일시적으로 사용할 수 없어도 이미 동작 중인 PostgreSQL이 곧바로 멈추는 것은 아니지만, 장애 조치와 상태 조정 능력에는 영향이 생긴다. (CNPG 구조)

구성 요소	책임
PostgreSQL	SQL·트랜잭션·WAL·복제·복구 실행
instance manager	각 DB Pod 안에서 PostgreSQL 실행과 상태·프로브 관리
operator	Kubernetes API를 통해 클러스터 상태를 관찰하고 배치·승격·업데이트 조정
Kubernetes·스토리지	Pod 스케줄링, 네트워크, 볼륨 제공
운영자	복제·복구 목표, 용량·장애 영역·백업 정책, 복원 검증

CNPG는 StatefulSet을 그대로 감싼 제품이 아니다. 자체 Pod controller로 Pod와 PVC를 관리한다. 따라서 DB Pod를 직접 수정하기보다 Cluster에 원하는 설정을 선언한다. (instance manager, 자체 Pod controller)

앱은 어느 주소로 연결하나

기본 서비스	연결 대상	앱의 판단
study-pg-rw	현재 primary	쓰기와 primary에서 확인할 읽기
study-pg-ro	replica들	지연을 허용할 수 있는 읽기
study-pg-r	primary와 replica	어느 역할에 붙어도 되는 읽기

Service는 SQL의 SELECT·UPDATE를 분석해 분기하지 않는다. 연결을 맺은 대상에서 쿼리가 실행되므로 앱이 연결 경로를 구분해야 한다. -ro가 있어도 replica가 없거나 준비되지 않았다면 쓸 대상이 없다. (서비스 관리)

primary가 바뀌어도 -rw 주소를 유지할 수 있지만 기존 TCP 연결·진행 중 트랜잭션이 살아남는다는 뜻은 아니다. 재연결과 실패 처리가 앱에도 필요하다.

이해 확인: operator의 replica 수를 늘리면 PostgreSQL 읽기 replica가 늘어날까? 아니다. operator Deployment의 가용성과 Cluster.spec.instances의 DB 인스턴스 수는 별개다.