CRD, CR, Operator - Zalando PostgreSQL Operator로 확인해보기

오퍼레이터 (Operator) - 건설회사(CRD+CRD Controller)

CRD (Custom Resource Definition) - 건축물 설계서

CRD Controller - 건축물 설계서의 변경, 추가사항 등을 확인
CR (Custom Resource) - 설계서로 만들어진 건물(인스턴스)

 

PostgresDB 클러스터 관련해서 Zalando PostgreSQL Operator를 많이 사용

-> 이것을 만들어보면서 CRD, CR, 오퍼레이터가 뭔지 알아보려고 함

 

기본개념

yaml에 적히는 kind에는 Pod, service, Deployment....등등이 존재

하지만 사용자가 기본 kind들이 아닌 새로운 사용자만의 kind를 추가하고싶을때 등장하는것이 오퍼레이터와 CRD

오퍼레이터가 CRD를 통해 새로운 kind를 추가해준다.

 

왜 사용?

클러스터 부트스트래핑, 노드 간 통신 설정, 데이터 복제 관리, 스케일링 시 데이터 재분배, 특정 버전으로의 안전한 업그레이드, 백업 및 복구 등의 작업, 클러스터링된 애플리케이션 등등

이런것들은 기본 k8s 리소스들만으로는 자동화하기 어려움

 

-> 이런 형태의 앱들을 자동화해서 관리할 수 있도록 오퍼레이터가 등장, Kubernetes API를 통해 PostgreSQL 클러스터의 생성, 스케일링, 고가용성 구성, 백업 및 복구, 버전 업그레이드와 같은 복잡한 운영 작업을 자동화한다는 것

사용자가 직접 CRD를 정의해서(예를들면 kind에 user-own-app이라는 리소스를 생성) 사용이 가능

혹은 Zalando 오퍼레이터같은 경우 오퍼레이터가 CRD를 클러스터에 등록해줌

 

 

클러스터 기본구성

마스터노드와 워커노드 2대
3노드DB 클러스터

마스터노드에는 NoSchedule taint 존재, 워커노드에 DB클러스터 구축하고자 함

 

과정

1. 네임스페이스 생성

-> postgres-operator

 

 

2. ConfigMap

-> 오퍼레이터가 어떻게 작동을 할것인가를 설정하는 것.

오퍼레이터가 어떤 docker image를 불러올것인지부터 시작해서 이것들이 어떻게 작동할것인지가 나온다.
PostgreSQL 리소스를 어떤 정책으로 생성/관리할지를 결정한다는 것.

 

3. RBAC + 서비스 계정 생성

이 계정이 컨트롤러의 역할을 하려면 권한이 있어야 함. create, delete get 등등 확인됨

 

4. 실제 오퍼레이터 배포

오퍼레이터가 파드형태로 배포됨.

 

5. CR을 생성

오퍼레이터가 배포되면서 CRD를 설치했을것이고, 사용자는 어떤 형태의 CR을 만들것인지 요청하면됨.

kubectl get crd로 확인하였을때 맨 아래에 postgresql crd가 존재하는걸 확인.

칼리코의 crd도 보인다.

세개의 DB인스턴스로 구성된 클러스터를 만들려고 한 상황

 

6. DB 파드 생성 확인

 

7. 클러스터링 확인

 

my-pg-db-0 파드를 죽였을때 리더도 잘 바뀌어서 선출됨.

 

8. 그럼 클러스터링은 누가?

Zalando 오퍼레이터 내부의 Patroni라는 클러스터매니저가 클러스터링을 수행함.

 

-> 결국 원래대로 돌아와서 중요한것은 사용자는 CR만 생성했고, 클러스터링은 알아서 진행되었다는 것

-> 설계도를 가져와서, CR을 생성하고, 그 이후는 자동. 왜냐하면 이걸 모든 인스턴스에 일일이하기 어려우니까


* 
Patroni 인스턴스 -> Patroni라는 클러스터 매니저가 작동중인 인스턴스, 여기선 my-pg-db-0,1,2
DCS(Kubernetes API 또는 etcd, DCS=분산 설정 시스템이지만 모든 인스턴스가 정보를 함꼐 바라볼수있는 공통의 공간)

이곳에 Lock을 먼저 잡는 인스턴스가 리더

Lock: 일반적인 개념은 내가 실행중일때 다른 객체가 접근하지 못하도록하는 것이지만, 여기선 '리더 정보를 먼저 DCS에 저장했다'의 개념 -> 먼저 다른 인스턴스가 저장했으면 내가 먼저 저장하지 못했다라는 것