이 글에서 Kubernetes 는 이하 K8s 라고 통칭한다.
Operator, CRD를 알려면 좀 많이 알아야하는데
kube-apiserver
- K8s API 를 노출하는 K8s Control-Plane Component이지만, 실제로는 정말 단순한 API 서버
- API 서버는 K8s Control-Plane의 프론트엔드 역할
- K8s API서버의 주요 구현이며, 수평으로 확장되도록 설계되었음(여러개의 kube-apiserver 인스턴스를 실행하고, 인스턴스간 트래픽을 균형있게 조절할수 있다)
K8s API
- K8s Control-Plane의 핵심이 K8s API
- API 서버는 최종사용자, 클러스터의 다른부분, 외부 컴포넌트가 서로 통신할수 있도록 하는 HTTP API 를 제공한다.
- K8s API 를 사용하면 K8s API Object(e.g: Pod, Namespace, Configmap, Event) 를 쿼리하고, 조작할수있다.
- kubectl CLI, API를 사용하는 kubeadm, REST 호출을 사용하는 API를 사용하여 접근할수 있다.
LINK : https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/
Resource
- K8s API 에서 특정 종류의 K8s API Object 모음을 저장하는 엔드포인트 (e.g. 빌트인 Pod 리소스에는 Pod Object 모음이 포함되어있다)
Custom Resource(CR)
- K8s API 의 Extension
- 기본 쿠버네티스 설치에서 반드시 사용할수 있는게 아니며, 특정한 수정작업이 필요함
- 동적 등록을 통해서 실행중인 Cluster에서 CR을 띄우거나, 지울수 있다.
- CR이 설치되면, 사용자는 Pod와 같은 빌트인 리소스와 마찬가지로, kubectl 을 사용하여 해당 Object를 생성하고 접근할수 있다.
- 일반적으로 API aggregate Layer 에서 API 를 추생성한 API를 독립적으로 유지할것인지 고려하는것같다.
LINK : https://kubernetes.io/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
LINK : https://kubernetes.io/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Custom Controller(CC)
- 자체적으로 CR을 사용하면 구조화된 데이터를 저장하여 사용할수 있다.
- 이때 CR을 CC와 결합하면, CR이 선언적(Declarative) API를 제공하게 된다.
- Cluster Lifecycle에 관계없이, 실행중인 Cluster에 CC를 배포하고 업데이트할수 있다.
⇒ Custom Resource + Custom Controller 형태로 사용한다
Configmap vs Custom Resource(CR)
Configmap을 사용할때
- 잘 문서화된 기존 구성파일이 있는경우
- 전체 구성파일을 Configmap 하나의 키에 넣고싶은경우
- K8s API가 아닌, 파드의 환경변수 또는 파드의 파일을 통해 사용하는경우
CR을 사용할때
- K8s CLI 를 사용해서 새로운 리소스를 만들려고 할때
- Object 를 CRUD 하고 싶을때
- .spec, .status, .metadata 같은 K8s API 규칙을 사용하고싶을때
CR을 추가하는 두가지 방법 : CRD, API Aggregation
- CRD(Custom Resource Definition)을 사용해서 프로그래밍 없이 만드는 방법이 존재
- API Aggregation은 프로그래밍이 필요하지만, 데이터 저장, API 버전간 변환 같은 API 동작을 강력하게 제어할수 있음
(Aggregate API는 기본 API 서버 뒤에있는 하위 API 서버이며, 프록시 역할을 한다. 이 배치를 API Aggregation 이라고한다)
Custom Resource Definition (CRD)
- CRD Object를 정의하면, 지정한 이름과 스키마를 사용하여 Custom Resource가 만들어진다.
- K8s API는 CR의 스토리지를 제공하고 처리한다.
- CR을 처리하기위해 자신의 API 서버를 작성할수는 없지만, 구현상의 제약때문에 API Aggregation 방식보다 유연성이 떠렁짐
API Aggregation (AA)
- K8s API의 Resource에는 Rest Request를 처리하고, Object의 Persistent Stroage를 관리하는 코드가 필요함
- 주요 K8s API서버는 빌트인 리소스(e.g : Pod, Service) 를 처리, CRD를 통해 CR을 처리함
Operator
- CRD를 사용하여 Application, Component를 관리하는 K8s의 Software Extension 이다
- 기본적인 설계목적은 자동화. K8s의 Core를 통해서 많은 Built-in 자동화 기능을 사용함
- K8s Operator Pattern 개념을 통해서 코드를 수정하지않고, Controller를 하나 이상의 CR에 연결하여 Cluster의 동작을 확장할수 있음
- Operator는 CR의 Controller역할을 하는 K8s API’s Client 역할임
'Cloud > Kubernetes' 카테고리의 다른 글
Deployment HPA: replicas 우선순위 (0) | 2024.01.20 |
---|---|
kubectl로 GKE, EKS 접근하기 (0) | 2023.10.26 |
Minikube 구축하기 (0) | 2023.03.25 |
Kubernetes Cluster IP no such host : kube-state-metrics 설치 (0) | 2023.03.24 |
kubeadm init 에러 detected "cgroupfs" as the Docker cgroup driver (0) | 2023.03.19 |