Docker 그리고 k8s...
컨테이너의 흐름
Docker 와 Containerd 그리고 k8s
Kubernetes가 컨테이너 런타임을 Docker에서 containerd로 변경한 이유는 몇 가지 기술적 요구사항과 운영 효율성을 고려한 결과입니다. 이 변화는 Kubernetes 1.20 버전에서 공식 발표되었고, 1.22부터는 Docker가 더 이상 지원되지 않으며 containerd와 같은 표준화된 컨테이너 런타임을 기본으로 사용하게 되었습니다.
Docker에서 containerd로 변경된 주요 이유
CRI(Container Runtime Interface) 표준화:
Kubernetes는 CRI라는 표준을 통해 다양한 컨테이너 런타임과 상호작용합니다. 그러나 Docker는 CRI를 직접 지원하지 않고, Docker를 Kubernetes에 사용하려면 중간 계층인 dockershim이 필요했습니다.
이 중간 계층은 Kubernetes의 코드 복잡성을 증가시키고 관리 부담을 더했습니다. Kubernetes가 더 가벼운 런타임인 containerd를 직접 사용하게 되면 dockershim을 제거할 수 있으며, 시스템이 간결하고 효율적으로 동작합니다.
간소화된 컨테이너 런타임:
Docker는 컨테이너를 실행하는 것 외에도 빌드, 이미지 관리, 네트워킹 등 많은 기능을 포함하고 있습니다. 그러나 Kubernetes에서는 컨테이너 실행 기능만 필요합니다.
containerd는 Docker의 핵심 컨테이너 실행 기능만을 담당하며, 더 간소화된 런타임으로 Kubernetes의 요구에 더 적합합니다. containerd는 Docker의 하위 계층으로 동작했으나, 이제는 독립적으로 Kubernetes에서 사용됩니다.
리소스 효율성:
Docker를 Kubernetes에서 사용할 경우, 컨테이너를 실행하기 위해 Docker 데몬이 항상 실행되어야 했습니다. Docker 데몬이 추가적인 리소스를 소비하고, 중간 계층이 필요하므로 성능과 리소스 효율성 측면에서 비효율적이었습니다.
containerd는 Docker 데몬 없이 직접 Kubernetes와 통합되어 리소스 사용을 최소화하고 더 나은 성능을 제공합니다.
오픈소스 표준과의 일치:
Docker는 여러 가지 기능을 통합한 종합적인 도구이지만, Kubernetes는 오픈 컨테이너 이니셔티브(OCI)와 같은 오픈 표준에 맞춘 간소화된 컨테이너 런타임을 선호합니다.
containerd는 OCI 표준을 준수하며, 더 나은 표준화된 컨테이너 관리 경험을 제공하기 때문에 Kubernetes의 방향성과 잘 맞습니다.
더 나은 유지보수 및 커뮤니티 지원:
containerd는 CNCF(Cloud Native Computing Foundation)의 프로젝트로 관리되고 있으며, Kubernetes와 밀접하게 협력하는 커뮤니티의 지원을 받고 있습니다. 이로 인해 지속적인 업데이트와 유지보수가 용이하고, Kubernetes와의 더 나은 호환성을 제공합니다.
Docker는 여전히 개발자 도구로 인기가 있지만, Kubernetes는 대규모 프로덕션 환경에서 보다 효율적이고 안정적인 런타임을 필요로 했기 때문에 containerd로 전환하게 되었습니다.
Docker에서 containerd로의 전환은 Kubernetes의 성능 향상, 표준 준수, 운영 간소화를 위한 결정이었습니다. Docker는 여전히 개발 도구로서 유용하지만, Kubernetes와 같은 대규모 클러스터 환경에서는 containerd와 같은 경량화된 컨테이너 런타임이 더 적합하다는 판단에 따른 것입니다.
Last updated