최신판 |
당신의 편집 |
31번째 줄: |
31번째 줄: |
|
| |
|
| ===API 이해하기=== | | ===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 정의=== | | ===API 정의=== |