(Kubernetes) - Custom Resource

🍳머리말

k8s docs 복붙글입니다. CR(Custom Resource)에 대해 설명합니다.

---

📕 Custom resource

📔 정의

k8s API의 extension입니다. Resource는 k8s API에서 특정 종류의 API object 모음을 저장하는 endpoint입니다. 예로는 built in pod resource에는 pod object모음이 포함되어 있습니다.

확장이므로 기본 k8s 설치시 반드시 사용할 수 있는 것은 아닙니다. 하지만 많은 기능에서 custom resource는 사용해 구축되어 k8s를 더욱 module화합니다.

동적으로 api를 등록해 실행 중인 cluster에서 custom resource가 나타나거나 사라질 수 있으며 cluster 관리자는 cluster 자체와 독립적으로 custom resource를 update할 수 있습니다. custom resource가 설치되면 사용자는 pod와 같은 built in resource와 마찬가지로 kubectl명령어를 사용해 해당 object를 생성하고 접근할 수 있습니다.

📔 추가방법

k8s는 cluster에 custom resource를 추가하는 두 가지 방법을 제공합니다.

• CRD는 간단하며 programming 없이 만들 수 있습니다.
• API aggregation에는 programming이 필요하지만, data 저장 방법 및 API version 간 변환과 같은 API 동작을 보다 강력하게 제어할 수 있다.

쿠버네티스는 다양한 사용자의 요구를 충족시키기 위해 이 두 가지 옵션을 제공하므로 사용의 용이성이나 유연성이 저하되지 않습니다.

aggregate API는 기본 API 서버 뒤에 있는 하위 API server이며 proxy 역할을 합니다. 이 배치를 API aggregation(AA)이라고 합니다. 사용자에게는 쿠버네티스 API가 확장된 것으로 나타납니다.

CRD를 사용하면 다른 API server를 추가하지 않고도 새로운 type의 resource를 생성할 수 있습니다. CRD를 사용하기 위해 API aggregation을 이해할 필요는 없습니다.

설치 방법에 관계없이 새 resource는 custom resource라고 하며 built in k8s resource(pod 등)와 구별됩니다.

📔 CRD

CRD(CustomResourceDefinition) API resource를 사용하면 custom resource를 정의할 수 있습니다. CRD object를 정의하면 지정한 이름과 schema를 사용해 새 CR이 만들어집니다. k8s API는 CR의 storage를 제공하고 저리합니다. CRD object의 이름은 유효한 DNS subdomain이름이어야 합니다.

따라서 CR를 처리하기 위해 자신의 API server를 작성할 수는 없지만 구현의 일반적 특성으로 인해 API server aggregation보다 유연성이 떨어집니다.

새 custom resource를 등록하고 새 resource type의 instance에 대해 작업하고 controller를 사용해 event를 처리하는 방식의 예제를 확인 바랍니다.

📔 API server aggregation

일반적으로 k8s API의 각 resource에는 REST요청을 처리하고 object의 persistent storage를 관리하는 code가 필요합니다. 주요 k8s API server는 pod 및 service와 같은 built in resource를 처리하고 일반적으로 CRD를 통해 CR를 처리할 수 있습니다. Aggregation layer를 사용하면 자체 독립형 API server를 작성하고 배포해 CR에 대한 특수한 구현을 제공할 수 있습니다. 기본 API server는 처리하는 CR에 대한 요청을 사용자에게 위임해 모든 client가 사용할 수 있게 합니다.

📔 CR 추가 방법 선택

CRD는 사용하기 쉽고, Aggregate API는 유연합니다. 자신의 요구에 가장 잘 맞는 방법을 선택해 봅시다. 일반적으로 CRD는 다음과 같은 경우에 적합합니다. 

• 사용 field가 적을 때
• 회사 내 또는 소규모 opensource project의 일부인(상용 제품이 아닌)resource를 사용할 때

📑 사용 편의성 비교

CRD	aggregate API
프로그래밍이 필요하지 않다. 사용자는 CRD 컨트롤러에 대한 모든 언어를 선택할 수 있다.	프로그래밍하고 바이너리와 이미지를 빌드해야 한다.
실행할 추가 서비스가 없다. CR은 API 서버에서 처리한다.	추가 서비스를 생성하면 실패할 수 있다.
CRD가 생성된 후에는 지속적인 지원이 없다. 모든 버그 픽스는 일반적인 쿠버네티스 마스터 업그레이드의 일부로 선택된다.	업스트림에서 버그 픽스를 주기적으로 선택하고 애그리게이트 API 서버를 다시 빌드하고 업데이트해야 할 수 있다.
여러 버전의 API를 처리할 필요가 없다. 예를 들어, 이 리소스에 대한 클라이언트를 제어할 때 API와 동기화하여 업그레이드할 수 있다.	인터넷에 공유할 익스텐션을 개발할 때와 같이 여러 버전의 API를 처리해야 한다

📔 k8s에 CR을 추가해야하나?

새로운 API를 생성할 때 k8s cluster API와 생성한 API를 aggregate할 것인지 생성한 API를 독립적으로 유지할 것인지 고려해봅니다.

API 애그리게이트를 고려할 경우	독립 API를 고려할 경우
API가 declarative이다.	API가 declarative 모델에 맞지 않다.
kubectl을 사용하여 새로운 타입을 읽고 쓸 수 있기를 원한다.	kubectl 지원이 필요하지 않다.
쿠버네티스 UI(예: 대시보드)에서 빌트인 타입과 함께 새로운 타입을 보길 원한다.	쿠버네티스 UI 지원이 필요하지 않다.
새로운 API를 개발 중이다.	생성한 API를 제공하는 프로그램이 이미 있고 잘 작동하고 있다.
API 그룹 및 네임스페이스와 같은 REST 리소스 경로에 적용하는 쿠버네티스의 형식 제한을 기꺼이 수용한다. (API 개요를 참고한다.)	이미 정의된 REST API와 호환되도록 특정 REST 경로가 있어야 한다.
자체 리소스는 자연스럽게 클러스터 또는 클러스터의 네임스페이스로 범위가 지정된다.	클러스터 또는 네임스페이스 범위의 리소스는 적합하지 않다. 특정 리소스 경로를 제어해야 한다.
쿠버네티스 API 지원 기능을 재사용하려고 한다.	이러한 기능이 필요하지 않다

---

📕 Declarative Api

📔 특징

선언적 APi에는 다음의 특성이 있습니다.

API는 상대적으로 수가 적고, 작은 object(resource)로 구성됩니다.

object는 application 또는 infra의 구성을 정의합니다.

object는 비교적 드물게 update됩니다.

사람이 종종 object를 읽고 쓸 필요가 있습니다.

object의 주요 작업은 CRUD-y(create, read, update, delete)입니다.

object간 transaction은 필요하지 않습니다. API는 정확한 상태가 아닌 desired state를 나타냅니다.

 

declarative API는 선언적이지 않습니다.  k8s declarative API는 책임의 분리를 강제합니다. 사용자는 resource의 의도한 상태를 선언합니다. k8s controller는 k8s object의 현재 상태가 선언한 의도 상태에 동기화 되도록 합니다. 이는 server에 무엇을 해야할지 지시하는 declarative API와는 대조됩니다. 다음의 특성이 이를 뒷받침해줍니다.

• 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다.
• 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다.
• RPC(원격 프로시저 호출)에 대해 얘기한다.
• 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트.
• 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다.
• 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다.
• 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다.
• API는 오브젝트로 쉽게 모델링되지 않는다.
• 작업 ID 또는 작업 오브젝트로 보류 중인 작업을 나타내도록 선택했다.

---

📕 Custom controller

📔 정의

custom resource를 reconciler loop를 통해 k8s로 하여금 어떤 것인지 알려주는 기능을 합니다.

📔 배경

자체적으로 custom resource를 사용하면 구조화된 data를 저장하고 검색할 수 있습니다. custom resource를 custom controller와 결합하면 custom resource가 진정한 declarative API를 제공하게 됩니다.

📔 특징

cluster lifecycle과 관계없이 실행 중인 cluster에 custom controller를 배포하고 update할 수 있습니다. custom controller는 모든 종류의 resource와 함께 작동할 수 있지만 custom resource와 결합할 때 특히 효과적입니다. operator pattern은 사용자 정의 resource와 custom controller를 결합합니다. custom controller를 사용해 특정 application에 대한 domain 지식을 k8s API의 extension으로 encoding할 수 있습니다.

---

📕참조

https://kubernetes.io/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/

커스텀 리소스