이전글입니다. -> 애플리케이션 배포를 위한 고급 설정
기본적인 리소스 외에도 직접 리소스의 종류를 정의해 사용할 수도 있는데, 이를 커스텀 리소스라고 부른다. 커스텀 리소스를 제대로 사용하려면 컨트롤러라고 하는 별도의 컴포넌트를 이해하고 구현할 수 있어야 한다.
쿠버네티스 컨트롤러의 개념과 동작 방식
명령형(Imperative) vs. 선언적(Declarative)
특정 명령을 처리하는 주체와 통신해 그 작업을 수행하고 그 결괏값을 돌려받는 방식을 명령형이라고 말합니다(kubectl run ~).
쿠버네티스는 이와 반대되는 선언형 방식을 지향합니다. 선언형 방식은 최종적으로 도달해야 하는 바람직한 상태를 정의한 뒤, 현재 상태가 바람직한 상태와 다를 경우 이를 일치하도록 만드는 방법입니다.
명령형 방식은 kubectl create, kubectl run 명령어를 사용해서 리소스를 생성한 뒤, 다시 사용하면 이미 리소스가 존재해서 새롭게 생성할 수 없다고 오류를 반환합니다.
하지만 선언형 바식은 kubectl apply -f 명령어로 특정 YAML 파일이 최종적으로 완성돼야 하는 상태라는 것을 쿠버네티스에게 알려줄 뿐, 실제로 어떠한 동작을 취해야 하는지는 명시하지 않습니다. 최종적으로 완성돼야 하는 상태가 되기 위해 어떠한 동작을 취할지는 쿠버네티스에서 컨트롤러라고 불리는 개체가 내부적으로 결정합니다.
쿠버네티스 컨트롤러는 모두 개별적으로 존재할 수도 있으나, 쿠버네티스는 전체 구성의 복잡성을 줄이기 위해 컨트롤러 로직을 쿠버테티스 컨트롤러 매니저라는 하나의 컨포넌트에 구현해 놓았습니다.
컨트롤러 매니저에는 디플로이먼트 컨트롤러, 노드 컨트롤러 등 다양한 컨트롤러가 동시에 실행됩니다. 이런 컨트롤러들은 쿠버네티스 리소스의 상태 변화를 감지하고 적절한 작업을 수행하도록 구현돼 있습니다.
커스텀 리소스에 대한 개념
커스텀 리소스를 사용하는 방법에는 여러 가지가 있습니다. 디플로이먼트, 서비스 등의 오브젝트의 묶음을 커스텀 리소스로 추상화함으로써 쿠버네티스 리소스를 묶어 놓은 패키지처럼 사용할 수도 있고, 쿠버네티스와 전혀 상관이 없는 로직을 커스텀 리소스와 연동할 수도 있습니다.
예를 들어, 웹 애플리케이션을 WebApp이라는 이름의 커스텀 리소스로 만들었다면 이 커스텀 리소스에는 프론트엔드 서버, 백엔드 서버, 데이터베이스 프플로이먼트, 그리고 각 포드가 서로 통신하기 위한 여러 서비스 리소스를 한꺼번에 생성할 수 있으며, 각 리소스의 생애 주기를 쉽게 관리할 수 있습니다. 커스텀 리소스를 사용함으로써 복잡하고 많은 리소스에 대한 관리의 복잡성을 줄일 수 있으며 쿠버네티스의 오브젝트를 원하는 대로 확장해 사용할 수 있습니다.
커스텀 리소스를 사용하기 위한 단계
- 현재 상태를 커스텀 리소스에 대한 바람직한 상태로 변화시킬 수 있는 컨트롤러를 구현하고, 컨트롤러를 실행합니다.
- 커스텀 리소스의 상세 정보를 정의하는 CRD(Custom Resource Definition) 리소스를 생성합니다.
- CRD에 정의된 데이터에 맞춰 커스텀 리소스를 생성합니다.
- 1번에서 실행한 컨트롤러는 커스텀 리소스의 생성을 감지하고, 커스텀 리소스가 원하는 바람직한 상태가 되도록 적절한 작업을 수행합니다.
커스텀 리소스를 정의하기 위한 CRD(Custom Resource Definition)
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: inhyos.ihp001.com
spec:
group: ihp001.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
required: ["spec"]
properties:
spec:
type: object
required: ["myvalue"]
properties:
myvalue:
type: "string"
minimum: 1
scope: Namespaced
names:
plural: inhyos
singular: inhyo
kind: Inhyo
shortNames: ["ih"]- metadata.name : CRD의 이름은 반드시 spec.names.plural + "." + spec.group 형태이어야 합니다.
- spec.group, version : API 그룹과 버전을 설정합니다(아래 사용 예시).
apiVersion: ihp001.com/v1
kind: Inhyo
...- spec.names : plural은 커스텀 리소스의 복수형을, singular는 단수형을 의미합니다. kind는 YAML 파일 등에서 Kind 항목에서 커스텀 리소스를 나타낼 때 사용할 이름을, shortNames는 커스텀 리소스를 줄여서 부를 이름을 설정합니다.
- spec.versions[schema] : 실제로 커스텀 리소스에 어떤 데이터가 저장돼야 하며, 어떠한 항목이 반드시 설정돼야 하는지 정의합니다. required: ["spec"]을 통해 '커스텀 리소스에는 반드시 spec이라는 항목이 임ㅆ어야 한다는 것을 명시해줬습니다. 또 spec의 하위에 반드시 myvalue라는 항목이 있어야 하며, 이 값은 문자열이어야 합니다.
이런 CRD의 설정 값들을 모두 만족하는 커스텀 리소스의 YAML 파일을 작성합니다.
apiVersion: ihp001.com/v1
kind: Inhyo
metadata:
name: my-custom-resource
spec:
myvalue: "This is my value"커스텀 리소스와 컨트롤러
커스텀 리소스 그 자체는 etcd에 저장된 단순한 데이터일 뿐, 실제로 동작하고 있는 포드나 서비스는 아니기 때문에 커스텀 리소스를 생성했을 때 특정 동작을 수행하도록 정의하는 컨트롤러를 별도로 구현해야만 커스텀 리소스가 비로소 의미를 갖게 됩니다.
예를 들어, 레플리카 셋의 목적은 라벨 셀렉터가 일치하는 일정 개수의 포드를 생성하는 것이었고 이를 위한 동작은 컨트롤러 매니저라는 컴포넌트 내부에서 수행됩니다. 이처럼 커스텀 리소스가 어떠한 목적을 위해 생성되는지 비즈니스 로직으로 구현해 놓은 별도의 컨트롤러가 필요합니다. 이 비즈니스 로직은 커스텀 리소스가 원하는 바람직한 상태를 계속해서 유치하도록 만드는 소스코드로 구현되어야 합니다.
이처럼 현재 상태가 바람직한 상태가 되도록 특정 동작을 수행하는 것을 쿠버네티스에서는 Reconcile이라고 부릅니다.
그리고 이러한 일련의 동작을 통해 CRD를 사용할 수 있도록 컨트롤러를구현하는 방법을 오퍼레이터 패턴이라고 부릅니다.
컨트롤러를 쉽게 개발할 수 있도록 도와주는 Operator SDK, KubeBuilder와 같은 프레임워크글 사용하면 Reconcile에서 어떠한 동작을 수행할 것인지만을 구현함으로써 쉽게 컨트롤러를 개발할 수 있습니다.
