서비스 관리

원문 보기 위키 갱신 2026.10.03

서비스 관리 (Service management)

PostgreSQL 클러스터는 CloudNativePG가 직접 관리하는 표준 쿠버네티스 네트워크 서비스를 통해서만 접근해야 해요. 자세한 내용은 쿠버네티스 문서의 "Service" 페이지를 참고하세요.

CloudNativePG는 각 Cluster 리소스에 대해 세 가지 유형의 서비스를 정의해요:

rw: 클러스터의 프라이머리 인스턴스를 가리켜요 (읽기/쓰기).
ro: 가능한 경우 레플리카를 가리켜요 (읽기 전용).
r: 클러스터의 모든 PostgreSQL 인스턴스를 가리켜요 (읽기).

기본적으로 CloudNativePG는 다음 규칙에 따라 Cluster 리소스에 대해 위의 모든 서비스를 생성해요:

서비스 이름은 <CLUSTER_NAME>-<SERVICE_NAME> 형식을 따라요.
모든 서비스는 ClusterIP 타입이에요.

:::info[Important] 기본 서비스 이름은 CloudNativePG 전용으로 예약되어 있어요. :::

이 구성이 같은 쿠버네티스 클러스터 안에서 PostgreSQL에 접근하는 대부분의 사용 사례를 다루지만, CloudNativePG는 다음과 같은 유연성도 제공해요:

ro 및/또는 r 기본 서비스 생성을 비활성화할 수 있어요.
쿠버네티스가 제공하는 표준 Service API로 자신만의 서비스를 정의할 수 있어요.

이 두 옵션은 함께 섞어서 사용할 수 있어요.

흔한 시나리오는 CloudNativePG를 데이터베이스-서비스(Database-as-a-Service, DBaaS) 환경에서 사용할 때 생기는데, 그 경우 쿠버네티스 클러스터 밖에서 데이터베이스에 접근해야 해요. 그런 경우 쿠버네티스 환경에서 사용 가능하다면 LoadBalancer 타입의 서비스를 직접 만들 수 있어요.

출처: 문서

본문

기본 서비스 비활성화하기

managed.services.disabledDefaultServices 옵션을 통해 ro와 r 기본 서비스 중 일부 또는 전부를 비활성화할 수 있어요.

:::info[Important] rw 서비스는 필수이며 비활성화할 수 없어요. CloudNativePG가 PostgreSQL 복제를 보장하기 위해 이 서비스에 의존하기 때문이에요. :::

예를 들어 ro(읽기 전용)와 r(읽기) 서비스를 둘 다 제거하고 싶다면 다음과 같이 구성하면 돼요:

# <snip>
managed:
  services:
    disabledDefaultServices: ["ro", "r"]

자신만의 서비스 추가하기

:::info[Important] 자신만의 서비스를 정의할 때는 <CLUSTER_NAME>-<SERVICE_NAME> 규칙을 따르는 기본 예약 서비스 이름을 사용할 수 없어요. 쿠버네티스 네임스페이스 안에서 서비스에 고유한 이름을 정하는 것은 여러분의 책임이에요. :::

managed.services.additional stanza를 통해 추가 서비스 목록을 정의할 수 있어요. selectorType 필드에 서비스 유형(예: rw)을 지정하고, 선택적으로 updateStrategy를 지정하면 돼요.

serviceTemplate 필드는 네트워크 Service 리소스에 대한 표준 쿠버네티스 API에 접근을 제공해서, metadata와 spec 섹션을 원하는 대로 정의할 수 있게 해요.

서비스에는 name을 반드시 제공해야 하고, selector 필드는 오퍼레이터가 관리하므로 정의를 피해야 해요.

:::warning 서비스 템플릿은 PostgreSQL 데이터베이스에 대한 네트워크 접근을 구성하는 데 무한한 가능성을 제공해요. 따라서 서비스가 예상대로 동작하도록 보장하는 데 더 큰 책임이 여러분에게 돌아가요. CloudNativePG는 selector를 존중하는 것 외에는 서비스 구성을 통제하지 못해요. :::

updateStrategy 필드는 오퍼레이터가 서비스 정의를 업데이트하는 방식을 제어할 수 있게 해요. 기본적으로 오퍼레이터는 patch 전략을 사용해서 변경 사항을 서비스에 직접 적용해요. 반면 replace 전략은 기존 서비스를 삭제하고 템플릿에서 다시 생성해요.

:::warning replace 전략은 변경할 때마다 서비스 중단을 일으켜요. 하지만 서비스 생성 시에만 설정할 수 있는 특정 파라미터를 수정하려면 필요할 수 있어요. :::

예를 들어 PostgreSQL 데이터베이스 프라이머리를 위한 단일 LoadBalancer 서비스를 만들고 싶다면 다음 발췌문을 사용할 수 있어요:

# <snip>
managed:
  services:
    additional:
      - selectorType: rw
        serviceTemplate:
          metadata:
            name: "mydb-lb"
            labels:
              test-label: "true"
            annotations:
              test-annotation: "true"
          spec:
            type: LoadBalancer

위 예시는 생성된 서비스에 대한 annotations와 labels 같은 메타데이터를 설정하는 방법도 보여줘요.

Postgres 서비스 노출에 관해

PostgreSQL 서비스를 쿠버네티스 클러스터 밖으로 노출하는 주요 사용 사례는 크게 세 가지예요:

일시적으로, 테스트를 위해.
영구적으로, DBaaS 목적으로.
장기간/영구적으로, 컨테이너화하기 어렵거나 지속 가능하지 않아 쿠버네티스 밖의 가상 머신이나 물리 머신에 있어야 하는 레거시 애플리케이션을 위해. 이 사용 사례는 DBaaS와 매우 유사해요.

공용 네트워크에서 데이터베이스에 접근을 허용하면 악의적인 사용자의 잠재적 공격에 데이터베이스가 노출될 수 있다는 점을 인지하세요.

:::warning 외부 접근을 허용하기 전에 데이터베이스를 반드시 보호하거나, 쿠버네티스 클러스터가 사설 네트워크에서만 접근 가능하도록 해야 해요. :::

서비스 관리