성장일기/Kubernetes

[k8s] 쿠버네티스가 도커 지원 중단한 이유가 무엇일까

지추월자 2024. 1. 3. 20:00
반응형

쿠버네티스(Kubernetes)가 처음에 도커(Docker)를 주요 컨테이너 런타임으로 사용하면서 시작했지만, 나중에 CRI(Container Runtime Interface)를 도입한 이유는 여러가지가 있으며 결론적으로는 쿠버네티스의 사용성이 점차 넓어지면서 쿠버네티스의 유연성, 확장성 및 범용성을 향상시키기 위한 전략적인 선택이었다고 합니다.

쿠버네티스는 다양한 환경과 사용 사례를 지원하는 범용 오케스트레이션 시스템을 목표로 했습니다. 처음에는 도커가 유일한 런타임 옵션이었지만, 시간이 지남에 따라 다른 컨테이너 런타임 기술들도 발전했습니다. CRI를 도입함으로써 쿠버네티스는 도커 외에도 containerd, CRI-O와 같은 다양한 컨테이너 런타임을 지원할 수 있게 되었습니다.

CRI는 쿠버네티스와 컨테이너 런타임 간의 표준화된 인터페이스를 제공하여, 쿠버네티스가 다양한 컨테이너 런타임(예: containerd, CRI-O)과 호환될 수 있도록 했습니다.

반면에 도커는 CRI를 직접적으로 지원하지 않고, 쿠버네티스가 도커와 함께 작동하기 위해서는 "Dockershim"이라는 중간 계층이 필요했습니다.

쿠버네티스 입장에서는 Dockershim 계층은 유지 관리와 성능 측면에서 부담이 될 수 있다고 생각했습니다.

쿠버네티스는 더 간단하고 효율적인 시스템을 추구하며, CRI를 직접 지원하는 다른 런타임으로 전환함으로써 이러한 문제를 해결할 수 있었기 때문에 도커 지원을 1.20부터 도커(Docker)에 대한 지원을 점진적으로 중단하기 시작했습니다. 사실 이러한 중단은 Dockershim 계층, 즉 쿠버네티스와 도커 간의 연결을 제공하는 중간 계층을 폐기를 의미하는 것이었죠. 

그래서 1.24부터는 완전히 Dockershim을 제거하고 CRI 로 전환한 것입니다. 

관련 문서 : https://kubernetes.io/docs/setup/production-environment/container-runtimes/

반응형