"Kubebuilder 시작하기"의 두 판 사이의 차이

2024년 4월 17일 (수) 17:01 기준 최신판

1 개요[ | ]

Getting Started
시작하기

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

2 샘플 프로젝트[ | ]

어떻게 작동하는지 알려드리기 위해 샘플 프로젝트를 만들어 보겠습니다. 이 샘플은 다음을 수행합니다.

Memcached CR 맞춤조정 - 클러스터에 배포/관리되는 Memcached의 인스턴스를 나타냅니다.
Memcached 이미지를 사용하여 Deployment 생성
적용될 CR에 정의된 크기보다 많은 인스턴스 불허
Memcached CR 상태 업데이트

다음 단계를 따르세요.

3 프로젝트 생성[ | ]

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

mkdir $GOPATH/memcached-operator
cd $GOPATH/memcached-operator
kubebuilder init --domain=example.com

4 Memcached API (CRD) 생성[ | ]

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

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

4.1 API 이해하기[ | ]

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

더 나은 아이디어 얻기

Kubernetes 플랫폼에서 애플리케이션과 해당 데이터베이스를 실행하는 것이 목표인 일반적인 시나리오를 생각해 보세요. 이 컨텍스트에서 한 객체는 프론트엔드 앱을 나타내고 다른 개체는 백엔드 데이터베이스를 나타낼 수 있습니다. 앱에 대해 하나의 CRD를 정의하고 DB에 대해 또 다른 CRD를 정의하면 캡슐화, 단일 책임 원칙, 응집도와 같은 필수 개념을 유지합니다. 이러한 원칙을 위반하면 복잡성이 증가하여 확장, 재사용, 유지관리가 어려워질 수 있습니다.

본질적으로, App CRD와 DB CRD에는 각각 자체 컨트롤러가 있습니다. 예를 들어 애플리케이션을 실행하려면 Deployment와 Service가 필요하다고 가정해 보겠습니다. 이 예시에서는 앱의 컨트롤러가 이러한 요구사항을 충족합니다. 마찬가지로 DB의 컨트롤러는 해당 항목의 비즈니스 로직을 관리합니다.

따라서 각 CRD에는 컨트롤러 런타임에 설명된 설계를 준수하는 하나의 별도 컨트롤러가 있어야 합니다 . 자세한 내용은 그룹, 버전, 종류를 참조하세요. 이런! .

4.2 API 정의[ | ]

4.2.1 상태와 스펙[ | ]

4.2.2 마커와 검증[ | ]

4.2.3 커스텀 리소스 샘플[ | ]

4.3 Reconciliation 처리[ | ]

4.3.1 반환 옵션[ | ]

4.3.2 우리 예시 맥락에서[ | ]

4.3.3 클러스터의 변경 사항 관찰[ | ]

4.4 RBAC 권한 설정[ | ]

4.5 매니저 (main.go)[ | ]

4.6 클러스터에서 실행 중인 프로젝트 확인[ | ]

5 다음 단계[ | ]

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

6 참고[ | ]

https://book.kubebuilder.io/getting-started

@@ 32번째 줄: / 32번째 줄: @@
 ===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은 객체의 인스턴스라고 생각하세요.
+더 나은 아이디어 얻기
+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 정의===