#CRI #Infra #IaaS #개념

1. 컨테이너 런타임이란?

2. CRI(Container Runtime Interface)의 등장 배경

초창기 Kubernetes는 Docker 엔진만 지원 → Docker API 의존
다양한 런타임(containerd, CRI-O 등)을 쓰고 싶어도 표준화된 인터페이스가 없음 → kubelet마다 따로 개발해야 했음
해결책: CRI = kubelet ↔ 컨테이너 런타임 표준 gRPC API

→ kubelet은 CRI만 알면 되고, 런타임은 CRI만 구현하면 됨.

(원리 도식)

RuntimeService
- PodSandbox(쿠버네티스 Pod의 최소 단위) 관리
- 컨테이너 생성, 시작, 중지, 삭제
- exec/attach/logs 등 지원
ImageService
- 컨테이너 이미지 풀(Pull) / 제거(Remove) / 목록(List)
- 이미지 상태 조회

containerd
- CNCF 프로젝트, Docker 엔진에서 분리되어 독립 런타임으로 발전
- 대부분의 Kubernetes 클러스터에서 디폴트로 사용
CRI-O
- Red Hat 주도, “Lightweight CRI implementation for OCI containers”
- OpenShift 기본 런타임
(과거) dockershim
- kubelet 안에서 Docker API를 CRI로 변환해 주던 중간 계층
- Kubernetes 1.24에서 완전히 제거됨 (→ 이제 Docker 직접 지원 없음)

OCI(Open Container Initiative): 컨테이너 표준화 단체
- OCI Runtime Spec: 컨테이너 실행 표준 (runc 등)
- OCI Image Spec: 이미지 포맷 표준 (.tar 구조)
CRI: 쿠버네티스에서 “OCI 런타임을 어떻게 쓸지” 정의한 인터페이스
정리:
- OCI → 컨테이너 “표준”
- CRI → 쿠버네티스용 “API 인터페이스”

사용자가 kubectl apply -f pod.yaml 실행
kube-apiserver → kubelet에게 “Pod 실행” 전달
kubelet → CRI RuntimeService 호출
- RunPodSandbox (Pod 환경 준비)
- CreateContainer (컨테이너 생성)
- StartContainer (실행)
런타임(containerd/CRI-O)이 이미지 풀 → runc 실행 → 컨테이너 프로세스 시작

쿠버네티스 노드에서 어떤 런타임을 쓰는지 확인:

kubectl get node -o wide
kubectl describe node <nodename> | grep "Container Runtime"

예:

Container Runtime Version:  containerd://1.7.12

CRI 호출을 직접 테스트:

crictl ps       # 컨테이너 목록
crictl images   # 이미지 목록
crictl runp ... # PodSandbox 실행

※ crictl = kubelet과 같은 CRI gRPC를 호출하는 CLI 도구