CRD를 생성하면 벌어지는 일들

kubectl로 CRD(CustomResourceDefinition)를 생성하면 Kubernetes API 서버에 새로운 “Custom API”가 등록됩니다.

즉, kubectl create -f mycrd.yaml 같은 명령어로 CRD를 적용하면, Kubernetes는 해당 리소스를 공식 리소스처럼 인식하게 돼요.

 

CRD를 생성하면 무슨 일이 벌어질까?

1. apiextensions.k8s.io/v1의 CRD 오브젝트가 etcd에 저장됨

2. Kubernetes API 서버가 동적으로 해당 CRD를 감지

3. 지정된 group, version, kind에 따라 새로운 RESTful API endpoint가 자동으로 생성됨

• 예: myresources.mygroup.example.com/v1

4. kubectl이나 클라이언트가 해당 리소스를 쿼리하거나 생성할 수 있음

 

예를 들어 다음과 같은 CRD를 등록하면:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: Widget
    shortNames:
      - wd

 

생성 후엔 이런 API 경로가 추가됩니다:

/apis/example.com/v1/widgets

 

kubectl로는:

kubectl get widgets.example.com

 

혹은 (RBAC 허용 시):

kubectl get widgets

 

생성 후 API가 “사용 가능해지기까지” 얼마나 걸려?

 

대부분의 경우: 1초 미만

• API 서버는 CRD를 생성하면 즉시 동적으로 등록합니다

• 실제 endpoint가 사용 가능해지기까지는 수 밀리초~수백 밀리초

 

하지만 다음과 같은 상황에서는 잠깐 대기 필요할 수도 있어요:

원인	영향
API 서버 부하	CRD 등록이 지연될 수 있음
Operator/controller가 바로 Custom Resource 생성 시도	CRD가 아직 등록되지 않으면 실패
CRD가 매우 복잡하고 버전이 많음	registration 약간 지연될 수 있음

 

그래서 많은 Operator 구현에서는 보통:

wait.Poll(...)

을 써서 CRD가 완전히 활성화될 때까지 기다립니다.

 

생성 확인 방법

kubectl get crd widgets.example.com

kubectl get apiservices | grep example.com

kubectl api-resources | grep widget