[DOIK 스터디 2기] Kubernetes Operator 개념과 Database 관련 Operator 얕게 알아보기

가시다님 주관 DOIK(Database Operator In Kubernetes) 스터디를 참여하게 되었다.

 

이번 기회를 통해 Operator 패턴과 Database 및 DB 운영에 대한 지식을 많이 늘렸으면 좋겠다..

 

1주차 과제로 Kubernetes Operator 개념과 Database 관련 Operator들을 간단하게 알아보고자 한다.

 

1. Kubernetes Operator?

Operator란 무엇일까? 관리자란 뜻이다.

쿠버네티스 관리자라는 뜻인데 무엇을 관리한다는 걸까?

 

Operator는 특정 대상(ex. DB, ..) 소프트웨어 운영 및 관리를 자동화하기 위한 방법론이다.

 

DB 운영을 생각해보자. DB 운영을 하기 위해서는 다음의 운영들이 필요할 수 있다.

- Master가 죽으면 Slave 중 1대가 Master로 승격되도록 한다.
- 주기적으로 DB Backup을 수행한다.

이런 작업들을 사람들이 하면 잠은 대체 언제 잘까? 이를 뭔가 쿠버네티스 상에서 자동화할 순 없을까?

단순 자동화 뿐 만 아니라 지정한 설정값을 넣으면 그에 따라 Operator가 운영을 자동으로 수행하도록 할 수 없을까? 라는 고민에서 나온게 Operator 패턴이다.

결국 특정 서비스를 잘 운영되게 끔 실행시키고 관리해주는 놈을 Operator라고 할 수 있다.

그럼 Operator를 이해하기 위해 필요한 개념들을 하나씩 살펴보자.

 

 

1.1. Controller

컨트롤러란 뭔가를 컨트롤하는 객체다. 즉 특정 리소스를 지속적으로 바라보며 정해진 작업을 수행하는 주체이다.

컨트롤러의 예시는 쿠버네티스에 내장되어 있는 ReplicaSet Controller, Deployment Controller 등이 있다.

 

참고로 내장되어 있지 않는 Controller는 Custom Controller라고 부른다.

 

 

 

1.2. Custom Resource, Custom Controller

Custom Resource Definition : 오퍼레이터가 관리할 객체들의 스펙을 정의한 명세서이다.

Custom Resource란 CRD 스펙을 지키며 Desired State를 정의하는 데이터 조합이다.

즉 CRD는 커스텀 리소스에 대한 명세서이고, CR은 명세서를 기반으로 원하는 상태에 대해서 정의한 설정값이라고 생각하면 된다.

Custom Controller는 CRD에 명시된 스펙을 확인하고, CR이 제출되면 이 설정값을 확인하여 원하는 상태로 리소스들을 배포하고, Control Loop을 계속 돌면서 체크하고 그에 리소스를 조정한다.

예를 들어 Nginx를 관리하는 Operator를 만든다고 생각해보자.

CRD에서는 대충 scope(범위)가 Cluster 레벨인지 Namespace 레벨인지, 각 어떤 변수들이 CR에 필요하고 그에 따른 스펙이 어떻게 되는지, API version이 무엇인지 등을 정의할 것이다.

CR에서는 CRD 스펙에 따라서 대략 다음처럼 만들 수 있을 것이다.

 

apiVersion: "extension.example.com/v1"
kind: Hello
metadata:
  name: hello-nginx
replicas: 3

이제 이를 관리할 수 있는 Custom Controller를 만들어 CR 객체가 들어오면 어떤 작업을 수행할 것인지 코드로 만들어줘야 한다.

 

최종적으로 Kubernetes 리소스를 만들어줘야 하는데 위 예시에서는 Pod를 만들어줄 것이다.

 

이해가 잘 안될 수 있으니 그림으로 확인해보자.

 

 

• 사용자가 Custom Resource YAML 파일을 Kubernetes에 제출한다.
• Kubernetes Operator(Custom Controller)는 이를 감지(watches)하고 Kubernetes API를 호출하여 원하는 상태(adjust state)로 만들어준다.
• 이를 무한 반복한다.

 

즉 Operator Pattern을 이해하기 위해서는 다음의 개념들을 잘 알고 있으면 된다.

 

• Custom Resource Definitions (CRD)
• Custom Resource(CR)
• Custom Controller(CC)
• Control Loop

 

물론 실제 Operator를 직접 만들어보기 위해서는 추가적인 지식이 필요하지만 큰 틀만 이해하기 위해서는 이정도면 충분하다고 본다.

 

 

2. MySQL Operator

MySQL Operator는 MySQL 서버와 MySQL 라우터로 이루어진 MySQL InnoDB 클러스터를 관리해준다.

 

즉 InnoDB 클러스터라는 추상화된 Custom Resource로 MySQL Server와 Router 관리를 자동화하고 간편하게 만들어주는 역할을 한다.

 

 

MySQL Router : 작업을 실행할 서버를 고르는 Stateless 애플리케이션으로 DB 인스턴스를 캐싱하여 라우팅 할 인스턴스를 관리한다.

MySQL Server Instance : 실제 DB 역할을 하게 되는 인스턴스 그룹으로 2가지 Mode가 존재한다.

Single Primary Mode : Master-Slave 구조의 복제 방식

Multi-Primary Mode : MySQL 8.0 버전에 등장한 Group Replication 복제 방식을 사용해 양방향 복제를 수행할 수 있음

MySQL Operator : Deployment로 관리되며 Operator가 InnoDBCluster, Mysqlbackup 등 Custom Resource를 통해 각 서버 클러스터와 서버 백업을 추상화하여 관리한다.

 

 

3. Strimiz Kafka Operator

Strimiz는 Kafka Cluster 운영에 도움을 주는 Operator이다.

strimzi의 특징으로는 다음과 같다.

• Kafka 클러스터 구성요소 배포, 관리
• Kafka 커넥트 설정
• Kafka 업그레이드 설정
• Broker 관리
• Topic, User 생성 관리

strimzi Kafka에서 제공하는 Operator는 3가지가 있다.

• Cluster operator : Kafka cluster, Kafka connect cluster 등 다양한 cluster를 생성
• Topic operator : Broker의 Topic을 생성, 변경, 삭제해주는 역할을 수행
• User operator : User 설정을 통해 Kafka에 접근할 때 접근을 승인하거나 권한을 준다.

 

 

관련 자료를 살펴보고 싶은 경우 아래 Strimzi 공식 문서를 확인해보자. 매우 자세히 설명되어 있음

https://strimzi.io/docs/operators/latest/overview

 

 

4. Percona Operator for MongoDB

Percona Operator for MongoDB는 MongoDB 데이터베이스 클러스터를 관리하고 배포하는 것을 도와준다.

Kubernetes에서 MongoDB를 실행하고 스케일링, 백업, 모니터링 등 다양한 관리 작업을 자동화하는데 도와준다.

 

다음은 Percona Operator for MongoDB의 특징들이다.

자동 스케일링: Percona Operator는 클러스터에 대한 자동 스케일링을 지원하여 서버 부하에 따라 인스턴스를 동적으로 추가하거나 제거할 수 있다.

백업 및 복원: 데이터의 안전성을 유지하기 위해 백업 및 복원 작업을 자동화하고 백업 스케줄링 및 데이터 복원을 관리할 수 있다.

모니터링과 경고: 클러스터의 상태를 모니터링하고 이벤트나 장애 상황에 대한 경고를 생성할 수 있다.

 

 

참고

https://miny0529.tistory.com/17

https://jackcokebb.tistory.com/7

https://medium.com/techblog-hayleyshim/k8s-percona-distribution-for-mongodb-operator-72554c904b54