Kubernetes Custom Resource 개념
Kubernetes Custom Resource 개념
[Kubernetes Custom Resource 관련글 목록]
Kubernetes Version 1.18 에 해당함.
Custion Resource Definition (CRD) Python
Custom Resource Definition (CRD) GoLang
Custom Resource란?
Addon은 어떻게 만들어졌을까?
관리자가 더 편리하고 효율적으로 kubernetes를 관리하기 위해
Kubernetes에서 기본적으로 제공해주는 기능보다 더 다양한 기능이 필요할때가 있음.
그럴 때 사용했던게 Kubernetes Cluster기능을 구현 및 확장하는 역할을 담당하는 Addon이였음.
그렇다면 Addon은 어떻게 기능을 추가적으로 구현 혹은 확장하는지 궁금해짐
다양한 Addon을 사용하다보면 kubernetes에서 제공하는 apiVersion이 아닌
Addon이 제공하는 apiVersion을 본적이 있을것임.
그 예제로 아래와 같이 portieris Addon에서 사용하는 yaml의 apiVersion 항목을 보면
portieris Addon만의 고유의 apiVersion인
securityenforcement.admission.cloud.ibm.com/v1beta1을 사용하는것을 볼 수가 있음
[예제 portieris의 ImagePolicy.yaml]
| apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1 kind: ImagePolicy metadata: name: iksoon-custom namespace: iksoon-ns spec: repositories: - name: "iksoon.docker.com:5000/*" policy: trust: enabled: true trustServer: "https://notary-server:4443" |
위와같이 Kubernetes에서는 직접 apiVersrion를 구현해서 사용할 수 있는 기능을 제공하고 있음
이때 사용하는 kubernetes 기능이 바로 Custom Resource임.
Custom Resource란?
Kubernetes는 Opensource라는 특징을 유지하기 위해
처음부터 사용자가 필요한 기능을 모두 구현해놓기보다,
사용자가 필요한 기능을 직접 구현해서 사용할 수 있도록 설계를 해놓았음.
그래서 Kubernetes API는 구조가 체계적이며 뛰어난 확장성을 가지고 있음.
Kubernetes 사용자가 필요한 기능을 직접 구현할 때 더 편리하게 작업할 수 있도록
기능을 구현해놓았는데 그것이 바로 Cutom Resource임.
Custom Resource가 kubernetes cluster에서 배포되면
Custom Resource Object를 kubectl 명령을 통해서도 사용할 수 있음.
이러한 Custom Resource를 생성하는 방법은 2가지가 있음.
첫 번째 : Custom Resource Definition
두 번째 : API Aggregation
[참고 : Custom Resource의 Resource란?]
Resource라 하면 CPU, Memory등의 자원을 뜻하는 것 같지만
Custom Resource의 Resource는
kubernetes의 각종 Object, Controller를 뜻함
예) Pod, Service, Deployment, Replicaset, ConfigMap 등등
조금 더 자세히 예를 들어서 설명하자면
Pod와 관련된 kubernetes의 기능과 Pod 정의(yaml혹은 create와 같은 것)를
Kubernetes Resource라 함.
Custom Resource Definition (CRD)
Custom Resource를 생성하는 가장 쉬운 방법으로 가장 많이 사용하기도 함.
Kubernetes 에서 제공하는 기능으로 Kubernetes Object 종류 중 하나임.
그래서 yaml 형식으로 생성이 가능하고
kubectl get crd 명령으로 crd 목록과 정보를 확인할 수 있음
특징
1. 프로그래밍이 필요 없음.
2. 아래에서 설명할 CRD Controller를 만들때 원하는 언어를 사용할 수 있음.
3. kube-apiserver가 관리함.
4. Kubernetes upgrade와 Bugfix 등이 바로 적용되서 따로 관리를 하지 않아도 됨.
5. Namespace or Cluster 에 적용할것인지 범위를 결정할 수 있음.
CRD를 생성하면?
Custom Resource Definition = 사용자가 원하는 새로운 상태를 선언
Kubernetes에 CRD Object를 생성해보면
그저 kubectl get crd 명령으로 확인해보면 생성한 CRD 정보만 나올뿐
Kubernetes Cluster에 어떠한 변화도 일어나지 않음.
이유는 이름 그대로 CRD는 그저 Definition일 뿐임.
CRD는 Custom Resource를 생성할 때
Custom Resource에 어떠한 data가 포함되어야 하는지,
또는 yaml 파일 옵션을 어떤것이 설정되어야하는지를 결정하는
일종의 환경 선언과 같은 역할만 수행함.
생성한 CRD로 yaml 파일 형식을 생성한 뒤 apply를 하면
cluster에 pod 또는 service Object가 생성되지 않음
그저 custom Resource data만 생성될 뿐임.
예를 들자면
Deployment를 생성하면 먼저 etcd에 Deployment 생성요청 data가 저장되고
kubernetes controller 또는 scheduler 모듈이 이를 탐지 한 후
pod를 생성하는 등 사용자가 원하는 상태를 만들려는 특정 목적을 달성하기 위한 임무를 수행함.
CRD를 생성하면 kubernetes etcd에 CRD Object가 생성되었다고 저장할 뿐
etcd를 바라보고 있는 kubernetes controller 또는 scheduler 모듈이
해당 CRD Object 생성을 탐지한 후 액션을 취하는 과정은 없음.
그렇다면 CRD도 Deployment와 같이 etcd에 CRD data가 생성되면
이를 모니터링 하고 있다가 액션을 취하는 무엇인가가 있어야하는데
그것이 바로 Custom Controller 임.
Custom Controller
Custom Controller = 사용자가 생성한 CRD 상태가 되도록 작업하는 역할.
위에서 설명했듯이 Custom Resource 자체는 그저 data 형식을 설정할 뿐
Custom Resource를 통해서 특정 동작을 실행하기 위해서는
Custom Controller가 있어야함.
Custom Controller는 Custom Resource에 명시된 사용자가 원하는 상태를 만들기 위한 임무를 수행함.
그렇다면 Custom Resource위한 Custom Controller는 어떻게 구현하는지 알아봐야함.
예를 들자면 Deployment, Job, Daemonset 등 현재 kubernetes 에서 제공하는 controller 또한
kube-controller라는 모듈이 있기 때문에
Deployment, Job과 같은 Core Resource Definition이 생성되면
kube-controller가 이를 탐지하는 controller이기 때문에 해당 Resource 의 create, delete, update 를 확인하고
이에 맞게 pod를 생성하는 등 object를 생성 역할을 수행함.
Custom Resource 도 마친가지로
Custom Resource 를 탐지하고 임무를 수행하는
Custom Controller를 생성해줘야 함.
[참고 그림]
그림 설명 : 01. Kubernetes 이론 글의 ReplicaSet 생성되는 과정 정리 참고.
[Core Resource란?]
kubernetes에서 기본적으로 제공하고 있는 자원을 뜻함.
해당 Core Resource에 해당하는 controller는
kubernetes cluster를 구성하고 있는 kube-controller 모듈임.
Custom Controller 구현하는 방법
Controller를 직접 구현하려면 Kubernetes를 구성하는 모듈(apiserver, controller, scheduler와 같은)의
역할도 파악하고 있어야하고 저수준의 kubernetes API도 알아야해서 쉽지 않음.
하지만 다양한 개발도구가 제공되고 있어서 그나마 쉽게 Custom Controller를 구현할 수 있음.
[ Custom Controller 개발도구 종류 ]
각 개발도구의 장단점 비교 참고 :
https://tiewei.github.io/posts/kubebuilder-vs-operator-sdk
API Aggregation
kubectl을 통해 명령을 내리면
가장먼저 kube-apiserver 모듈로 전달되어 동작하게되는데
API Aggregation을 사용하게 되면 사용자가 원하는 기능을 수행하는
apiserver 구현해서 추가할 수 있음.
그렇다면 기존의 kube-apiserver가 여러대가 되는것인가?
그건 또 아님.
기존의 kube-apiserver에 API Registration 기능이 제공되고 있어서
해당 기능을 사용하면 사용자가 구현한 apiserver를 kube-apiserver에 등록하는 방식으로
kube-apiserver를 확장하는 개념으로 사용됨.
하지만 별도의 apiserver를 구축하는 작업은 매우 어렵고 관리도 힘듬.
CRD방식 보다 더 세밀하게 커스텀 리소스를 구현할 수 있지만
CRD 방식도 많이 update되면서 API Aggregation 의 디테일한 점을 따라잡아서
현재는 API Aggregation 방식은 거의 사용되고 있지 않다고 함.
실제로 CRD관련 예제는 많지만
API Aggregation 관련 예제는 자료가 거의 없음.
특징
1. GO언어로 개발해서 바이너리와 이미지를 만들어야함.
2. 주기적으로 업스트림의 소스를 가져와서 변경사항을 반영하고
새로운 kube-apiserver 바이너리를 만드는 작업을 직접 진행해야함
3. CRD에 비해서 더 정교하게 API를 만들 수 있으나 어려움.
4. API 동작 제어 강화
제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!
참고
[custom resource]
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
https://arisu1000.tistory.com/27862
https://blog.naver.com/alice_k106/221579974362
https://getoutsidedoor.com/2019/07/27/kubernetes-crd%EC%99%80-operator/
https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/