Kubebuilder 시작하기 편집하기

==개요==
;Getting Started
;시작하기

[[오퍼레이터 패턴]]을 따르면, 예상되는 모든 리소스를 제공할 수 있을 뿐만 아니라 이를 동적으로, 프로그래밍 방식으로, 실행 시 관리할 수 있습니다. 이 아이디어를 설명하기 위해 누군가 실수로 설정을 변경했거나 실수로 리소스를 제거했다고 가정해 보겠습니다. 이 경우 오퍼레이터는 사람의 개입 없이 문제를 해결할 수 있습니다.

==샘플 프로젝트==
어떻게 작동하는지 알려드리기 위해 샘플 프로젝트를 만들어 보겠습니다. 이 샘플은 다음을 수행합니다.
* Memcached CR 맞춤조정 - 클러스터에 배포/관리되는 Memcached의 인스턴스를 나타냅니다.
* Memcached 이미지를 사용하여 Deployment 생성
* 적용될 CR에 정의된 크기보다 많은 인스턴스 불허
* Memcached CR 상태 업데이트

다음 단계를 따르세요.

==프로젝트 생성==
먼저, 프로젝트 디렉토리를 만들고 탐색합니다. 그런 다음, kubebuilder를 사용하여 초기화합니다.

<syntaxhighlight lang='bash'>
mkdir $GOPATH/memcached-operator
cd $GOPATH/memcached-operator
kubebuilder init --domain=example.com
</syntaxhighlight>

==Memcached API (CRD) 생성==
다음으로 Memcached 솔루션 배포 및 관리를 담당하는 새로운 API를 생성하겠습니다. 이 경우 [Deploy Image Plugin][deploy-image]를 활용하여 솔루션에 대한 포괄적인 코드 구현을 얻습니다.

<syntaxhighlight lang='bash'>
kubebuilder create api --group cache --version v1alpha1 --kind Memcached --image=memcached:1.4.36-alpine --image-container-command="memcached,-m=64,-o,modern,-v" --image-container-port="11211" --run-as-user="1001" --plugins="deploy-image/v1-alpha" --make=false
</syntaxhighlight>

===API 이해하기===
이 명령어의 기본 목표는 Memcached 종류(Kind)에 대한 커스텀 리소스(CR) 및 커스텀 리소스 정의(CRD)를 생성하는 것입니다. 이는 Memcached 종류의 새 CRD를 고유하게 식별하는 <code>cache.example.com</code> 그룹과 <code>v1alpha1</code> 버전을 사용하여 API를 생성합니다. Kubebuilder 도구를 활용하여, 이러한 플랫폼에 대한 솔루션을 나타내는 API와 오브젝트를 정의할 수 있습니다. 이 예시에서는 리소스 Kind 하나만 추가했지만, <code>Groups</code>와 <code>Kinds</code>를 필요한만큼 추가할 수 있습니다. 간단하게, CRD는 커스텀 객체의 정의로 생각하고, CR은 객체의 인스턴스라고 생각하세요.

===API 정의===

====상태와 스펙====

====마커와 검증====

====커스텀 리소스 샘플====

===Reconciliation 처리===

====반환 옵션====

====우리 예시 맥락에서====
====클러스터의 변경 사항 관찰====

===RBAC 권한 설정===

===매니저 (main.go)===

===클러스터에서 실행 중인 프로젝트 확인===

==다음 단계==
* 솔루션 개발에 대해 더 자세히 알아보려면 제공된 튜토리얼을 살펴보세요.
* 접근 방식 최적화에 대한 통찰력을 얻으려면 [[kubebuilder 모범사례|모범사례]] 문서를 참조하세요.

==참고==
* https://book.kubebuilder.io/getting-started

[[분류: kubebuilder]]
@@ 31번째 줄: / 31번째 줄: @@
 ===API 이해하기===
-이 명령어의 기본 목표는 Memcached 종류(Kind)에 대한 커스텀 리소스(CR) 및 커스텀 리소스 정의(CRD)를 생성하는 것입니다. 이는 Memcached 종류의 새 CRD를 고유하게 식별하는 <code>cache.example.com</code> 그룹과 <code>v1alpha1</code> 버전을 사용하여 API를 생성합니다. Kubebuilder 도구를 활용하여, 이러한 플랫폼에 대한 솔루션을 나타내는 API와 오브젝트를 정의할 수 있습니다. 이 예시에서는 리소스 Kind 하나만 추가했지만, <code>Group</code>과 <code>Kind</code>를 필요한만큼 추가할 수 있습니다. 간단하게, CRD는 커스텀 객체의 정의로 생각하고, CR은 객체의 인스턴스라고 생각하세요.
+이 명령어의 기본 목표는 Memcached 종류(Kind)에 대한 커스텀 리소스(CR) 및 커스텀 리소스 정의(CRD)를 생성하는 것입니다. 이는 Memcached 종류의 새 CRD를 고유하게 식별하는 <code>cache.example.com</code> 그룹과 <code>v1alpha1</code> 버전을 사용하여 API를 생성합니다. Kubebuilder 도구를 활용하여, 이러한 플랫폼에 대한 솔루션을 나타내는 API와 오브젝트를 정의할 수 있습니다. 이 예시에서는 리소스 Kind 하나만 추가했지만, <code>Groups</code>와 <code>Kinds</code>를 필요한만큼 추가할 수 있습니다. 간단하게, CRD는 커스텀 객체의 정의로 생각하고, CR은 객체의 인스턴스라고 생각하세요.
-더 나은 아이디어 얻기
-Kubernetes 플랫폼에서 애플리케이션과 해당 데이터베이스를 실행하는 것이 목표인 일반적인 시나리오를 생각해 보세요. 이 컨텍스트에서 한 객체는 프론트엔드 앱을 나타내고 다른 개체는 백엔드 데이터베이스를 나타낼 수 있습니다. 앱에 대해 하나의 CRD를 정의하고 DB에 대해 또 다른 CRD를 정의하면 캡슐화, 단일 책임 원칙, 응집도와 같은 필수 개념을 유지합니다. 이러한 원칙을 위반하면 복잡성이 증가하여 확장, 재사용, 유지관리가 어려워질 수 있습니다.
-본질적으로, App CRD와 DB CRD에는 각각 자체 컨트롤러가 있습니다. 예를 들어 애플리케이션을 실행하려면 Deployment와 Service가 필요하다고 가정해 보겠습니다. 이 예시에서는 앱의 컨트롤러가 이러한 요구사항을 충족합니다. 마찬가지로 DB의 컨트롤러는 해당 항목의 비즈니스 로직을 관리합니다.
-따라서 각 CRD에는 [https://github.com/kubernetes-sigs/controller-runtime 컨트롤러 런타임]에 설명된 설계를 준수하는 하나의 별도 컨트롤러가 있어야 합니다 . 자세한 내용은 [https://book.kubebuilder.io/cronjob-tutorial/gvks 그룹, 버전, 종류]를 참조하세요. 이런! .
 ===API 정의===