CRD와 CR만 정의하는 경우 활용 사례

✅ Controller 없이 CRD와 CR만 정의하는 경우의 유즈케이스

Kubernetes에서 CRD(Custom Resource Definition) 와 CR(Custom Resource) 만 정의하고, 컨트롤러를 작성하지 않는 경우에도 몇 가지 유용한 활용 사례가 있습니다. 이러한 경우 주로 데이터 저장, 구성 관리, API 확장 등의 목적으로 사용됩니다.

 

1️⃣ 선언적 설정 저장소 (Declarative Configuration Storage)

• CRD를 데이터 저장소로 사용하여 특정 애플리케이션이나 시스템의 설정 값을 Kubernetes 클러스터에 저장할 수 있음.
• 애플리케이션이 Kubernetes API를 통해 CR을 읽어가며 설정을 가져올 수 있음.
• 컨트롤러가 필요 없음 → 애플리케이션이 직접 API 호출하여 설정을 가져오면 됨.

📌 예제: 애플리케이션 설정 저장

apiVersion: config.example.com/v1
kind: AppConfig
metadata:
  name: my-config
spec:
  logLevel: "debug"
  maxRetries: 5

🔹 유즈케이스

• 설정 파일(ConfigMap, Secret 대신 CRD 사용)
• 특정 서비스의 구성 저장 (예: DB 연결 정보, API 키 등)

 

2️⃣ 클러스터 내부 상태 기록 및 조회 (State Registry)

• 클러스터 내 특정 애플리케이션의 상태를 저장하는 용도로 사용 가능.
• 컨트롤러 없이 CRD만 등록해도 kubectl 또는 API를 통해 데이터 조회 가능.
• kubectl get을 활용하여 관리자가 직접 클러스터 상태를 조회할 수 있음.

📌 예제: 애플리케이션 배포 상태 저장

apiVersion: status.example.com/v1
kind: DeploymentStatus
metadata:
  name: my-app-status
spec:
  lastDeployed: "2023-01-01T12:00:00Z"
  version: "v1.2.3"
  replicas: 3
  healthy: true

🔹 유즈케이스

• GitOps 또는 배포 도구가 특정 리소스의 상태를 저장하는 용도로 사용.
• 클러스터 내 사용자 정의 상태 저장소.

 

3️⃣ Kubernetes 네이티브 API 확장

• 컨트롤러 없이 CRD만 정의해도 Kubernetes API로 사용할 수 있음.
• 사용자가 kubectl을 통해 CRD 기반의 리소스를 직접 생성하고 관리 가능.
• CLI 도구에서 Kubernetes API를 확장하는 방식으로 활용 가능.

📌 예제: 자체적인 네임스페이스 관리

apiVersion: myplatform.example.com/v1
kind: Tenant
metadata:
  name: team-a
spec:
  owner: "alice@example.com"
  quota:
    cpu: "2"
    memory: "4Gi"

🔹 유즈케이스

• 다중 테넌트 환경에서 팀별 네임스페이스 관리 (kubectl get tenants)
• kubectl 기반 관리 도구 확장 (리소스 정의, 상태 조회 등)

 

4️⃣ 서드파티 애플리케이션과의 통합

• CRD를 통해 외부 애플리케이션과 Kubernetes 리소스를 연계할 때 사용.
• 특정 컨트롤러 없이 외부 시스템이 CRD 데이터를 활용하는 방식.

📌 예제: 모니터링 시스템과 연동

apiVersion: monitoring.example.com/v1
kind: AlertRule
metadata:
  name: high-cpu
spec:
  metric: "cpu_usage"
  threshold: 80
  action: "notify"

🔹 유즈케이스

• Prometheus, Datadog 같은 모니터링 시스템이 CRD 데이터를 활용.
• API Gateway에서 CRD를 이용해 엔드포인트 설정 관리.

 

5️⃣ GitOps 및 IaC(Infrastructure as Code) 관리

• CRD를 선언적인 인프라 정의 파일로 사용 가능.
• ArgoCD, Flux 같은 GitOps 도구와 함께 사용하면 컨트롤러 없이도 리소스 배포 가능.

📌 예제: GitOps를 위한 인프라 정의

apiVersion: infra.example.com/v1
kind: VirtualMachine
metadata:
  name: vm-01
spec:
  cpu: "4"
  memory: "8Gi"
  disk: "100Gi"

🔹 유즈케이스

• Kubernetes에서 직접 가상 머신(VM) 또는 클라우드 리소스 선언.
• Terraform 또는 Pulumi 같은 IaC 도구와 함께 사용.

 

6️⃣ 컨트롤러 없이도 활용 가능한 Kubernetes 네이티브 기능

• Admission Webhook과 조합 → CRD를 활용해 웹훅이 특정 리소스를 검증 가능.
• OpenAPI 스키마 검증 → CRD에 필드 검증 규칙을 정의해 입력 유효성 검사 가능.
• kubectl 활용 → kubectl apply, kubectl get 명령어만으로 리소스 관리 가능.

🚀 정리

즉, 컨트롤러 없이도 CRD와 CR만으로 유용한 활용이 가능하며, Kubernetes를 하나의 데이터 저장소 또는 API 확장 도구로 활용할 수 있음