오퍼레이터 & MySQL 오퍼레이터 (2) - Operator 작동 방식

CloudNet@ 팀의 가시다님이 진행하는 Database Operator In Kubernetes study 스터디 중 Operator 내용에 대해 정리하였습니다.

 

Kubernetes Operators 의 구조

Kubernetes 클러스터는 Operator 를 워크로드로 배포된 애플리케이션처럼 처리합니다. 이 특수 응용 프로그램은 Kubernetes에서 호스팅되는 다른 응용 프로그램과 같은 다른 리소스를 관리합니다
Operator 는 Managed Resource 집합을 사용하여 Operand 를 관리합니다.

• Operand : Operator 가 Service 로 제공하는 Managed Resource입니다.
• Managed Resource : Operator 가 Operand 를 만드는 데 사용하는 Kubernetes 개체입니다.

기본적으로 Kubernetes는 stateless 워크로드를 잘 관리합니다. Kubernetes가 동일한 논리를 사용하여 모두 관리할 정도로 유사합니다. Stateful 워크로드는 더 복잡하고 각각 다르기 때문에 맞춤형 관리가 필요합니다. 여기에서 Operator 가 들어옵니다.

기본 Operator 는 다음과 같은 구성 요소로 구성됩니다.

Operator 구조

• API : Operand 의 구성을 설명하는 데이터입니다. API에는 다음이 포함됩니다.
  • Custom resource definition (CRD) : Operand 구성에 사용할 수 있는 설정 스키마를 정의
  • Programmatic API : CRD 와 동일한 데이터 스키마를 정의하고 Go와 같은 운영자의 프로그래밍 언어를 사용하여 구현되는 프로그래밍 API.
  • Custom resource (CR) : CRD 에서 정의한 설정 값을 지정 Operand 구성을 설명
• Controller : Operator 의 두뇌. 컨트롤러는 Custom Resource 의 설명을 기반으로 Managed resource 를 생성합니다. 컨트롤러는 Go와 같은 운영자의 프로그래밍 언어를 사용하여 구현됩니다.
• Role and service accounts : 컨트롤러가 Managed resource 를 생성할 수 있는 권한이 있는 Kubernetes RBAC (역할 기반 액세스 제어) 리소스입니다.

Operator 는 Worker Node 와 Control Plane의 구성요소만 사용합니다.

Operator 는 Worker Node 에서 실행됩니다. 그러나 Operator 는 Control Plan 에서 실행되는 컨트롤러를 구현합니다.
Operator 는 Worker Node 에서 컨트롤러를 실행하기 때문에 Control Plane 을 Worker Node 로 효과적으로 확장할 수 있습니다.

클러스터에는 항상 desired 상태와 current 상태의 두 가지가 있습니다. desired 상태는 클러스터에 있어야 하는 개체를 나타냅니다. current 상태는 실제로 존재하는 개체를 나타냅니다. 컨트롤러는 클러스터의 상태를 관리하여 current 상태를 desired 상태와 일치시킵니다. Kubernetes 컨트롤러는 Control Plane 에서 실행됩니다.

거의 모든 Kubernetes 객체에는 객체의 desired 상태와 current 상태를 저장하는 두 개의 중첩된 객체 필드(스펙 섹션에 의해 YAML에 표시됨)와 상태(상태 섹션에 의해 YAML에 표시됨)가 포함됩니다.이 두 필드는 Operator Controller 가 operands 를 조정(reconcile) 하기 위해 사용하는 필드입니다.
desired 상태를 업데이트하려면 사용자 지정 리소스의 규격 필드에 있는 설정을 업데이트합니다.
클러스터가 operands 를 업데이트하면 컨트롤러는 관리 대상 리소스의 current 상태를 상태 필드에 저장하여 Custom Resources 의 현재 상태를 저장합니다.

Kubernetes에서의 워크로드 도입

Operator 가 워크로드를 배포 및 관리하는 방법은 관리자 가 워크로드를 배포 및 관리하는 방법과 유사합니다.

Kubernetes 클러스터에 배포된 기본 워크로드의 구조

워크로드는 Pod 복제본(replicas)을 실행하는 Deployment 로 구성되며, 각 복제본(replicas) 은 중복 컨테이너를 실행합니다. 
Deployment 는 클라이언트에서 복제본(replicas) 의 동작을 호출할 수 있는 단일 endpoint 을 제공하는 Service 로 노출됩니다.

Operator 가 워크로드를 배포하는 방법

Operator 는 인간 관리자(또는 빌드 파이프라인)와 매우 유사한 방식으로 워크로드를 배포합니다. 
Operator 는 결국 IT 관리자가 수행하는 작업을 자동화해야 합니다.

Kubernetes API는 클라이언트가 관리자인지 Operator 인지 알지 못하므로 클러스터는 동일한 방식으로 워크로드를 배포합니다. 컨트롤 플레인에서 일어나는 모든 일은 동일합니다.

워크로드 배포 방법

Kubernetes의 워크로드 배치

관리자는 kubectl CLI 및 YAML 파일과 같은 클라이언트 도구를 사용하여 워크로드를 배포할 리소스와 같은 어떤 리소스를 생성해야 하는지 클러스터에 알려줍니다.

• 클라이언트 도구는 Control Plane  의 인터페이스인 Kube API와 통신합니다.
• API는 클러스터가 desired 상태를 변경하여 명령을 수행합니다. 
• Control Plane 의 컨트롤러는 클러스터의 current 상태를 변경하여 desired 상태와 일치시킵니다.

Operators 워크로드 배치

Operator 가 워크로드를 배포 할 때 다음과 같은 작업을 수행합니다.

• Custom Resources 은 관리자의 YAML 파일처럼 작동하여 배포해야 하는 리소스에 대한 추상적인 설명을 제공합니다.
• 컨트롤러는 API를 사용하여 Custom Resources 을 읽고 Kubernetes API를 사용하여 관리자 실행과 마찬가지로 Custom Resources 에 의해 기술된 리소스를 만듭니다. (kubectl명령어를 지정합니다.)
• 어느 쪽이든 desired 상태를 업데이트하여 클라이언트의 명령을 수행하며, 이 상태를 current 상태를 업데이트하기 위해 Kubernetes Controller 가 사용합니다. 이러한 방식으로 Operator 는 관리자가 수행할 작업을 수행하지만 컨트롤러 구현에 포함된 자동화된 방식으로 수행합니다.

Operators가 Kubernetes 클러스터 상태를 조정(reconcile) 하는 방법

Kubernetes 클러스터에는 항상 두 가지 상태가 있습니다.
desired 상태는 클러스터에 있어야 하는 개체를 나타내며 current 상태는 실제로 존재하는 개체를 나타냅니다.

Kubernetes Operators에서는 컨트롤러가 클러스터 상태를 관리하여 current 상태를 desired 상태와 일치하도록 조정(reconcile) 합니다. 
Kubernetes Controller 는 Control Plane 에서 동작합니다.

Control Plane 의 Reconciliation Loop

일반적인 Kubernetes 클러스터에서는 Controller Manager 가 Control Plane 내의 Reconciliation Loop 에서 컨트롤러를 실행합니다.각 컨트롤러는 클러스터 동작의 특정 부분을 관리합니다. Controller Manager 는 Reconciliation Loop 를 실행하여 각 컨트롤러를 실행할 수 있도록 합니다

컨트롤러가 조정되면 컨트롤러의 태스크는 현재 상태를 조정하여 Desired State 와 일치하도록 합니다.

Kubernetes reconciliation loop

Worker Node 의 Reconciliation Loop

Kubernetes 컨트롤러는 Control Plane 으로 동작하지만 오퍼레이터의 컨트롤러는  Worker Node 로 동작합니다.이는 오퍼레이터가 워크로드로 Kubernetes 클러스터에 배포되기 때문입니다. 또한 다른 워크로드와 마찬가지로 클러스터도 작업자 노드에서 운영자의 워크로드를 호스팅합니다.

각 오퍼레이터는 Controller Manager 의 컨트롤러 리스트에 커스텀컨트롤러를 추가함으로써  Reconciliation Loop 를 확장합니다

Controller Manager 는 Reconciliation Loop 를 실행할 때 다음 두 가지 작업을 수행합니다.

• Control Plane 내의 각 컨트롤러에게 조정(reconcile) 하도록 지시합니다.
• 각 Operator 의 커스텀컨트롤러 에 대해 조정(reconcile) 하도록 지시합니다.

Reconcile states

Reconcile states

Operator Controller 는 Kubernetes Controller 보다 한 단계 높은 추상화를 수행합니다.

Kubernetes Controller 는 Deployment 및 Job과 같은 기본 제공 유형(kinds)  을 Pod 와 같은 하위 수준 유형(kinds) 으로 조정합니다. 
Custom Controllers 는 Memcached 및 Etcd와 같은 CRD를 Deployment 및 Service 와 같은 워크로드 종류로 조정(reconcile) 합니다. 
따라서 Custom Controllers 의 현재 상태는 Kubernetes 컨트롤러의  Desired State 가 됩니다.

두 종류의 컨트롤러 모두 desired 와 current 상태를 조정(reconcile) 하지만 Operator 의 Custom Resources 에 대한 워크로드를 배포하려면 두 번의 변환이 필요합니다.

• Operator Controller 는 Custom Resources 를 Operator 의 current 상태인 동시에 Control Plane 의 desired 상태인 관리되는 리소스 집합(즉, 워크로드)로 변환합니다
• Kubernetes Controller 는 관리되는 리소스를 Control Plane 의 current 상태에서 실행 중인 Pods (operand 라고도 함)로 변환합니다.

Operators 는 다음과 같은 몇 가지 점에서 Kubernetes와 동일하게 작동합니다.

• Operator 의 뇌는 Control Plane 내의 일반적인 Kubernetes Controller 와 같은 역할을 하는 컨트롤러입니다.
• Operator 가 워크로드를 배포하는 방법은 관리자가 워크로드를 배포하는 방식과 유사합니다. Control Plane 은 차이를 모릅니다.
• Control Plane 은 각 컨트롤러가 스스로를 조정(reconcile) 할 수 있는 Reconciliation Loop 를 구현하고, 운영자는 해당 루프에 컨트롤러를 추가합니다.
• Kubernetes Controller 와 Custom Controllers 가 desired 상태와 current 상태 사이에서 조정(reconcile) 되는 동안 Operator 는 desired 상태를 Custom Resources 로 관리하고 Kubernetes Controller 가 desired 상태로 사용하는 관리된 리소스 집합인 current 상태로 조정(reconcile) 합니다.

 

 

https://developers.redhat.com/articles/2021/06/22/kubernetes-operators-101-part-2-how-operators-work#
내용을 번역, 정리하였습니다.