6.3 Rolling updates

PostgreSQL 이미지를 새 마이너 버전으로 올리거나, restart가 필요한 설정을 바꾸거나, Operator 자체를 업그레이드할 때 인스턴스를 다시 띄워야 한다. 이때 모든 pod를 한꺼번에 내리면 서비스가 멈춘다. CloudNativePG는 그 대신 rolling update로 인스턴스를 하나씩 교체해 서비스 중단을 최소화한다.

핵심 원칙은 단순하다. replica부터 하나씩 바꾸고, primary는 맨 마지막에 switchover로 넘긴다. 읽기 트래픽은 살아 있는 다른 인스턴스가 받고, 쓰기 중단은 primary가 교체되는 짧은 switchover 순간으로 국한된다.

무엇이 rolling update를 부르나

다음 변화가 감지되면 Operator가 rolling update를 시작한다.

imageName 변경 (예: PostgreSQL 마이너 버전 업)
.spec.postgresql.extensions stanza 변경
Image Catalog에 해당 major 버전의 새 이미지가 올라옴
restart가 필요한 PostgreSQL 설정 변경
.spec.resources 값 변경
Operator 업그레이드 (in-place instance manager 업데이트가 켜져 있지 않은 경우)

교체 순서

Operator는 serial 번호가 가장 높은 replica부터 한 번에 pod 하나씩 올려 나가고, primary는 가장 마지막에 처리한다. pod는 삭제 후 재생성되지만 PVC는 그대로 유지되므로, 데이터를 다시 clone하지 않고 같은 CloudNativePG 신원을 유지한 채 이미지만 갈아 끼운다.

    flowchart TD
  START["업데이트 감지"]
  R2["replica(serial 높은 순)<br/>하나씩 교체"]
  DONE{"replica 모두<br/>완료?"}
  STRAT{"primaryUpdateStrategy"}
  SUP["supervised:<br/>수동 개입 대기"]
  UNSUP["unsupervised:<br/>자동 진행"]
  PRI["primaryUpdateMethod로<br/>primary 교체"]

  START --> R2 --> DONE
  DONE -->|"아니오"| R2
  DONE -->|"예"| STRAT
  STRAT --> SUP
  STRAT --> UNSUP --> PRI

primaryUpdateStrategy: primary를 언제 넘길까

replica 교체가 끝난 뒤 primary를 어떻게 처리할지는 primaryUpdateStrategy가 정한다.

unsupervised (기본값) — 전 과정이 자동이다. replica 업그레이드가 끝나면 primaryUpdateMethod가 알아서 실행되어 primary까지 교체한다. 대부분의 환경에 적합하다.

primaryUpdateMethod: 재시작이냐 switchover냐

primary를 실제로 교체하는 방식은 primaryUpdateMethod가 정한다.

restart (기본값): primary pod를 그 자리에서 재시작한다. 재시작이 실패하면 switchover로 넘어간다.
switchover: 가장 앞선 replica를 새 primary로 승격한 뒤 옛 primary pod를 내린다.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  primaryUpdateStrategy: unsupervised
  primaryUpdateMethod: switchover
  storage:
    size: 1Gi

switchover를 쓸 때는 이미지 이름과 PostgreSQL 설정 파라미터를 동시에 바꿀 수 없다. 둘을 한 번에 바꾸려 하면 안 되고, 순서를 나눠 차례로 적용해야 한다.

restart와 switchover, 언제 무엇을

restart는 primary가 재시작되는 동안 짧게 쓰기가 멈추지만 primary가 그대로 유지된다. switchover는 primary 역할이 다른 pod로 넘어가므로, 승격이 끝나는 순간 클라이언트가 새 primary로 다시 연결한다. 둘 다 무중단을 지향하지만 쓰기가 끊기는 짧은 창은 존재하므로, 애플리케이션은 연결 재시도(retry)를 갖춰 두는 편이 안전하다.

정리

rolling update는 replica부터 한 번에 하나씩 교체하고 primary를 마지막에 처리해 중단을 최소화한다
이미지·extension·restart 필요 설정·resource 변경·Operator 업그레이드가 update를 부른다
primaryUpdateStrategy로 primary 전환을 자동(unsupervised)으로 둘지 수동(supervised)으로 둘지 정한다
primaryUpdateMethod로 primary를 재시작(restart)할지 switchover할지 고른다. switchover 시 이미지와 설정 동시 변경은 금지된다

다음 절(6.4)에서는 하나의 Kubernetes 클러스터를 넘어, 다른 리전에 replica cluster를 두어 재해에 대비하는 replica clusters를 본다.

6.2 자동 failover 6.4 Replica clusters