개요

쿠버네티스 controller는 선언된 상태와 실제 상태를 탐지하고 이를 맞추려고 하는 무한 루프 프로세스이다.
쿠버네티스의 큰 장점인 자동 확장, 자동 복구 같은 것들은 전부 이 컨트롤러가 수행해주는 것이라고 보면 되겠다.

기본적인 쿠버네티스의 컨트롤러들은 kube-controller-manager에 의해 관리된다.
해당 매니저 프로세스에 여러 컨트롤러 프로세스가 내재되어 동작하고 있다.

직접 커스텀 컨트롤러를 만드는 것도 가능한데, Kubebuilder 같은 것을 사용하면 쉽게 시작해볼 수 있다.

동작 구조

컨트롤러는 크게 두 가지 동작을 한다.

• 감시(watch)
  • 클러스터의 현재 상태(current state)를 감시한다.
  • 사용자의 희망 상태(desired state)를 감시한다.
• 재조정(reconcile)
  • 희망 상태에 맞춰 현재 상태를 재조정한다.

클러스터의 정보 조회와 조작은 모두 kube-apiserver를 통해 이뤄지므로, 위 동작은 결국 전부 api서버와의 통신을 통해 이뤄진다.
컨트롤러의 동작에만 초점을 맞추어 간단한 예시를 들어보자.

• 사용자가 잡 리소스를 만들라고 api서버에 요청한다.
  • kubectl apply, create 등의 명령이 바로 이러한 요청이다.
• api서버는 사용자가 요청한 잡 리소스를 그대로 Etcd에 저장한다.
• 컨트롤러 매니저의 잡 컨트롤러는 잡 관련 리소스(잡 그 자체, 파드)에 대해 지속적으로 api서버로부터 이벤트를 수신하는 감시 루프를 돌고 있다.
• api서버로부터 실제로 생성되지 않은 잡 리소스가 있다는 것을 파악한다.
  • spec 필드(희망 상태)는 채워져있는데 status 필드(현재 상태)는 비워져 있으니 이 둘을 맞춰야 한다는 것을 알게 된다.
• 잡 컨트롤러는 status 필드를 요청에 맞게 채우는 재조정 작업을 한다.
  • 희망 상태에 맞춰 api서버에 파드 리소스를 만들라는 요청을 보낸다.
  • 컨트롤러 스스로 한 작업을 잡 리소스의 status 필드에 채워 api 서버에 patch한다.

파드 리소스를 보고 작업을 하는 건 kube-scheduler인데, 이 부분은 컨트롤러와는 관련이 없으니 생략한다.
결국 사용자가 잘 정제된 형태로 리소스를 등록만 하면 이에 맞춰서 실제로 클러스터에 반영하는 것은 컨트롤러이다!
즉, 사용자가 희망하는 상태를 선언해두고 클러스터가 이를 따라가게 하는 쿠버네티스의 선언적 관리 기능은 바로 이 컨트롤러에서 기반하는 것이다.

리소스 업데이트 과정도 결국 이와 비슷하다.
그냥 spec 부분과 status 필드가 다른 것을 보고 이를 맞춰주는 작업을 할 뿐이다.
잡 같은 리소스는 잡의 파드가 실행되고 완료되거나 실패하는 여러 중간 상태가 있는데, 이런 것들을 status 필드에 반영해주는 작업 역시 컨트롤러가 도맡는다.

오퍼레이터 패턴

오퍼레이터 패턴은 어떤 설정이나 컴포넌트 대상을 쿠버네티스의 커스텀 리소스로 등록하고 컨트롤러를 통해 관리하게 하는 방식의 디자인 패턴을 말한다.^[1]

배경

문서의 표현을 빌리자면, 오퍼레이터 패턴은 서비스를 관리하는 인간 운영자의 관심사, 목표를 포착하는 것이 핵심 목표이다.
운영자가 해야 하는 작업들에 대한 자동화를 도와주기 위한 컨트롤러를 오퍼레이터라고 부른다는 것이다.
근데 이 표현은 너무 추상화돼서 오히려 감이 안 잡히는 것 같다.
내 방식대로 오퍼레이터 패턴이 등장한 배경을 말하자면..

쿠버네티스 위에 애드온이나 시스템을 구축할 때, 클러스터 네이티브하게 각종 설정을 하고 운영하고 싶을 수 있다.
가령 프로메테우스를 클러스터에 구축한다고 생각해보자.
이때 프로메테우스에 넣어야 하는 각종 설정들은 프로메테우스 서버 프로세스를 가동할 때 인자로 전달하던가, 제공되는 api로 동적으로 설정을 주입해줘야 한다.
이러한 방식은 쿠버네티스를 운영하는 것과 별개로 설정해야 하는데, 아예 이런 것도 쿠버네티스 네이티브하게 관리할 수 없냐 하면서 나온 것이 바로 오퍼레이터 패턴이다!
프로메테우스 오퍼레이터는 이러한 니즈를 위해 등장한 오퍼레이터로, 프로메테우스에서의 각종 컴포넌트와 설정 파일을 클러스터의 커스텀 리소스로 등록하고 이를 관리하는 컨트롤러를 둔다.
그래서 사용자가 해당 리소스에 대해 어떤 설정을 넣으면, 해당 컨트롤러가 그 리소스를 읽어서 실행되고 있는 프로메테우스 시스템에 이를 반영한다.

그래서 나는 오퍼레이터의 기능을 이 정도로 정리하고자 한다.

• 클러스터에 구축한 시스템, 소프트웨어를 클러스터 네이티브하게 관리한다.
  • kubectl을 이용해서, 양식 파일을 둔 채로 선언적으로 관리 가능.

관련 문서

참고

• 문서

https://jh-labs.tistory.com/503