커스텀 리소스
커스텀 리소스 (Custom Resources)
쿠버네티스를 운영하다 보면, 기본으로 제공되는 리소스만으로는 부족할 때가 있어요. 여러분만의 데이터 모델이나 도메인 로직이 필요할 때 쓰는 게 바로 커스텀 리소스(Custom Resources) 입니다. 이 페이지에서는 언제 커스텀 리소스를 추가해야 하는지, 언제 독립된 서비스를 쓰는 게 나은지, 그리고 추가 방법 두 가지를 설명해요.
커스텀 리소스는 쿠버네티스 API의 확장이에요. 이 페이지는 언제 클러스터에 커스텀 리소스를 추가할지, 언제 독립형(standalone) 서비스를 쓸지를 다루고, 커스텀 리소스 추가의 두 가지 방식과 그 사이에서 고르는 법을 설명합니다.
커스텀 리소스 (Custom resources)
리소스(resource)는 쿠버네티스 API에서 특정 종류의 API 객체 컬렉션을 저장하는 엔드포인트입니다. 예를 들어 기본 제공되는 pods 리소스는 Pod 객체의 컬렉션을 담고 있어요.
커스텀 리소스는 기본 쿠버네티스 설치에는 없을 수 있는 쿠버네티스 API의 확장입니다. 특정 쿠버네티스 설치의 맞춤화(customization)를 나타내요. 다만 요즘은 많은 핵심 쿠버네티스 기능이 커스텀 리소스로 만들어져, 쿠버네티스가 더 모듈화되고 있습니다.
커스텀 리소스는 동적 등록(dynamic registration)을 통해 실행 중인 클러스터에서 나타났다 사라질 수 있고, 클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트할 수 있어요. 커스텀 리소스가 설치되면 사용자는 Pod 같은 기본 리소스처럼 kubectl로 그 객체를 만들고 접근할 수 있습니다.
커스텀 컨트롤러 (Custom controllers)
커스텀 리소스만으로는 구조화된 데이터를 저장·검색할 수 있습니다. 커스텀 리소스를 커스텀 컨트롤러와 결합하면, 커스텀 리소스가 진정한 선언적(declarative) API를 제공하게 돼요.
쿠버네티스 선언적 API는 책임을 분리합니다. 원하는 상태(desired state)를 선언하면, 쿠버네티스 컨트롤러가 쿠버네티스 객체의 현재 상태를 선언한 원하는 상태와 동기화해요. 이는 서버에 "무엇을 하라"고 지시하는 명령형(imperative) API와 대조적입니다.
커스텀 컨트롤러는 클러스터의 수명주기와 독립적으로, 실행 중인 클러스터에 배포·업데이트할 수 있어요. 커스텀 컨트롤러는 어떤 종류의 리소스와도 작동하지만, 커스텀 리소스와 결합할 때 특히 효과적입니다. Operator 패턴은 커스텀 리소스와 커스텀 컨트롤러를 결합한 것이에요. 커스텀 컨트롤러를 사용하면 특정 애플리케이션에 대한 도메인 지식을 쿠버네티스 API의 확장으로 인코딩할 수 있습니다.
커스텀 리소스를 클러스터에 추가해야 할까?
새 API를 만들 때, 여러분의 API를 쿠버네티스 클러스터 API에 통합(aggregate)할지, 아니면 독립형으로 둘지 고민해야 해요.
| API 통합(aggregation)을 고려할 때 | 독립형 API를 선호할 때 |
|---|---|
| 여러분의 API가 선언적(Declarative)일 때 | API가 선언적 모델에 맞지 않을 때 |
새 타입을 kubectl로 읽고 쓸 수 있게 하고 싶을 때 |
kubectl 지원이 필요 없을 때 |
| 새 타입을 대시보드 같은 쿠버네티스 UI에서 기본 타입과 함께 보고 싶을 때 | 쿠버네티스 UI 지원이 필요 없을 때 |
| 새 API를 개발 중일 때 | 여러분의 API를 잘 서빙하는 프로그램이 이미 있을 때 |
| 쿠버네티스가 REST 리소스 경로(API 그룹, 네임스페이스)에 두는 형식 제약을 수용할 수 있을 때 | 특정 REST 경로가 필요할 때 |
구체적인 조건은 위쪽 표의 각 상황을 참고하세요. (참고: 표의 마지막 행은 "API 통합"의 경우 형식 제약을 수용할 수 있을 때, "독립형"의 경우 특정 REST 경로가 필요할 때로 갈라집니다. 전체 판단 기준은 원문 표를 확인 필요합니다.)