CRD (r1)

CRD는 쿠버네티스 API 서버에 새로운 API 오브젝트 타입을 정의하기 위한 리소스이다. CRD 자체도 하나의 쿠버네티스 리소스로, CustomResourceDefinition이라는 API 그룹에 속한다. 기본 구조는 크게 메타데이터, 스펙, 상태로 나뉘며, YAML 또는 JSON 매니페스트로 정의된다.

CRD 매니페스트의 핵심 필드는 다음과 같다.

spec 영역은 새로 생성할 커스텀 리소스의 구조를 정의하는 가장 중요한 부분이다. 주요 하위 필드로는 group, versions, scope, names가 있다. group은 새 API가 속할 API 그룹을 지정한다(예: example.com). versions는 지원할 API 버전 목록과 각 버전의 스키마를 정의한다. scope는 해당 리소스가 클러스터 전체(Cluster)에 적용되는지 특정 네임스페이스(Namespaced)에만 적용되는지를 결정한다. names 필드에는 사용할 리소스의 복수형(plural), 단수형(singular), 종류(kind), 짧은 이름(shortNames) 등을 정의한다.

이 구조를 통해 쿠버네티스는 CRD를 등록받고, 지정된 API 엔드포인트를 생성한다. 이후 사용자는 이 새 리소스 타입의 인스턴스를 생성하고 관리할 수 있다. CRD의 구조는 OpenAPI v3 스키마를 사용하여 커스텀 리소스의 데이터 형식과 유효성 검사 규칙을 상세히 정의할 수 있도록 진화했다.

쿠버네티스는 Pod, Service, Deployment와 같은 기본 제공(built-in) 리소스들을 관리하기 위한 API를 제공한다. 이러한 빌트인 리소스는 쿠버네티스 코어의 일부로, 클러스터의 기본적인 워크로드와 네트워킹, 스토리지 등을 정의하고 제어하는 데 사용된다. 반면, 커스텀 리소스(Custom Resource)는 사용자가 쿠버네티스 API를 자신의 애플리케이션 도메인에 맞게 확장하여 정의한 새로운 리소스 종류이다. CRD(Custom Resource Definition)는 바로 이 커스텀 리소스의 스키마와 생명주기를 정의하는 객체이다.

두 리소스 유형의 가장 큰 차이는 관리 주체와 목적에 있다. 빌트인 리소스는 쿠버네티스 프로젝트 자체에 의해 개발되고 유지되며, 모든 쿠버네티스 클러스터에서 표준적으로 사용 가능하다. 이에 비해 커스텀 리소스는 특정 조직이나 팀의 필요에 따라 생성된다. 예를 들어, "Database"라는 커스텀 리소스를 정의하여 데이터베이스 인스턴스의 생성, 백업, 모니터링을 선언적으로 관리할 수 있다. 커스텀 리소스는 kubectl 명령어로 조작할 수 있다는 점에서 빌트인 리소스와 동일한 사용자 경험을 제공한다.

기술적 관점에서, 빌트인 리소스의 로직은 쿠버네티스 컨트롤 플레인 컴포넌트(예: kube-apiserver, kube-controller-manager)에 하드코딩되어 있다. 반면, 커스텀 리소스는 CRD를 통해 API 서버에 등록만 될 뿐, 그 자체로는 아무런 동작 로직을 포함하지 않는다. 커스텀 리소스가 실제로 의미 있는 동작을 하기 위해서는 이를 감시하고 비즈니스 로직을 수행하는 별도의 컨트롤러(Controller)가 필요하다. 이 패턴을 오퍼레이터 패턴이라고 부른다.

다음 표는 두 리소스 유형의 주요 차이점을 요약한다.

결론적으로, 빌트인 리소스는 쿠버네티스의 핵심 기능을 구성하는 반면, 커스텀 리소스는 이 핵심 플랫폼 위에 사용자 자신의 추상화와 자동화를 구축할 수 있게 해주는 확장 메커니즘이다.

CRD에서 정의하는 사용자 정의 객체의 상태는 크게 두 가지 주요 부분, 즉 명세(Spec)와 상태(Status)로 구성된다. 이 구분은 쿠버네티스의 기본 리소스 설계 철학을 반영한다.

Spec은 사용자가 원하는 객체의 *바람직한 상태(Desired State)*를 기술한다. 예를 들어, "데이터베이스"라는 CRD를 생성할 때, 사용자는 Spec 필드에 데이터베이스 엔진 타입, 스토리지 크기, 복제본 수 등을 정의한다. 이는 사용자가 시스템에 요구하는 선언적 구성이다. 반면, Status는 시스템에 의해 보고되는 객체의 *실제 상태(Actual State)*를 나타낸다. 동일한 데이터베이스 객체의 Status에는 현재 준비된 복제본 수, 연결 가능한 엔드포인트, 마지막 백업 시간 등이 기록된다. Status 필드는 일반적으로 관련 컨트롤러에 의해 주기적으로 갱신된다.

이 두 필드의 분리는 쿠버네티스의 선언적 시스템 관리 모델의 핵심이다. 사용자는 Spec을 통해 의도를 선언하면, 컨트롤러가 이를 감시하고 현재 상태(Status)를 바람직한 상태(Spec)에 일치시키기 위해 지속적으로 작업한다. Status는 작업의 진행 상황이나 결과를 사용자에게 피드백하는 창구 역할을 한다. 따라서 CRD를 설계할 때는 어떤 속성이 사용자의 의도(Spec)이고, 어떤 속성이 시스템의 관찰 결과(Status)인지를 명확히 구분하여 정의하는 것이 중요하다.

스키마는 CRD가 정의하는 커스텀 리소스의 구조와 유효성을 규정하는 청사진이다. 이 스키마는 OpenAPI v3.0 사양을 따르는 JSON 또는 YAML 형식으로 정의되며, 쿠버네티스 API 서버가 리소스 생성 및 수정 요청을 검증하는 데 사용하는 규칙을 제공한다. 스키마 정의는 spec.versions[*].schema.openAPIV3Schema 필드에 위치한다.

스키마는 리소스의 Spec과 Status 필드에 포함될 수 있는 모든 속성의 데이터 타입, 형식, 제약 조건, 기본값, 설명을 명시한다. 주요 데이터 타입으로는 string, integer, boolean, array, object가 사용되며, required 목록을 통해 필수 필드를 지정할 수 있다. 또한 minimum, maximum, pattern, enum과 같은 검증 규칙을 적용하여 유효하지 않은 데이터가 쿠버네티스 etcd에 저장되는 것을 방지한다[2]([-a-z0-9]*[a-z0-9])?$'`는 DNS 서브도메인 이름 규칙을 적용함].

스키마 정의의 예시는 다음과 같다.

정의된 스키마는 kubectl 명령어와의 통합에도 기여한다. kubectl explain 명령어를 통해 리소스 필드에 대한 문서를 조회할 수 있으며, kubectl create나 kubectl apply 실행 시 대화형 유효성 검증을 제공한다. 이는 사용자가 매니페스트를 작성할 때 실수를 줄이고, API의 안정성과 사용성을 크게 향상시킨다.

CRD를 등록하기 위해서는 쿠버네티스가 이해할 수 있는 형식으로 정의를 작성해야 한다. 이는 일반적으로 YAML 형식의 매니페스트 파일을 통해 이루어진다. 이 파일은 CRD의 API 그룹, 버전, 종류(Kind), 그리고 리소스의 구조를 기술하는 스키마를 포함한다.

기본적인 CRD 매니페스트는 다음과 같은 주요 필드로 구성된다.

• apiVersion: apiextensions.k8s.io/v1을 사용한다.

• kind: 리소스 종류로 CustomResourceDefinition을 명시한다.

• metadata: CRD 자체의 메타데이터로, 주로 name을 정의한다. 이름은 <plural>.<group> 형식을 따른다[3].

• spec: CRD의 사양을 정의하는 핵심 영역이다.

• group: CRD가 속할 API 그룹을 지정한다 (예: example.com).

• versions: 지원할 API 버전 목록을 배열로 정의한다. 각 버전은 name, served, storage 필드와 스키마를 포함한다.

• scope: 리소스의 스코프를 지정하며, Namespaced 또는 Cluster 중 하나를 선택한다.

• names: 리소스의 이름 관련 정보를 정의한다.

• plural: API 경로에서 사용되는 복수형 이름 (예: databases).

• singular: CLI 등에서 사용되는 단수형 이름 (예: database).

• kind: 매니페스트 파일에서 사용할 종류 (예: Database).

• shortNames: 짧은 축약형 별칭 리스트 (예: ["db"]).

스키마 정의는 spec.versions[*].schema.openAPIV3Schema 경로 하위에 위치한다. 여기서는 사용자가 생성할 커스텀 리소스 객체의 필드, 데이터 타입, 제약 조건, 기본값 등을 OpenAPI v3 규격에 맞게 상세히 기술한다. 예를 들어, spec 필드 아래에 size, image와 같은 애플리케이션 특화 필드를 정의하고, status 필드 아래에 phase, conditions와 같은 상태 필드를 정의할 수 있다. 스키마 정의는 데이터의 유효성 검증과 쿠버네티스 API 서버가 해당 리소스를 이해하는 데 필수적이다.

CRD를 쿠버네티스 클러스터에 등록하는 가장 기본적이고 직접적인 방법은 kubectl 명령줄 도구를 사용하는 것이다. 이 과정은 CRD의 정의가 포함된 YAML 매니페스트 파일을 클러스터에 적용하는 것으로 이루어진다. 일반적으로 kubectl apply 명령어를 사용하며, 이는 선언적 구성 관리를 지원하여 리소스의 생성과 업데이트를 모두 처리한다.

배포 절차는 다음과 같은 단계로 진행된다. 먼저, CustomResourceDefinition API 리소스 종류를 정의한 YAML 파일을 준비한다. 이후 터미널에서 해당 파일이 위치한 디렉토리로 이동한 후, kubectl apply -f <파일명>.yaml 명령을 실행한다. 성공적으로 배포되면, kubectl get crd 명령을 통해 등록된 CRD 목록을 확인할 수 있다. 새롭게 정의된 커스텀 리소스는 이제 빌트인 리소스와 마찬가지로 kubectl get <리소스 복수형 이름>과 같은 명령으로 조작이 가능해진다.

kubectl을 통한 배포 시 주의할 점은 스키마 검증이다. CRD 매니페스트에 OpenAPI v3 스키마가 정의되어 있으면, kubectl이나 API 서버가 해당 스키마를 사용하여 사용자가 생성하거나 수정하는 커스텀 리소스 객체의 필드 유효성을 검사한다. 잘못된 필드 값이 포함된 매니페스트를 적용하려고 하면 유효성 검사 오류가 발생하여 배포가 거부된다. 이는 데이터의 무결성을 보장하는 중요한 기능이다.

배포 후 CRD의 수정 또는 삭제도 kubectl로 관리한다. 정의를 업데이트할 때는 동일한 YAML 파일을 수정한 후 다시 kubectl apply 명령을 실행한다. CRD를 클러스터에서 완전히 제거하려면 kubectl delete -f <파일명>.yaml 명령을 사용한다. 단, CRD를 삭제하면 해당 CRD를 통해 생성된 모든 커스텀 리소스 객체도 함께 삭제된다는 점에 유의해야 한다.

CRD는 단독으로는 단순한 데이터 스키마에 불과합니다. CRD가 실제 동작하는 리소스로 기능하려면 이를 관리하는 컨트롤러가 필요하며, 이 둘을 결합한 설계 철학이 오퍼레이터 패턴입니다. 오퍼레이터 패턴은 쿠버네티스의 확장 메커니즘을 활용하여 도메인 지식이나 애플리케이션별 운영 로직을 자동화하는 소프트웨어를 구축하는 방법입니다.

오퍼레이터는 기본적으로 사용자 정의 컨트롤러입니다. 이 컨트롤러는 쿠버네티스 API 서버를 감시하며, 특정 CRD로 생성된 커스텀 리소스 객체의 생성, 변경, 삭제 이벤트를 지속적으로 관찰합니다. 이벤트를 감지하면 컨트롤러는 사전에 정의된 비즈니스 로직에 따라 실제 상태(예: 파드 생성, 외부 서비스 구성 변경)를 조정하여 사용자가 CR에 명시한 원하는 상태(Spec)와 실제 상태(Status)를 일치시키려고 시도합니다. 이 패턴은 복잡한 스테이트풀 애플리케이션의 배포, 구성, 백업, 업그레이드 등을 자동화하는 데 널리 사용됩니다.

오퍼레이터 패턴의 구현은 일반적으로 다음 구성 요소를 포함합니다.

이 패턴을 통해 운영팀은 데이터베이스, 메시지 큐, 모니터링 시스템 같은 복잡한 소프트웨어의 운영 지식을 코드화하여 패키지로 배포할 수 있습니다. 결과적으로 쿠버네티스는 단순한 컨테이너 오케스트레이터를 넘어, 어떠한 종류의 서비스도 관리할 수 있는 진정한 클라우드 운영 체제로 진화하게 되었습니다.

컨트롤러는 CRD로 정의된 사용자 정의 리소스의 실제 생명주기를 관리하는 핵심 구성 요소이다. 컨트롤러는 지속적으로 쿠버네티스 API 서버를 감시하여 특정 CRD 인스턴스의 생성, 수정, 삭제 이벤트를 확인한다. 감지된 이벤트와 리소스의 spec 필드에 명시된 사용자의 의도(Desired State)를 바탕으로, 컨트롤러는 필요한 조치를 취해 실제 상태(Actual State)를 의도한 상태에 일치시키기 위해 노력한다. 이 과정은 리컨실레이션 루프라고 불리는 지속적인 조정 활동이다.

컨트롤러의 구체적인 역할은 애플리케이션의 도메인 로직에 따라 다양하다. 예를 들어, Database라는 CRD를 위한 컨트롤러는 사용자가 Database 리소스를 생성하면, 그 spec에 정의된 엔진 타입과 스토리지 크기에 맞춰 실제 파드, 서비스, 퍼시스턴트볼륨클레임 등을 생성할 수 있다. 또한 리소스의 status 필드를 실시간으로 업데이트하여 데이터베이스의 준비 상태나 연결 엔드포인트 같은 정보를 사용자에게 제공한다.

컨트롤러는 CRD 자체가 단순한 데이터 스키마에 불과하다는 점을 보완한다. 컨트롤러가 없으면 CRD로 생성한 리소스는 선언적 데이터일 뿐, 이를 해석하고 실행할 로직이 존재하지 않는다. 따라서 컨트롤러는 CRD에 생명을 불어넣고, 쿠버네티스 클러스터를 사용자 정의 도메인 지식에 맞게 확장하는 실제 실행 엔진의 역할을 담당한다. 이 패턴은 오퍼레이터 패턴의 구현체로 이해된다.

컨트롤러의 구현은 일반적으로 클라이언트-고 라이브러리와 같은 쿠버네티스 클라이언트 라이브러리를 사용하여 작성된다. 최근에는 쿠버빌더나 오퍼레이터 SDK와 같은 프레임워크를 사용해 컨트롤러의 기본 골격과 리컨실레이션 루프를 자동으로 생성하는 것이 일반적이다.

CRD를 통한 애플리케이션 확장은 쿠버네티스의 핵심 기능을 사용자 정의 리소스로 래핑하거나 복잡한 애플리케이션의 상태를 선언적으로 관리하기 위해 주로 사용된다. 이를 통해 개발자는 파드, 디플로이먼트, 서비스와 같은 빌트인 오브젝트만으로는 표현하기 어려운 도메인 특화된 개념을 쿠버네티스 API에 자연스럽게 통합할 수 있다. 예를 들어, "Database", "BackupSchedule", "IngressRoute"와 같은 사용자 정의 리소스를 생성하여 애플리케이션의 복잡한 구성과 생명주기를 단순화한다.

구체적인 활용 패턴으로는, 첫째, 외부 시스템이나 서비스를 위한 쿠버네티스 네이티브 인터페이스를 제공하는 것이다. 클라우드 공급자의 관리형 서비스나 클러스터 외부에 존재하는 레거시 시스템을 CRD로 추상화하면, 사용자는 익숙한 kubectl 명령어를 통해 해당 리소스를 조작할 수 있다. 둘째, 복합 애플리케이션의 템플릿화가 있다. 여러 개의 빌트인 리소스로 구성된 애플리케이션 스택(예: 웹 서버, 캐시, 데이터베이스)을 하나의 사용자 정의 리소스(예: "WebApp")로 정의하면, 배포와 관리를 단일 오브젝트로 단순화할 수 있다.

다음 표는 애플리케이션 확장을 위한 일반적인 CRD 사례를 보여준다.

이러한 확장은 궁극적으로 오퍼레이터 패턴과 결합되어 그 위력을 발휘한다. CRD가 "무엇"을 원하는지 선언한다면, 연동된 컨트롤러는 해당 선언된 상태를 실제 클러스터 내외부에서 구현하기 위해 "어떻게" 동작할지 책임진다. 결과적으로 개발자와 운영자는 애플리케이션의 비즈니스 로직에 더 집중할 수 있으며, 반복적이고 오류가 발생하기 쉬운 운영 작업을 자동화된 시스템에 위임할 수 있게 된다.

도메인 특화 오퍼레이터는 CRD와 컨트롤러를 결합하여 특정 애플리케이션, 미들웨어, 또는 인프라 구성 요소의 수명 주기를 관리하는 소프트웨어 확장이다. 이 오퍼레이터는 도메인 지식을 쿠버네티스 API에 인코딩하여 복잡한 상태 저장 애플리케이션의 설치, 구성, 업그레이드, 백업, 복구와 같은 작업을 자동화한다. 예를 들어, 데이터베이스, 메시지 큐, 모니터링 시스템과 같은 소프트웨어를 쿠버네티스 상에서 선언적 방식으로 운영할 수 있게 해준다.

이러한 오퍼레이터는 사용자가 정의한 CRD 인스턴스(예: PostgresCluster, KafkaTopic)의 상태(Spec)를 지속적으로 관찰하고, 의도한 상태를 실제 상태와 일치시키기 위해 필요한 조치를 실행한다. 도메인 특화 오퍼레이터의 핵심 가치는 운영 팀의 수동 개입을 줄이고, 복제, 장애 조치, 설정 변경과 같은 복잡한 운영 작업을 표준화하고 자동화하는 데 있다.

도메인 특화 오퍼레이터의 구체적인 사례는 다음과 같다.

이러한 오퍼레이터들은 각 도메인의 복잡성을 캡슐화하여, 사용자는 단순한 YAML 선언문으로 전문적인 운영 작업을 수행할 수 있다. 결과적으로 쿠버네티스는 단순한 컨테이너 오케스트레이션 플랫폼을 넘어 복잡한 애플리케이션을 위한 진정한 애플리케이션 플랫폼으로 진화하게 된다.

CRD는 애플리케이션의 수명 주기 동안 스키마가 진화할 수 있도록 설계되었다. 이를 효과적으로 관리하기 위해 CRD 정의에는 spec.versions 필드를 통해 여러 API 버전을 명시할 수 있다. 각 버전은 독립적인 스키마를 가질 수 있으며, 쿠버네티스 API 서버는 지정된 버전 간의 변환을 처리한다. 일반적으로 v1alpha1, v1beta1, v1과 같은 버전 명명 규칙을 따른다.

버전 간의 호환성은 크게 두 가지 전략으로 관리된다. 첫째는 호환성이 깨지는 변경(Breaking Change)을 수반하는 새 API 버전을 추가하고, 기존 버전을 지원 중단(Deprecation) 경로에 놓는 방법이다. 둘째는 기존 버전의 스키마를 호환성을 유지하면서 확장하는 방법이다. 예를 들어, 필드를 추가하는 것은 일반적으로 안전한 변경 사항으로 간주된다.

버전 업그레이드 및 마이그레이션을 위해서는 변환 웹훅(Conversion Webhook)을 설정할 수 있다. 이 웹훅은 서로 다른 버전의 CRD 객체 간 변환 로직을 사용자 정의할 수 있게 해준다. 또한, CRD의 spec.preserveUnknownFields 값을 false로 설정하고 스키마를 엄격하게 정의하여 향후 호환성을 보장하는 것이 권장된다.

CRD를 사용할 때는 성능과 보안 측면에서 몇 가지 중요한 사항을 고려해야 한다. CRD 정의 자체는 쿠버네티스 API 서버의 스토리지 계층에 저장되며, 각 CRD는 etcd에 하나의 리소스로 기록된다. CRD의 수가 많아지거나, CRD로 생성된 커스텀 리소스 오브젝트의 수가 과도하게 증가하면 API 서버의 부하와 etcd의 저장 공간 및 성능에 영향을 미칠 수 있다. 특히, 와치 요청이 많거나 오브젝트의 크기가 클수록 네트워크 대역폭과 메모리 사용량이 증가한다.

보안 측면에서 CRD는 쿠버네티스 RBAC을 통해 접근 제어를 설정할 수 있다. CRD를 등록하는 사용자 또는 서비스 계정은 클러스터 수준의 권한이 필요하므로 주의가 요구된다. 또한, CRD의 스키마 정의를 통해 사용자 입력값의 유효성을 검증할 수 있지만, 이는 기본적인 검증에 불과하다. CRD를 처리하는 컨트롤러의 로직에 보안 취약점이 존재하거나, 악의적인 사용자가 특수하게 조작된 YAML 파일을 생성하여 컨트롤러를 공격할 수 있는 가능성을 배제할 수 없다. 따라서 컨트롤러 코드의 보안 검토와 입력값에 대한 철저한 검증이 필수적이다.

CRD와 관련된 권한 설정은 세심하게 관리해야 한다. 다음 표는 주요 보안 고려사항을 정리한 것이다.

마지막으로, CRD는 쿠버네티스 API를 확장하므로, 잘못 설계된 CRD는 API 서버의 업그레이드나 유지보수에 복잡성을 더할 수 있다. 호환되지 않는 스키마 변경은 기존 데이터와 클라이언트에 문제를 일으킬 수 있으므로, 앞서 설명한 버전 관리 전략을 준수하는 것이 장기적인 성능과 안정성 보장에 도움이 된다.

Kubebuilder는 쿠버네티스 CRD와 이를 관리하는 컨트롤러를 효율적으로 구축하기 위한 SDK이자 프레임워크입니다. 이 도구는 쿠버네티스 시그니처 프로젝트의 일부로, Go 언어를 사용하여 프로덕션 수준의 쿠버네티스 오퍼레이터를 개발하는 데 필요한 표준화된 구조와 도구를 제공합니다.

Kubebuilder의 핵심 기능은 스캐폴딩(Scaffolding)입니다. 개발자는 간단한 CLI 명령어를 통해 프로젝트의 기본 골격을 생성할 수 있습니다. 이는 CRD의 API 정의(Group, Version, Kind), 컨트롤러 코드, 웹훅 설정, 단위 테스트 및 통합 테스트 환경, 배포를 위한 매니페스트 파일 등을 포함합니다. 특히 컨트롤-루프 로직을 구현하는 데 필요한 기본적인 Reconcile 함수의 틀을 자동으로 생성해주어 개발자는 비즈니스 로직에 집중할 수 있습니다.

Kubebuilder는 내부적으로 컨트롤러-런타임과 컨트롤러-툴 라이브러리를 사용합니다. 이는 쿠버네티스 API와 상호작용하는 로우레벨 코드를 추상화하여, 개발자가 반복적이고 복잡한 보일러플레이트 코드를 작성하지 않도록 돕습니다. 또한, 로컬 쿠버네티스 클러스터에서 컨트롤러를 실행하고 테스트할 수 있는 환경(make run)과 컨테이너 이미지를 빌드하여 실제 클러스터에 배포하는 워크플로우(make docker-build, make deploy)를 표준화합니다.

Operator SDK는 레드햇이 주도하여 개발한 쿠버네티스 오퍼레이터를 구축하기 위한 프레임워크이자 도구 모음이다. 이 SDK는 개발자가 커스텀 리소스 정의와 이를 관리하는 컨트롤러를 효율적으로 생성, 테스트, 패키징, 배포할 수 있도록 돕는다. Go 언어를 기본으로 지원하며, Ansible과 Helm을 이용한 오퍼레이터 개발 옵션도 제공한다.

주요 구성 요소와 기능은 다음과 같다.

개발 워크플로우는 일반적으로 operator-sdk init 명령으로 프로젝트를 초기화한 후, operator-sdk create api로 CRD의 API(Groups, Versions, Kinds)와 컨트롤러 코드를 생성하는 방식으로 진행된다. 이후 생성된 Go 코드 틀에 비즈니스 로직을 구현하고, SDK가 제공하는 통합 테스트 환경에서 검증한 뒤, 오퍼레이터를 컨테이너 이미지로 빌드하여 클러스터에 배포한다.

Operator SDK는 쿠버네티스 오퍼레이터 프레임워크의 핵심 프로젝트로서, OLM 및 Operator Lifecycle Manager과 긴밀하게 통합되어 있다. 이를 통해 개발자는 애플리케이션의 운영 지식을 코드화한 오퍼레이터를 체계적으로 개발하고, 이를 사용자에게 패키지 형태로 배포 및 관리할 수 있는 생태계를 활용할 수 있다.