오퍼레이터 역량 레벨

원문 보기 위키 갱신 2026.10.03

오퍼레이터 역량 레벨 (Operator capability levels)

CloudNativePG 오퍼레이터가 Operator SDK의 역량 레벨(Capability Levels) 프레임워크 기준으로 어떤 수준의 관리 기능을 제공하는지 정리해 드릴게요. CloudNativePG는 "Level V - Auto Pilot" 역량 세트를 제공해요.

출처: 문서

본문

이 역량들은 Operator SDK의 역량 레벨 정의 프레임워크로 분류된 것으로, CloudNativePG에 의해 구현됐어요.

Operator Capability Levels

:::info[Important] Operator Capability Levels 모델에 따르면, CloudNativePG 오퍼레이터에서 "Level V - Auto Pilot" 역량 세트를 기대할 수 있어요. :::

각 역량 레벨은 오퍼레이터가 제공하는 특정 관리 기능 세트와 연결돼요:

기본 설치 (Basic install)
원활한 업그레이드 (Seamless upgrades)
전체 라이프사이클 (Full lifecycle)
깊은 통찰 (Deep insights)
오토 파일럿 (Auto pilot)

:::note 이 프레임워크를 오퍼레이터의 향후 작업과 구현을 위한 가이드로 간주해요. :::

레벨 1: 기본 설치 (Basic install)

역량 레벨 1은 오퍼레이터의 설치와 구성을 포함해요. 이 범주는 오퍼레이터 및 PostgreSQL 클러스터 구성과의 상호작용 방식 개선 같은 사용성과 사용자 경험 향상을 포함해요.

:::info[Important] 정보 보안(information security)을 이 레벨의 일부로 간주해요. :::

선언적 구성을 통한 오퍼레이터 배포 (Operator deployment via declarative configuration)

오퍼레이터는 PostgreSQL 라이프사이클을 관리하는 데 필요한 핵심 CustomResourceDefinition 객체를 정의하는 Kubernetes 매니페스트를 사용해 선언적 방식으로 설치돼요. 여기에는 다음이 포함돼요:

구성 & 토폴로지: Cluster, Pooler, ImageCatalog, ClusterImageCatalog.
식별 & 스키마: DatabaseRole 및 Database.
비즈니스 연속성: Backup, ScheduledBackup, Publication, Subscription.
런타임 오케스트레이션: FailoverQuorum (자동 페일오버 중 컨센서스를 위해 오퍼레이터가 사용).

선언적 구성을 통한 PostgreSQL 클러스터 배포 (PostgreSQL cluster deployment via declarative configuration)

Cluster 커스텀 리소스를 사용해 PostgreSQL 클러스터(오퍼랜드)를 완전히 선언적인 방식으로 정의해요. PostgreSQL 버전은 CR에 정의된 오퍼랜드 컨테이너 이미지로 결정되며, 요청된 레지스트리에서 자동으로 가져와져요.

오퍼레이터는 표준 Kubernetes 리소스(Pod, Service, Secret, ConfigMap, PersistentVolumeClaim, PodDisruptionBudget, ServiceAccount, RoleBinding, Role)를 생성하고 관리함으로써 배포를 오케스트레이션하며, 사용자 정의 CNPG 리소스(Database, DatabaseRole 등)를 리컨실리하여 데이터베이스 환경이 원하는 상태와 일치하도록 해요.

Cluster와 Pooler 리소스 모두에 기존 ServiceAccount를 선택적으로 제공할 수 있어요. 이 공유 ServiceAccount 지원은 클라우드 네이티브 아이덴티티 제공자와의 원활한 통합을 가능하게 해서, 클러스터별로가 아니라 인프라 레벨에서 IAM 역할과 권한을 관리할 수 있게 해줘요.

CRD를 통한 오퍼랜드 이미지 재정의 (Override of operand images through the CRD)

오퍼레이터는 PostgreSQL을 포함한 모든 오퍼랜드 컨테이너 이미지를 지원해요. 기본적으로 ghcr.io의 가장 최근 커뮤니티 지원 메이저 버전 중 최신 안정 마이너 버전을 사용하지만, Cluster 리소스에서 .spec.imageName 속성을 설정해 이를 재정의할 수 있어요. 이 직접적인 방법은 프라이빗 레지스트리용 imagePullSecrets를 지원하고, 컨테이너 불변성을 보장하기 위해 태그와 SHA256 다이제스트를 모두 사용할 수 있어요.

대안으로 이미지 카탈로그(image catalogs)를 활용해 PostgreSQL 메이저 버전을 간단히 참조함으로써 이미지를 더 효과적으로 관리할 수 있어요. 이 접근 방식은 이미지 공급망 관리를 중앙화하므로 프로덕션 환경에 더 우수해요.

핵심 PostgreSQL 엔진을 넘어, 이미지 카탈로그를 사용하면 오퍼랜드 이미지와 함께 확장 볼륨(extension volumes)을 정의할 수 있어서, 데이터베이스와 관련 모듈이 항상 호환되고 버전이 일치하며 인프라 전체에서 단일 일관된 단위로 취급되도록 보장해요. 같은 카탈로그 메커니즘은 PgBouncer 풀러 이미지도 관리해요. 따라서 이미지 카탈로그는 오퍼레이터가 관리하는 전체 PostgreSQL 스택에 걸친 통합 공급망 프리미티브가 돼요.

라벨과 어노테이션 (Labels and annotations)

클러스터 메타데이터에 정의된 라벨과 어노테이션을 상속하도록 오퍼레이터를 구성할 수 있어요. 목표는 Kubernetes 인프라에서 CloudNativePG 배포의 구성을 개선하는 것이에요.

독립형 인스턴스 매니저 (Self-contained instance manager)

Patroni나 Stolon 같은 외부 도구에 의존해 Kubernetes 클러스터 파드에서 PostgreSQL 인스턴스를 조정하는 대신, 오퍼레이터는 /controller/manager라는 파일로 각 파드 안에 오퍼레이터 실행 파일을 주입해요. 이 애플리케이션은 기본 PostgreSQL 인스턴스를 제어하고 PostgreSQL 클러스터 토폴로지를 기반으로 파드 상태와 인스턴스를 리컨실리하는 데 사용돼요. 인스턴스 매니저는 또한 kubelet이 프로브(probe)를 위해 호출하는 웹 서버를 시작해요. kubelet이 호출하는 Unix 시그널은 인스턴스 매니저에 의해 필터링돼요. 적절한 경우 외부 이벤트에 빠르고 제어된 방식으로 반응하기 위해 postgres 프로세스로 전달돼요. 인스턴스 매니저는 Go로 작성되었으며 외부 의존성이 없어요.

스토리지 구성 (Storage configuration)

스토리지는 데이터베이스 워크로드에서 중요한 구성 요소예요. Kubernetes 네이티브 스토리지 기능과 리소스를 활용하는 오퍼레이터는 기본 Kubernetes 환경이 제공할 수 있는 것에 기반해 워크로드 요구사항에 맞는 올바른 스토리지를 선택할 수 있는 충분한 유연성을 제공해요. 이는 퍼블릭 클라우드 환경에서 특정 스토리지 클래스를 선택하거나 CR의 storage 파라미터에서 PVC 템플릿을 통해 생성된 PVC를 미세 조정하는 것을 의미해요.

더 나은 성능과 세밀한 제어를 위해 클러스터의 write-ahead 로그(WAL, pg_wal이라고도 함)를 별도의 볼륨, 가급적 다른 스토리지에 두도록 선택할 수도 있어요. 문서의 "Benchmarking(벤치마킹)" 섹션은 프로덕션 전에 스토리지와 데이터베이스 모두를 벤치마킹하는 상세한 지침을 제공해요. 최적의 성능과 안정성을 보장하기 위해 cnpg 플러그인을 사용해요.

레플리카 구성 (Replica configuration)

오퍼레이터는 instances라는 단일 파라미터를 통해 클러스터의 레플리카를 감지해요. 1로 설정하면 클러스터는 레플리카가 없는 단일 primary PostgreSQL 인스턴스로 구성돼요. 1보다 크면 오퍼레이터는 자동 페일오버를 통한 고가용성(HA)과 스위치오버 작업을 통한 롤링 업데이트를 포함해 instances - 1개의 레플리카를 관리해요.

CloudNativePG는 고가용성 클러스터의 모든 레플리카에 대해 리플리케이션 슬롯을 관리해요. 또한 primary에서 사용자 정의 물리적 리플리케이션 슬롯을 지원하고, PostgreSQL 17 이상에서는 sync_replication_slots로, 이전 버전에서는 pg_failover_slots 확장을 통해 로지컬 디코딩 페일오버를 네이티브하게 지원해요.

서비스 구성 (Service Configuration)

기본적으로 CloudNativePG는 애플리케이션이 네트워크를 통해 클러스터에 접근할 수 있도록 세 개의 Kubernetes 서비스(services)를 만들어요:

읽기/쓰기 작업용으로 primary를 가리키는 것 하나.
읽기 전용 쿼리용으로 레플리카를 가리키는 것 하나.
읽기 작업용으로 임의 인스턴스를 가리키는 일반적인 것 하나.

구성으로 읽기 전용 및 읽기 서비스를 비활성화할 수 있어요. 또한 서비스 템플릿 기능을 활용해 로드 밸런서를 포함한 커스텀 서비스 리소스를 만들어 Kubernetes 외부에서 PostgreSQL에 접근할 수 있어요. 이는 DBaaS 목적에 특히 유용해요.

파드 선택자를 통한 동적 네트워크 접근 제어 (Dynamic network access control via pod selectors)

CloudNativePG는 podSelectorRefs의 선언적 정의를 지원해 pg_hba.conf 규칙을 동적으로 관리해요. 라벨 선택자를 사용해 클라이언트 파드를 식별하면 오퍼레이터가 그 임시 IP 주소를 자동으로 해석하고 PostgreSQL 호스트 기반 인증 규칙을 그에 맞게 업데이트해요. 이렇게 하면 같은 네임스페이스의 권한 있는 워크로드만 데이터베이스에 연결할 수 있게 보장하며, 수동 IP 관리나 정적 CIDR 범위가 필요 없어요.

데이터베이스 구성 (Database configuration)

오퍼레이터는 단일 데이터베이스로 PostgreSQL 클러스터를 부트스트랩하도록 설계됐어요. 오퍼레이터는 읽기-쓰기, 읽기, 읽기-전용 워크로드를 위해 프로비저닝되고 관리되는 세 개의 Kubernetes 서비스를 통해 클러스터에 대한 네트워크 접근을 투명하게 관리해요. 컨벤션-오버-컨피규레이션 방식을 사용해 오퍼레이터는 기본적으로 app이라는 데이터베이스를 만들고, 기본적으로 같은 이름의 일반 Postgres 사용자가 소유해요. 필요한 경우 부트스트랩의 일부로 데이터베이스 이름과 사용자 이름을 모두 지정할 수 있어요.

추가 데이터베이스는 선언적 데이터베이스 관리(declarative database management)를 통해 Database CRD를 사용해 생성하거나 관리할 수 있으며, 확장, 스키마, 외부 데이터 래퍼(FDW), 외부 서버도 지원해요.

클러스터를 실행하는 데 구성이 필요하지는 않지만, CR의 postgresql 섹션에서 PostgreSQL 런타임 구성과 PostgreSQL 호스트 기반 인증 규칙을 모두 커스터마이즈할 수 있어요.

Postgres 역할, 사용자, 그룹 구성 (Configuration of Postgres roles, users, and groups)

CloudNativePG는 두 가지 선언적 방법을 통해 PostgreSQL 역할, 사용자, 그룹의 포괄적 관리를 지원해요:

DatabaseRole CRD (권장): 세분화된 라이프사이클 관리를 위한 독립 리소스. Kubernetes 리소스가 제거될 때 데이터베이스 역할을 삭제할지 정의하는 databaseRoleReclaimPolicy(retain 또는 delete 지원)를 포함해요.
managed 스탠자: 더 단순한 요구사항을 위해 Cluster 리소스의 .spec.managed.roles 섹션 안에 역할을 인라인으로 정의할 수 있어요.

두 방법 모두 역할 속성(예: login, superuser, connectionLimit)의 자동 리컨실리에이션과 Kubernetes Secrets를 통한 안전하고 버전 관리되는 비밀번호 관리를 제공해요. 비밀번호는 PostgreSQL로 보내지기 전에 오퍼레이터 측에서 SCRAM-SHA-256으로 인코딩되므로, 평문 값이 서버 로그나 확장에 도달하지 않아요. DatabaseRole은 또한 오퍼레이터가 자동으로 생성하고 갱신하는 TLS 클라이언트 인증서를 요청할 수 있어, 비밀번호 없는 cert 인증을 가능하게 해요.

Postgres 확장 구성 (Configuration of Postgres extensions)

CloudNativePG는 각 파드에서 확장을 읽기 전용 확장 볼륨(extension volumes)으로 마운트해 PostgreSQL 확장 관리를 선언적으로 지원해요. 버전 1.29부터 권장 접근 방식은 이미지 카탈로그(image catalogs)를 활용하는 것으로, 오퍼레이터가 PostgreSQL 버전에 따라 이미지 참조와 디렉토리 경로를 자동으로 해석할 수 있게 해줘요. 이미지 볼륨에는 extension_control_path 파라미터(PostgreSQL 18+)와 ImageVolume 기능(Kubernetes 1.35+, 또는 기능 게이트가 있는 1.33+)이 필요해요. 이 요구사항이 충족되지 않으면 확장은 오퍼랜드 이미지에 직접 포함되어야 해요. 시스템에서 사용할 수 있게 되면 Database 리소스가 CREATE EXTENSION SQL 라이프사이클을 자동화해요.

파드 보안 표준 (Pod security standards)

InfoSec 요구사항을 위해 오퍼레이터는 어떤 컨테이너에도 권한 모드(privileged mode)를 요구하지 않아요. 오퍼레이터와 오퍼랜드 파드 모두의 컨테이너 불변성을 보장하기 위해 읽기 전용 루트 파일시스템을 강제해요. 또한 필요한 보안 컨텍스트를 명시적으로 설정해요.

어피니티 (Affinity)

클러스터의 affinity 섹션은 파드와 영구 볼륨 같은 관련 리소스가 Kubernetes 클러스터의 노드들에 어떻게 스케줄링되는지를 미세 조정할 수 있게 해줘요. 특히 오퍼레이터는 다음을 지원해요:

파드 어피니티 및 안티-어피니티
노드 선택자
테인트와 톨러레이션

토폴로지 분산 제약 (Topology spread constraints)

클러스터의 topologySpreadConstraints 섹션은 토폴로지에 걸쳐 파드를 스케줄링하는 추가 제어를 가능하게 해, 어피니티와 안티-어피니티가 제공하는 것을 강화해요.

커맨드라인 인터페이스 (Command-line interface)

CloudNativePG는 자체 커맨드라인 인터페이스가 없어요. kubectl이라는 Kubernetes를 위한 최고의 커맨드라인 인터페이스에 의존하며, cnpg라는 플러그인을 제공해요. 이 플러그인은 PostgreSQL 클러스터 관리 경험을 향상시키고 단순화해요.

클러스터의 현재 상태 (Current status of the cluster)

오퍼레이터는 클러스터의 관찰된 상태로 CR의 status 섹션을 지속적으로 업데이트해요. 전체 PostgreSQL 클러스터 상태는 각 파드에서 실행되는 인스턴스 매니저에 의해 지속적으로 모니터링돼요. 인스턴스 매니저는 제어된 PostgreSQL 인스턴스에 필요한 변경을 적용해 클러스터의 요청된 상태로 수렴하도록 책임져요. (예를 들어 클러스터 상태가 파드 -1이 primary라고 보고하면, 파드 -1은 스스로 승격하고 다른 파드들은 파드 -1을 따라야 해요.) 같은 상태는 kubectl용 cnpg 플러그인이 세부 정보를 제공하는 데 사용돼요.

오퍼레이터의 인증 기관 (Operator's certification authority)

오퍼레이터는 스스로를 위한 인증 기관(certification authority)을 생성해요. 웹훅 서버가 사용할 리프(leaf) 인증서를 오퍼레이터 인증 기관으로 생성하고 서명해요. 이 인증서는 Kubernetes API 서버와 오퍼레이터 사이의 안전한 통신을 보장해요.

클러스터의 인증 기관 (Cluster's certification authority)

오퍼레이터는 모든 PostgreSQL 클러스터에 대해 인증 기관을 생성해요. 이 인증 기관은 (비밀번호 대신) 스트리밍 리플리케이션 스탠바이 서버를 포함한 클라이언트 인증을 위한 TLS 인증서를 발급하고 갱신하는 데 사용돼요. 클라이언트 인증서용 커스텀 인증 기관 지원은 시크릿을 통해 제공되며 cert-manager와의 통합도 포함해요. 인증서는 kubectl용 cnpg 플러그인으로 발급할 수 있어요.

TLS 연결 (TLS connections)

오퍼레이터는 클러스터의 인증 기관을 사용해 클라이언트/서버 통신을 암호화하는 TLS/SSL 연결을 투명하고 네이티브하게 지원해 보안을 강화해요. 커스텀 서버 인증서 지원은 시크릿을 통해 제공되며 cert-manager와의 통합도 포함해요.

스트리밍 리플리케이션 인증서 인증 (Certificate authentication for streaming replication)

스탠바이 서버로부터의 스트리밍 리플리케이션 연결을 승인하기 위해 오퍼레이터는 TLS 클라이언트 인증서 인증에 의존해요. 이 방법은 (따라서 시크릿에 의존하는) 비밀번호 대신 사용돼요.

연속 구성 관리 (Continuous configuration management)

오퍼레이터는 Cluster 리소스 YAML 섹션의 PostgreSQL 구성에 변경을 적용할 수 있게 해줘요. 구성 옵션에 따라 모든 인스턴스가 제대로 리로드되거나 재시작되도록 보장하기도 해요.

:::note ALTER SYSTEM으로 인한 변경은 감지되지 않아, 클러스터 상태가 강제되지 않는다는 것을 의미해요. :::

기존 PostgreSQL 데이터베이스 가져오기 (Import of existing PostgreSQL databases)

오퍼레이터는 오프라인 마이그레이션을 사용해 기존 Postgres 데이터베이스를 Kubernetes의 새 CloudNativePG 클러스터에 가져오는 선언적 방법을 제공해요. 같은 기능은 PostgreSQL 데이터베이스의 오프라인 메이저 업그레이드를 포함해요. 오프라인이란 애플리케이션이 데이터베이스가 가져올 때까지 소스에서 쓰기 작업을 중지해야 한다는 것을 의미해요. 이 기능은 다른 PostgreSQL 데이터베이스에서 사용 가능한 데이터의 로지컬 스냅샷을 사용해 새 PostgreSQL 클러스터를 만드는 initdb 부트스트랩 방법을 확장해요. 이 데이터는 수퍼유저 연결을 통해 네트워크로 접근할 수 있어요. 가져오기는 지원되는 모든 Postgres 버전에서 수행돼요. 작업에 포함된 모든 데이터베이스에 대해, 그리고 요청된 경우 역할에 대해 새 클러스터 primary에서 pg_dump와 pg_restore를 실행하는 데 의존해요.

PostGIS 클러스터 (PostGIS clusters)

CloudNativePG는 지리 데이터베이스용 PostGIS 오픈소스 확장과 함께 클러스터 설치를 지원해요. 이 확장은 PostgreSQL에서 가장 인기 있는 확장 중 하나예요.

PostgreSQL용 기본 LDAP 인증 (Basic LDAP authentication for PostgreSQL)

오퍼레이터는 PostgreSQL 문서의 LDAP 인증 섹션에 설명된 대로 simple bind 또는 search+bind 모드를 사용해 PostgreSQL 클라이언트에 대한 LDAP 인증을 구성할 수 있게 해줘요.

여러 설치 방법 (Multiple installation methods)

오퍼레이터는 퍼블릭 및 프라이빗 클라우드 환경의 전통적인 Kubernetes 설치에서 쓰이는 kubectl apply 방식의 Kubernetes 매니페스트로 설치할 수 있어요. CloudNativePG는 또한 Helm 차트나 OperatorHub.io의 OLM 번들로 설치하는 것도 지원해요.

컨벤션 오버 컨피규레이션 (Convention over configuration)

오퍼레이터는 컨벤션-오버-컨피규레이션 패러다임을 지원하며, 표준 기본값을 결정하면서도 이를 재정의하고 커스터마이즈할 수 있게 해줘요. Cluster CRD를 사용해 몇 줄의 YAML 코드로 PostgreSQL 클러스터 배포를 지정할 수 있어요.

레벨 2: 원활한 업그레이드 (Seamless upgrades)

역량 레벨 2는 오퍼레이터와 실제 워크로드(여기서는 PostgreSQL 서버)의 업데이트를 가능하게 하는 것에 관한 것이에요. 여기에는 PostgreSQL 마이너 릴리스 업데이트(보통 보안 및 버그 수정)와 온라인 메이저 업그레이드가 포함돼요.

오퍼레이터 업그레이드 (Operator Upgrade)

오퍼레이터 업그레이드는 원활하며 새 배포로 수행할 수 있어요. 컨트롤러를 업그레이드한 후 배포된 모든 PostgreSQL 클러스터의 롤링 업데이트가 시작돼요. 모든 클러스터를 동시에 업데이트하거나 시간에 걸쳐 업그레이드를 분산하도록 선택할 수 있어요.

인스턴스 매니저 주입 덕분에 오퍼레이터를 업그레이드해도 오퍼랜드에 대한 변경이 필요하지 않아, 오퍼레이터가 이전 버전의 오퍼랜드를 관리할 수 있게 해줘요.

또한 CloudNativePG는 오퍼레이터 업그레이드 후 인스턴스 매니저의 인플레이스 업데이트를 지원해요. 인플레이스 업데이트는 클러스터의 롤링 업데이트나 후속 스위치오버를 요구하지 않아요.

관리 워크로드 업그레이드 (Upgrade of the managed workload)

오퍼랜드는 Cluster 리소스, 구체적으로는 .spec.imageName 파라미터를 업데이트하거나 이미지 카탈로그(image catalog)에서 버전 참조를 업데이트하는 선언적 접근 방식으로 업그레이드돼요. 이 프로세스는 일반적으로 보안 패치나 새 PostgreSQL 마이너 버전으로 트리거돼요. 스탠바이 서버가 있는 클러스터에서 오퍼레이터는 레플리카부터 시작하는 롤링 업데이트를 수행해요. 기존 파드를 삭제하고 기본 스토리지를 재사용하면서 업데이트된 이미지로 새 파드로 교체해요. primaryUpdateStrategy에 따라 오퍼레이터는 이전 primary를 업데이트하기 전에 자동으로 스위치오버를 수행하거나(unsupervised), cnpg 플러그인을 통해 사용자가 시작한 수동 스위치오버를 기다릴 수 있어요(supervised). 이 전략을 통해 조직은 스위치오버에 필요한 짧은 다운타임(워크로드에 따라 수 초에서 수 분)과 비즈니스 요구사항을 균형 있게 맞출 수 있어요.

PostgreSQL 오프라인 인플레이스 메이저 업그레이드 (Offline In-Place Major Upgrades of PostgreSQL)

CloudNativePG는 더 높은 PostgreSQL 메이저 버전의 새 오퍼랜드 컨테이너 이미지가 적용될 때 선언적 오프라인 인플레이스 메이저 업그레이드를 지원해요. 이 업그레이드는 .spec.imageName을 직접 업데이트하거나 이미지 카탈로그 안에서 더 높은 메이저 버전을 선택해 트리거할 수 있어요. 이미지 카탈로그 사용은 여기서 특히 유용한데, 관련된 확장 볼륨(extension volumes)이 새 PostgreSQL 메이저 버전과 호환되는 버전으로 동시에 업데이트되도록 보장하기 때문이에요.

이 과정에서 오퍼레이터는 데이터 일관성을 유지하기 위해 모든 클러스터 파드를 종료하고, 업그레이드 조건을 검증하고 pg_upgrade를 실행하는 잡(job)을 시작해요. 이 잡은 레플리카를 다시 만들기 전에 PGDATA, WAL 파일, 테이블스페이스에 필요한 새 디렉토리를 생성해요. 이 구조화된 워크플로우는 메이저 버전 전환을 위한 안정적인 경로를 제공하며, 실패 후 사용자가 이미지를 되돌리면 자동 롤백 정리를 지원해요. 이미지 볼륨 확장을 사용하는 클러스터도 지원돼요: 업그레이드 잡 중에 소스 버전과 대상 버전의 확장 이미지가 나란히 마운트되므로, 이전 서버는 라이브러리를 유지하고 실패한 업그레이드는 깨끗하게 되돌아가요.

업그레이드 중 클러스터 사용 가능 상태 표시 (Display cluster availability status during upgrade)

언제든지 클러스터의 고가용성 상태를 전달해요. 예를 들어 Setting up primary, Creating a new replica, Cluster in healthy state, Switchover in progress, Failing over, Upgrading cluster, Upgrading Postgres major version 등요.

레벨 3: 전체 라이프사이클 (Full lifecycle)

역량 레벨 3은 오퍼레이터가 비즈니스 연속성과 확장성의 측면을 관리할 것을 요구해요.

*재해 복구(Disaster recovery)*는 데이터베이스의 백업과 복구가 모두 올바르게 작동해야 하는 비즈니스 연속성 구성 요소예요. 시작점으로서 RPO < 5분을 달성하는 것이 목표이며, 장기적으로는 RPO=0 백업 솔루션을 구현하는 것이 목표예요. *고가용성(High availability)*은 비즈니스 연속성의 또 다른 중요한 구성 요소예요. PostgreSQL 네이티브 물리적 리플리케이션과 핫 스탠바이 레플리카를 통해 오퍼레이터가 페일오버와 스위치오버 작업을 수행할 수 있게 해줘요. 이 영역에는 다음의 개선이 포함돼요:

동기 리플리케이션, (캐스케이딩) 리플리케이션 클러스터 등 PostgreSQL 물리적 리플리케이션 제어
pgBouncer를 통한 커넥션 풀링 계층으로 성능과 제어를 개선하는 커넥션 풀링

PostgreSQL WAL 아카이브 (PostgreSQL WAL archive)

오퍼레이터는 WAL 파일의 PostgreSQL 연속 아카이빙을 객체 스토어(AWS S3 및 S3 호환, Azure Blob Storage, Google Cloud Storage, MinIO 같은 게이트웨이)로 지원해요.

WAL 아카이빙은 클러스터 정의에서 backup 파라미터를 통해 클러스터 레벨에서 선언적으로 정의돼요. 이는 S3 프로토콜 대상 URL(예: AWS S3 버킷의 특정 폴더를 가리키는 URL)과 선택적으로 일반 엔드포인트 URL을 지정해 수행돼요.

연속 백업의 전제 조건인 WAL 아카이빙은 사용자의 추가 작업이 필요 없어요. 오퍼레이터는 barman-cloud-wal-archive에 의존하도록 archive_command를 투명하게 설정해 WAL 파일을 정의된 엔드포인트로 전송해요. 압축 알고리즘과 아카이브에 WAL 파일을 동시에 업로드할 병렬 잡 수를 결정할 수 있어요. 또한 Instance Manager는 첫 번째 WAL 파일 세트를 전송하기 전에 barman-cloud-check-wal-archive 명령을 수행해 아카이브 대상의 정확성을 확인해요.

PostgreSQL 백업 (PostgreSQL Backups)

CloudNativePG는 PostgreSQL의 네이티브 물리적 백업 메커니즘(즉 베이스 백업과 연속 WAL 아카이빙)을 사용해 애플리케이션 레벨 백업을 관리하기 위한 플러그형 인터페이스(CNPG-I)를 제공해요. 이 설계는 일관성과 성능을 보장하면서 유연성과 확장성을 가능하게 해요.

CloudNativePG 커뮤니티는 객체 스토어로의 연속 물리적 백업과 전체 및 시점 복구(PITR) 기능을 가능하게 하는 Barman Cloud Plugin을 공식 지원해요.

CNPG-I 플러그인 외에도 CloudNativePG는 기본 스토리지 클래스와 CSI 드라이버가 지원할 때 Kubernetes 볼륨 스냅샷을 사용한 백업도 네이티브로 지원해요.

베이스 백업은 두 가지 방법으로 시작할 수 있어요:

주문형(on-demand), Backup 커스텀 리소스 사용
예약형(scheduled), cron 유사 스케줄 형식의 ScheduledBackup 커스텀 리소스 사용

볼륨 스냅샷은 Kubernetes API를 활용하며, 속도와 스토리지 효율성 덕분에 매우 큰 데이터베이스(VLDB)에 특히 효과적이에요.

볼륨 스냅샷과 CNPG-I 기반 백업 모두 다음을 지원해요:

핫 백업: PostgreSQL이 실행되는 동안 수행되어 중단을 최소화해요.
콜드 백업: 필요할 때 PostgreSQL을 일시적으로 중지해 완전히 일관된 스냅샷을 보장해요.

스탠바이에서의 백업 (Backups from a standby)

오퍼레이터는 데이터베이스의 RPO에 영향을 주지 않고 베이스 백업을 스탠바이로 오프로드하는 것을 지원해요. 이를 통해 표준 데이터베이스 작업을 위해 특히 I/O 자원을 primary에 보존할 수 있어요.

백업에서 전체 복원 (Full restore from a backup)

오퍼레이터는 볼륨 스냅샷, 객체 스토어 또는 플러그인에 있는 기존의 접근 가능한 백업에서 (그 설정과 함께) 새 클러스터를 부트스트랩할 수 있게 해줘요.

부트스트랩 프로세스가 완료되면 오퍼레이터는 복구 모드에서 인스턴스를 시작해요. 지정된 아카이브에서 사용 가능한 모든 WAL 파일을 재생하고, 복구를 종료하고 primary로 시작해요. 이후 오퍼레이터는 요청된 수의 스탠바이 인스턴스를 primary에서 복제해요. CloudNativePG는 아카이브에서 병렬 WAL 페치를 지원해요.

백업에서 시점 복구 (Point-in-time recovery (PITR) from a backup)

오퍼레이터는 타임스탬프, 라벨 또는 트랜잭션 ID로 정의된 특정 시점으로 기존 백업을 복구해 새 PostgreSQL 클러스터를 만들 수 있게 해줘요. 이 기능은 전체 복원 기능 위에 구축되며 PostgreSQL의 PITR에 사용 가능한 모든 옵션을 지원해요.

동기 리플리케이션을 통한 제로 데이터 손실 클러스터 (Zero-Data-Loss Clusters Through Synchronous Replication)

CloudNativePG는 동기 리플리케이션과 선택적 페일오버 쿼럼(failover quorum)을 결합해 제로 데이터 손실(RPO=0) 고가용성 클러스터를 가능하게 해요: 언제든 사용 가능해야 하는 동기 스탠바이 레플리카 수를 정의할 수 있어서, 데이터가 안전하게 리플리케이션될 때만 페일오버가 진행되도록 보장해요. 쿼럼 기반과 우선순위 기반 동기 리플리케이션을 모두 지원하며, 오퍼레이터는 지속성과 성능 요구사항에 맞춰 synchronous_standby_names 설정을 구성하는 완전한 유연성을 제공해요.

레플리카 클러스터 (Replica clusters)

네이티브 스트리밍과 캐스케이딩 리플리케이션의 힘을 활용해 PostgreSQL 클러스터를 위한 강력한 크로스-Kubernetes 클러스터 토폴로지를 구축해요. replica 옵션을 사용하면 같은 메이저 버전의 다른 PostgreSQL 소스에서 일관되게 데이터를 리플리케이션하는 자율 클러스터를 구성할 수 있어요. 이 소스는 WAL 파일을 가져오기 위한 WAL 아카이브에 접근하거나 두 엔드포인트 사이에 TLS를 통한 직접 스트리밍 연결이 있다면 어디든 위치할 수 있어요.

특히 소스 PostgreSQL 인스턴스는 물리적 또는 가상 환경에서 Kubernetes 외부에 존재할 수 있어요.

레플리카 클러스터는 볼륨 스냅샷, 복구 객체 스토어(Barman Cloud 백업 형식 사용), 또는 pg_basebackup을 사용한 스트리밍 등 다양한 방법으로 인스턴스화할 수 있어요. WAL 파일 전송과 WAL 스트리밍을 모두 지원해요. 레플리카 클러스터 배포는 Kubernetes 내 PostgreSQL 데이터베이스의 비즈니스 연속성 태세를 크게 향상시키며, 여러 데이터 센터에 걸쳐 확장되고 하이브리드 및 멀티-클라우드 설정을 용이하게 해요. (Kubernetes 페더레이션 네이티브 기능을 기대하면서도, 데이터 센터 간 수동 스위치오버는 여전히 필요해요.)

또한 의도적으로 primary 클러스터보다 뒤처지는 지연(delayed) 레플리카 클러스터를 만드는 유연성도 확장돼요. 이 의도적 지연은 잘못된 DELETE 또는 UPDATE SQL 작업 같은 의도치 않은 오류가 발생할 경우 복구 시간 목표(RTO)를 최소화하는 것을 목표로 해요.

분산 데이터베이스 토폴로지 (Distributed Database Topologies)

레플리카 클러스터를 활용해 다양한 Kubernetes 클러스터에 걸친 PostgreSQL용 분산 데이터베이스 토폴로지를 정의하고, 하이브리드 및 멀티-클라우드 배포를 용이하게 해요. CloudNativePG로 다음과 같은 강력한 기능을 얻을 수 있어요:

선언적 primary 제어: 어떤 PostgreSQL 클러스터가 primary인지 쉽게 지정해요.
원활한 primary 스위치오버: 이전 primary를 다시 복제할 필요 없이 현재 primary를 강등하고 다른 클러스터(보통 다른 리전에 위치)를 승격시켜요.

이 설정은 두 개 이상의 리전에서 효율적으로 운영될 수 있고, 리플리케이션을 위해 전적으로 객체 스토어에 의존할 수 있으며, 최대 5분의 RPO(복구 지점 목표)를 보장해요. 이 고급 기능은 CloudNativePG만의 고유 기능으로, 다양한 환경에서 강력한 데이터 무결성과 연속성을 보장해요.

테이블스페이스 지원 (Tablespace support)

CloudNativePG는 개별 영구 볼륨의 선언적 정의를 용이하게 함으로써 PostgreSQL 테이블스페이스에 대한 강력한 지원을 매끄럽게 통합해요. 이 혁신적인 기능을 통해 다양한 스토리지 장치에 걸쳐 I/O 작업을 효율적으로 분산할 수 있어요. 테이블스페이스의 투명한 오케스트레이션을 통해 CloudNativePG는 PostgreSQL 데이터베이스의 성능과 확장성을 향상시키고, 클라우드 네이티브 환경에서 대규모 데이터 스토리지를 관리하는 원활하고 최적화된 경험을 보장해요. 임시 테이블스페이스 지원도 포함돼요.

커스터마이즈 가능한 Startup, Liveness, Readiness 프로브 (Customizable Startup, Liveness, and Readiness Probes)

CloudNativePG는 Kubernetes kubelet이 관리하는 PostgreSQL 컨테이너용 startup, liveness, readiness 프로브를 구성해요. 이 프로브는 인스턴스 매니저의 웹 서버가 노출하는 /startupz, /healthz, /readyz 엔드포인트와 상호작용해 파드의 상태와 준비 상태를 모니터링해요.

모든 프로브는 기본 설정으로 구성되지만 특정 요구사항에 맞게 완전히 커스터마이즈될 수 있어, 환경과 워크로드에 맞게 미세 조정할 수 있어요.

상세 구성 옵션과 고급 사용법은 Postgres instance manager 문서를 참고해 주세요.

롤링 배포 (Rolling deployments)

오퍼레이터는 다운타임을 최소화하기 위해 롤링 배포를 지원해요. PostgreSQL 클러스터가 공개적으로 노출되는 경우, 서비스는 초기화나 업데이트 중에 사용 가능한 파드에만 읽기 전용 트래픽을 로드 밸런싱해요.

레플리카 스케일 업/다운 (Scale up and down of replicas)

오퍼레이터는 PostgreSQL 클러스터의 인스턴스 수를 스케일 업하고 다운할 수 있게 해줘요. 새 레플리카는 primary 서버에서 시작되며 클러스터의 HA 인프라에 참여해요. CRD는 kubectl scale 명령을 사용할 수 있게 해주는 "scale" 하위 리소스를 선언해요. scale 하위 리소스는 또한 관리되는 인스턴스 파드의 라벨 선택자를 게시해 autoscaler가 이를 발견할 수 있게 해줘요. 권장 사용법은 Vertical Pod Autoscaler 통합을, HPA에 적용되는 주의사항은 Horizontal Pod Autoscaler 통합을 참고해 주세요.

Kubernetes 노드용 유지보수 창과 PodDisruptionBudget (Maintenance window and PodDisruptionBudget for Kubernetes nodes)

오퍼레이터는 동시 중단 수를 primary 인스턴스 하나로 제한하는 PodDisruptionBudget 리소스를 생성해요. 이 구성은 유지보수 작업이 클러스터의 모든 파드를 삭제하지 못하게 방지하고, 지정된 수의 인스턴스가 생성되도록 해요. PodDisruptionBudget은 노드 드레이닝 작업 중에 적용되어 클러스터 서비스의 중단을 방지해요.

이 전략은 스토리지가 모든 워커 노드 사이에 공유되는 Kubernetes 클러스터에서는 올바르지만, 로컬 스토리지를 사용하는 클러스터나 프라이빗 클라우드에 설치된 클러스터에는 최선의 솔루션이 아닐 수 있어요. 오퍼레이터는 유지보수 창을 지정하고 기본적인 노드 축출(eviction)에 대한 반응을 구성할 수 있게 해줘요. 유지보수 창 섹션의 ReusePVC 옵션은 사용할 전략을 지정할 수 있게 해줘요. 축출된 인스턴스에 대해 다른 PVC에 새 스토리지를 할당하거나, 기본 노드가 다시 사용 가능해질 때까지 기다려요.

펜싱 (Fencing)

펜싱은 PostgreSQL 클러스터의 하나, 여러 개, 또는 모든 인스턴스가 오작동하는 것으로 보일 때 그 데이터를 보호하는 프로세스예요. 인스턴스가 펜싱되면 PostgreSQL 서버 프로세스가 종료되는 것이 보장되는 반면, 파드는 계속 실행 상태로 유지돼요. 이렇게 하면 펜스가 해제될 때까지 파드의 데이터가 PostgreSQL에 의해 수정되지 않고, 디버깅과 문제 해결을 위해 파일시스템을 조사할 수 있게 보장돼요.

하이버네이션 (Hibernation)

CloudNativePG는 cnpg.io/hibernation 어노테이션을 통해 실행 중인 PostgreSQL 클러스터의 하이버네이션을 선언적 방식으로 지원해요. 하이버네이션은 데이터베이스 PVC를 유지하면서 데이터베이스 파드를 제거해 CPU 전력을 절약할 수 있게 해줘요. 이 기능은 인스턴스를 0개로 스케일링하는 것을 시뮬레이션해요.

파드의 영구 볼륨 스토리지 재사용 (Reuse of persistent volumes storage in pods)

오퍼레이터가 사용자가 삭제했거나 Kubernetes 유지보수 작업에 의해 축출된 파드를 만들어야 할 때, 가능하면 PersistentVolumeClaim을 재사용해요. 이 능력은 primary에서 데이터를 다시 복제할 필요를 피하게 해줘요.

CPU 및 메모리 requests와 limits (CPU and memory requests and limits)

오퍼레이터는 관리자가 매니페스트의 resources 섹션에서 클러스터 파드의 리소스 사용을 제어하고 관리할 수 있게 해줘요. 특히 CPU와 RAM 모두에 대해 requests와 limits 값을 설정할 수 있어요. Cluster가 scale 하위 리소스를 통해 라벨 선택자를 노출하기 때문에, Vertical Pod Autoscaler의 추천 전용 모드에서 이 값들에 대한 크기 조정 제안을 얻기 위한 대상으로도 사용될 수 있어요.

PgBouncer를 통한 커넥션 풀링 (Connection pooling with PgBouncer)

CloudNativePG는 PostgreSQL용 가장 인기 있는 오픈소스 커넥션 풀러 중 하나인 PgBouncer를 통한 커넥션 풀링을 네이티브로 지원해요. 아키텍처 관점에서 PgBouncer 커넥션 풀러의 네이티브 구현은 데이터베이스에 접근하는 새로운 계층을 도입해요. 이는 인스턴스로의 쿼리 흐름을 최적화하고 기본 PostgreSQL 리소스의 사용을 더 효율적으로 만들어요. 애플리케이션은 PostgreSQL 서비스에 직접 연결하는 대신 이제 PgBouncer 서비스에 연결해 기존 연결을 재사용할 수 있어요. PgBouncer 이미지는 ImageCatalog나 ClusterImageCatalog(via spec.pgbouncer.imageCatalogRef)를 통해 중앙에서 관리할 수 있고, Pooler 메트릭 엔드포인트는 선택적으로 TLS를 통해 제공할 수 있어요.

로지컬 리플리케이션 (Logical Replication)

CloudNativePG는 Publication과 Subscription 커스텀 리소스 정의를 사용해 PostgreSQL의 로지컬 리플리케이션을 선언적으로 지원해요.

로지컬 리플리케이션은 특히 다음에 유용해요:

온라인 데이터 마이그레이션: 최소 다운타임으로 외부 PostgreSQL 인스턴스나 퍼블릭 DBaaS 솔루션에서 데이터를 이동해요.
PostgreSQL 메이저 업그레이드: 메이저 버전 간 거의 제로-다운타임 업그레이드를 용이하게 해요.
선택적 데이터 분산: 보고 또는 현지화된 워크로드를 위해 다른 클러스터에 걸쳐 특정 테이블이나 데이터 세트를 리플리케이션해요.

레벨 4: 깊은 통찰 (Deep insights)

역량 레벨 4는 *관측성(observability)*에 관한 것이에요: 모니터링, 알림, 트렌드 파악, 로그 처리. 여기에는 Prometheus, Grafana, Fluent Bit 같은 외부 도구의 사용과 오류 로그를 직접 JSON 형식으로 출력하기 위한 PostgreSQL 엔진의 확장이 포함될 수 있어요.

CloudNativePG는 유연한 모니터링과 로깅을 위해 업계 표준 및 커뮤니티에서 수용되는 도구와 쉽게 통합하는 데 필요한 모든 것을 제공하도록 설계됐어요.

구성 가능한 쿼리를 가진 Prometheus exporter (Prometheus exporter with configurable queries)

인스턴스 매니저는 플러그형 프레임워크를 제공해요. metrics 포트(9187)에서 수신 대기하는 자체 웹 서버를 통해 Prometheus 모니터링 및 알림 도구용 메트릭을 내보내는 엔드포인트를 노출해요. 오퍼레이터는 postgres_exporter for Prometheus와 호환되는 구문을 사용해 ConfigMap 또는 Secret 객체로 정의된 커스텀 모니터링 쿼리를 지원해요. CloudNativePG는 여러분의 상황에 통합하고 적응할 수 있는 기본 PostgreSQL 모니터링 쿼리 세트를 제공해요.

Grafana 대시보드 (Grafana dashboard)

CloudNativePG는 PostgreSQL 클러스터의 모든 중요한 측면을 모니터링하고 커스터마이즈할 수 있는 기반으로 사용할 수 있는 Grafana 대시보드를 함께 제공해요.

PostgreSQL 오류 메시지의 표준 출력 JSON 로깅 (Standard output logging of PostgreSQL error messages in JSON format)

모든 로그 메시지는 표준 출력으로 JSON 형식으로 전달돼요. 첫 번째 레벨은 타임스탬프, 로그 레벨, 로그 항목 유형(예: 표준 PostgreSQL 오류 메시지 채널용 postgres)의 정의예요. 결과적으로 CloudNativePG가 관리하는 모든 파드는 JSON을 소스 데이터 유형으로 지원하는 다운스트림 로그 처리 스택과 쉽고 직접적으로 통합될 수 있어요.

실시간 쿼리 모니터링 (Real-time query monitoring)

CloudNativePG는 다음과 같은 것을 투명하고 네이티브하게 지원해요:

PostgreSQL 서버가 실행한 모든 SQL 문의 계획 및 실행 통계 추적을 가능하게 하는 필수 pg_stat_statements 확장
수동으로 EXPLAIN을 실행하지 않고도 느린 문의 실행 계획을 자동으로 로깅하는 수단을 제공하는 auto_explain 확장 (최적화되지 않은 쿼리를 추적하는 데 도움이 됨)

감사 (Audit)

CloudNativePG는 데이터베이스 및 보안 관리자, 감사자, 오퍼레이터가 PostgreSQL용 PGAudit을 사용해 데이터베이스 활동을 추적하고 분석할 수 있게 해줘요. 그러한 활동은 JSON 로그로 직접 흘러가며 Fluentd 같은 일반적인 로그 브로커를 사용해 올바른 다운스트림 대상으로 적절히 라우팅될 수 있어요.

Kubernetes 이벤트 (Kubernetes events)

Kubernetes API가 기대하는 대로 리소스 생성, 노드 제거, 업그레이드 같은 주요 이벤트를 기록해요. 이벤트는 kubectl describe 및 kubectl get events 명령으로 표시할 수 있어요.

레벨 5: 오토 파일럿 (Auto pilot)

역량 레벨 5는 관측성 계층에서 도출된 이상 징후와 통찰의 발견을 통한 자동 스케일링, 자가 치유(healing), 튜닝에 초점을 맞춰요.

자가 치유를 위한 자동 페일오버 (Automated failover for self-healing)

primary에서 실패가 감지되면 오퍼레이터는 가장 정렬된 레플리카를 새 대상 primary로 설정해 클러스터 상태를 변경해요. 결과적으로 각 살아있는 파드의 인스턴스 매니저는 클러스터의 요청된 상태와 정렬되기 위해 필요한 절차를 시작해요. 새 primary가 되거나 그를 따름으로써 이를 수행해요. 이전 primary가 다시 올라오는 경우, 같은 메커니즘은 애플리케이션에게 접근을 차단하고, 서버에서 pg_rewind를 실행하고 스탠바이로 다시 시작함으로써 스플릿-브레인을 방지해요. 오퍼레이터는 또한 뮤텍스 역할을 하는 클러스터별 Kubernetes Lease를 통해 primary 승격을 조정해, 언제든 최대 하나의 인스턴스가 승격되도록 보장해요: 인스턴스는 primary로 작동하기 전에 lease를 보유해야 하고, 깨끗한 종료 시 그것을 해제하므로 레플리카는 전체 TTL을 기다리지 않고 승격할 수 있어요. 동기 페일오버 쿼럼이 활성화되면 오퍼레이터의 "Auto Pilot" 로직은 훨씬 더 정교해져요: 레플리카 쿼럼이 트랜잭션 상태를 검증할 수 없으면 승격을 적극적으로 차단해요. 이는 primary와 그 동기 스탠바이 모두에 영향을 주는 네트워크 파티션 같은 복잡한 실패 시나리오 중 우발적인 데이터 손실을 방지해요.

스탠바이 자동 재생성 (Automated recreation of a standby)

스탠바이를 호스팅하는 파드가 제거되면 오퍼레이터는 스탠바이 서버를 다시 만드는 절차를 시작해요.