[Kubernetes] Kuberntes History

서론

이 장에서는 지금까지 쿠버네티스가 어떻게 발전해 왔는지에 대해서 설명한다.

초기 쿠버네티스는 Docker Engine을 직접 호출해서 컨테이너를 실행시켰다.
도커 이외의 다수의 컨테이너 런타임을 지원하기 위해 CRI(Container Runtime Interface)가 등장하면서 쿠버네티스는 CRI를 통해 컨테이너 오케스트레이션이 가능해졌다.
하지만 도커 엔진은 자체적인 고유 API를 사용했기 때문에 쿠버네티스가 설계한 CRI와 호환되지 않았다.
이 문제를 해결하기 위해 쿠버네티스는 도커 엔진을 CRI에 맞추기 위한 어댑터 모듈(Dockershim)을 내장했다.
이 모듈은 쿠버네티스와 도커 엔진이 통신을 할 때 CRI 명령을 도커 네이티브 API 형식으로 변환하는 번역계층을 수행했다.

쿠버네티스가 CRI 표준을 도입하면서 컨테이너 런타임과의 통신 방식을 재정의했다. 하지만 당시 도커 엔진은 CRI를 지원하지 않았기 때문에, dockershim을 개발한 것이다.

그런데 도커 엔진이 업데이트될 때마다 쿠버네티스의 dockershim도 수정해야 했기 때문에 유지보수가 어려웠다.
이를 없애기 위해  dockershim 없이 쿠버네티스와 컨테이너 런타임 간 CRI만 쓰고, 런타임 내부에서 OCI Image/Runtime Spec으로 컨테이너를 실행하는 구조로 전환했다.

다시 말해 containerd · CRI‑O 같은 런타임은 CRI를 구현하면 쿠버네티스와 통신이 가능했고, 자신 안에서는 OCI 표준을 따라 runc 등 저수준 런타임을 호출한다.
- 컨테이너 “런타임”이란?
  - Docker Engine: CLI·빌드·이미지 관리·컨테이너 실행 모두 포함한 “종합세트”.
  - containerd, CRI-O: 빌드는 빼고 실행(core runtime) 기능에 집중한 경량화 버전.
  - Docker Engine = 런타임+@
  - containerd/CRI-O = 런타임 코어”
따라서 1.24 버전 이후에는 dockershim이 완전히 제거되면서 CRI를 직접 구현한 런타임만 지원하는 형태가 확정되었다.
crictl: CRI 소켓에 붙어 쿠버네티스 시점으로 컨테이너를 들여다보는 디버그 CLI
- crictl은 Kubelet과 동일한 API를 사용해 파드·컨테이너·이미지 정보를 가져옴
  - kubectl : 사용자 → API Server 통신용 CLI
  - kubelet : API Server → 노드(런타임) 연결 담당 에이전트
    - API Server의 지시에 따라 CRI 호출로 컨테이너를 만든다.
  - crictl : kubelet과 마찬가지로 CRI를 직접 호출하는 CLI
ctr·nerdctl: containerd 소켓에 붙어 containerd를 직접 조종하는 CLI(ctr=저수준, nerdctl=일상용).
- containerd 내부 객체(Task, Snapshot 등) 를 직접 만져야 할 때 사용.

쿠버네티스 클러스터의 전반적인 작업을 관리