12.4 Networking

CloudNativePG는 Kubernetes 클러스터의 네트워킹이 이미 제대로 구성돼 있다고 전제한다. 그 위에서 operator와 PostgreSQL Pod, 그리고 Pod끼리 서로 연결될 수 있어야 정상 동작한다. 로컬 개발 환경(KinD, k3d)에는 기본적으로 아무 제약이 없어 신경 쓸 일이 적지만, 운영 클러스터에 NetworkPolicy가 걸려 있으면 이 연결을 명시적으로 허용해야 한다.

필요한 연결

operator와 클러스터가 동작하려면 최소한 다음 경로가 열려 있어야 한다.

operator → cluster Pod — operator가 각 PostgreSQL Pod에 포트 8000과 5432로 접속할 수 있어야 한다. 8000은 instance manager의 상태·관리 채널, 5432는 PostgreSQL 접속 포트다.
Pod ↔ Pod — 클러스터의 Pod끼리 서로 연결돼야 한다. replica가 primary로부터 streaming replication으로 WAL을 받는 경로가 여기 해당한다.

    flowchart TD
  OP["Operator<br/>(cnpg-system)"]
  PRI["Primary Pod"]
  REP["Replica Pod"]
  OP -->|"8000 / 5432"| PRI
  OP -->|"8000 / 5432"| REP
  PRI -->|"replication 5432"| REP

NetworkPolicy와 cross-namespace 트래픽

흔히 operator는 전용 namespace(기본값 cnpg-system)에, 클러스터는 별도 namespace에 둔다. 이때 namespace 사이 트래픽을 막는 NetworkPolicy가 있으면 operator가 Pod에 닿지 못해 클러스터 관리가 멈춘다. reconcile이 실패하거나, failover·rolling update 같은 조작이 진행되지 않는 형태로 드러난다.

“namespace 사이 트래픽을 차단하는” 기본 정책을 깔아 두었다면, operator namespace에서 클러스터 namespace로 향하는 트래픽을 예외로 허용해야 한다. 그러지 않으면 operator는 살아 있어도 클러스터를 손대지 못한다.

공식 문서는 networkpolicy-example.yaml 템플릿을 제공한다. 이를 가져다 클러스터 이름·클러스터 namespace를 자기 환경에 맞게 바꾸고, operator namespace가 기본값이 아니라면 그것도 함께 고친다. 아래는 operator namespace에서 오는 ingress와 Pod 사이 트래픽을 허용하는 형태의 예다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cluster-example-allow
  namespace: my-cluster-ns          # 클러스터 namespace로 교체
spec:
  podSelector:
    matchLabels:
      cnpg.io/cluster: cluster-example   # 클러스터 이름으로 교체
  policyTypes:
    - Ingress
  ingress:
    # operator namespace에서 오는 트래픽 허용
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: cnpg-system
      ports:
        - protocol: TCP
          port: 8000
        - protocol: TCP
          port: 5432
    # 같은 클러스터 Pod 사이(replication) 허용
    - from:
        - podSelector:
            matchLabels:
              cnpg.io/cluster: cluster-example
      ports:
        - protocol: TCP
          port: 5432

cross-cluster 시나리오

bootstrap의 import나 externalClusters로 다른 클러스터를 참조할 때는 그 사이 연결도 확보해야 한다. 관련된 모든 클러스터, object store, namespace 사이의 연결이 열려 있어야 복제·가져오기가 성립한다. logical replication의 subscriber가 publisher에 접속하는 경우, replica cluster가 원본에서 WAL을 받아 오는 경우가 여기 해당한다.

정리

CloudNativePG는 클러스터 네트워킹이 이미 구성돼 있다고 전제
operator → Pod는 8000·5432, Pod ↔ Pod는 replication 경로가 열려 있어야 함
operator와 클러스터를 다른 namespace에 두고 cross-namespace 차단 정책이 있으면 관리가 멈춘다 — 예외 허용 필요
공식 networkpolicy-example.yaml을 자기 환경에 맞춰 이름·namespace를 바꿔 적용
externalClusters·import를 쓸 땐 관련 클러스터·object store 사이 연결도 확보

다음 절에서는 cnpg 플러그인으로 pgbench·fio 벤치마크를 돌려 성능을 재는 법을 본다.

12.3 PostGIS 12.5 Benchmarking