CSI, CRD, CRI, CNI

존재하는 이유: k8s가 특정 구현체에 종속되지 않도록 만든 표준 인터페이스

 

- CSI (Container Storage Interface): 스토리지를 파드에 붙이는 표준 인터페이스

* EBS CSI Driver: CSI를 참고하여 구현한 AWS 전용 드라이버 -> EKS add on 에 추가 가능 

PVC 생성 
-> controller-manager
-> CSI Controller Plugin 호출(EBS 생성)
-> 파드 스케줄링
-> kubelet 
-> CSI Node Plugin 호출
-> 파드에서 볼륨 사용

 

PV / PVC / StorageClass 관계 

1. 어떤 개발자가 요청을 하면, 

2. 어떤 타입의 스토리지인지 정의되어잇는 StorgeClass를 참고해서 

3. 동적으로 PV 한다. 

  개발자          관리자/CSI
    │               │
  PVC 생성  →  StorageClass 참조  →  CSI가 PV(EBS) 동적 생성
    │                                  │
    └──────────── 바인딩 ────────────────┘
    
    # PVC 생성 예시
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
  - ReadWriteOnce        # 단일 노드에서 읽기/쓰기
storageClassName: gp3   # 어떤 StorageClass 쓸지 지정
resources:
  requests:
    storage: 10Gi        # 10GB 요청

 

--

CRD (Custom Resource Definition): k8s API를 확장해 커스텀 리소스를 정의 

  기본 리소스: Pod, Deployment, Service ...
         +
  CRD 정의  →  커스텀 리소스 추가
               예: Application (ArgoCD), Rollout (Argo Rollouts)
                   NodeClaim (Karpenter), ExternalSecret (ESO)

 

CRD : 커스텀 리소스의 스키마 정의 (설계도)

CR : CRD로 만든 실제 오브젝트 (인스턴스)

Operator: CR을 감지해서 원하는 상태로 만드는 컨트롤러

 

Reconcile Loop: Operator의 핵심 동작

현재 상태와 원하는 상태를 계속 비교 -> 다르면 맞춤 -> 반복 

-> k8s의 자가 치유의 핵심 

 

--

CRI (Container Runtime Interface): 컨테이너를 어떻게 실행할 것인가?

kubelet이 containerd 한테 "이 컨테이너 실행해줘" -> CRI는 그 컨테이너의 규격이 된다.

실제로는 containerd, CRI-O 등이 구현체이다.

 

--

CNI (Container Network Interface): 파드에 IP/Network를 어떻게 붙일 것인가?

파드가 생성되면 kubelet이 CNI 플러그인한테 “이 파드에 IP 붙여줘” → CNI는 그 네트워크의 규격

AWS애서는 VPC CNI가 구현체 → ENI에서 IP를 뽑아서 파드에 직접 할당