쿠버네티스, 도커 지원 중단! 어떻게 해야 할까요?

쿠버네티스, 도커 지원 중단! 어떻게 해야 할까요?

‘네카라쿠배당토’로 대표되는 국내 대표 IT기업에 관심이 많은 분이시라면 ‘쿠버네티스(Kubernetes)’라는 단어를 한 번쯤 들어봤을 겁니다. 쿠버네티스는 국내 IT 대기업의 DevOps 직군에서 중요시하는 스킬로, 해외 IT매체 ZDNet에 따르면 전 세계 조직의 96%가 쿠버네티스를 이미 사용 중이거나 검토 중인 것으로 나타났죠.

쿠버네티스에 관심이 많으신 분들이라면 '도커(Docker)'에 관해서도 많이 들어보셨을 겁니다. 그동안 쿠버네티스와 도커는 떼려야 뗄 수 없는 관계로 여겨졌습니다. 쿠버네티스와 도커를 같은 의미로 아는 사람들도 적지 않죠.

그런데 지난 2020년 12월 8일, 쿠버네티스가 도커 사용을 중지한다고 발표했습니다. 이제 막 쿠버네티스 공부를 시작하는 개발자나 취준생 입장에서는 다소 어지러운 상황이라 할 수 있겠습니다. 도커 사용 중단 이전 버전으로 내용이 꾸려진 쿠버네티스 관련 도서나 온라인 강의로 공부하고 있었다면 더욱 그렇겠죠.

그렇다면 쿠버네티스와 도커는 과연 무엇일까요? 둘에는 어떤 차이가 있을까요? 그리고 쿠버네티스가 도커 지원을 중단한 상황에는 어떻게 대응해야 할까요? 한번 살펴봅시다.

하나에 특화된 도커, 다수를 관리하는 쿠버네티스

쿠버네티스와 도커를 이해햐기 위해서는 먼저 '컨테이너(Container)'에 관해 알아볼 필요가 있습니다. 컨테이너는 어떤 환경에서도 애플리케이션을 실행할 수 있도록 필요한 모든 요소를 포함하는 소프트웨어 패키지를 의미하죠.

컨테이너를 사용할 때 필요한 도구로는 컨테이너를 쉽게 다운로드받거나 공유하고 구동할 수 있게 도와주는 ‘컨테이너 런타임(Container Runtime)’이 있습니다. 그중에서 가장 유명한 도구가 ‘도커’에요. 도커는 컨테이너 기반의 오픈소스 가상화 플랫폼으로, 컨테이너 이미지를 생성, 관리, 공유, 구동하는 작업을 손쉽게 합니다.

그런데 서비스 개발/운영 환경에서는 컨테이너 하나만 사용하는 게 아닙니다. 데이터베이스와 웹 프론트엔드, 연상을 위한 백엔드 등 여러 컨테이너를 다수의 호스트에 배치하고 관리하는 작업이 필요하기 때문이죠. 이렇게 다수의 컨테이너 및 사용하는 환경 설정을 관리하는 것을 ‘오케스트레이션(Orchestration)’이라 합니다.

‘쿠버네티스’는 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구라 할 수 있습니다. 쿠버네티스를 사용하면 각각의 컨테이너를 일일이 하나씩 관리하지 않아도 됩니다. 또한, 기밀이나 앱 환경 구성처럼 개발자가 하기 귀찮은 세부 관리도 도맡아 해주니 더욱 편리하게 개발에 나설 수 있죠.

이러한 특성을 생각해보면, 컨테이너를 하나만 구성하고 관리할 때는 굳이 쿠버네티스를 사용할 필요가 없습니다. 오히려 도커로 관리할 때가 편한 경우도 있죠. 반면, 여러 개의 컨테이너를 서비스 단위로 관리해야 하는 상황에서는 쿠버네티스가 필요합니다.

쿠버네티스, v1.20부터 도커 지원 중단

이렇게 쿠버네티스와 도커는 분명 다릅니다. 다만, 그동안 쿠버네티스에서 사용하는 컨테이너 런타임으로 그동안 도커가 많이 쓰였죠. 하지만 쿠버네티스가 v1.20부터 도커 지원을 중단함에 따라 개발자 입장에서는 조금 골치가 아파졌습니다.

지난 2020년 12월 8일, 쿠버네티스는 버전 1.20버전 이후 도커를 컨테이너 런타임으로 사용하는 것을 중지한다고 발표했습니다. 쿠버네티스는 컨테이너 런타임과 통신할 때 CRI라는 표준 인터페이스 API를 사용하는데, 도커는 이를 지원하지 않아 호환성 문제가 발생했기 때문이죠.

이 때문에 도커와 쿠버네티스 API를 잇는 도구로 ‘도커심(Dockershim)’이 사용됐습니다. 쿠버네티스가 처음 등장한 시기에는 도커가 범용적으로 쓰이고 있었습니다. 그래서 도커 엔진 컨테이너 런타임에서 OCI 호출을 쿠버네티스 자체 CRI 내부의 도커 호출로 변환하기 위한 임시 솔루션으로 도커심이 많이 채택됐죠.

하지만 쿠버네티스의 최신 버진인 v1.24부터는 도커심 기본 지원도 중단되었습니다. 도커심 때문에 배포 속도가 느려지고 유지 관리자에게도 큰 부담을 안겨줬기 때문이죠. 근본적으로 ‘임시 방편’이었던 만큼 한계도 많았던 것입니다.

쿠버네티스를 지원하는 컨테이너 런타임을 사용합시다

그렇다면 큰일 난 걸까요? 고개 드세요! 아직 비상 아닙니다. 그냥 컨테이너 런타임을 도커심을 통하지 않고 CRI를 준수하는 다른 컨테이너 런타임으로 바꾸면 OK! 컨테이너를 생성하고 실행하기 위해 필요한 컨테이너 런타임은 도커 이외에도 많으니 알맞은 것을 선택하면 됩니다. 혹은 미란티스(Mirantis)에서 개발한 도커심의 외부 대체품인 크리도커드(cri-dockerd)를 쓰는 방법도 있죠.

그렇다면 쿠버네티스 CRI와 호환되는 컨테이너 런타임을 살펴볼까요? 먼저 도커 프로젝트에서 분리된 containerd가 있습니다. 도커 자체적으로도 containerd를 사용하지만, 이 런타임은 따로 도커심과 같은 중단 매체가 필요 없습니다.

CRI-O도 있습니다. 이를 사용하면 훨씬 가볍게 컨테이너 실행이 가능합니다. 다만, 도커가 제공하는 컨테이너 생성 및 이미지 빌드 기능은 제공하지 않아요. 그래서 도커 대신에 이미지를 빌드할 수 있는 툴이 필요한데, 대표적으로는 kaniko, buildash, Podman, Skpeo 등이 있습니다.

도커, 아직도 쓸모가 많습니다

그렇다면 도커는 이제 완전히 쓸모가 없어진 것일까요? 그렇지 않습니다. 쿠버네티스 개발팀측은 도커가 CRI를 사용하는 런타임으로 더 이상 사용되지 않는 것일 뿐, 도커를 더 이상 개발 도구로 쓸 수 없다는 뜻은 아니라고 발표했습니다.

무슨 뜻일까요? 먼저 쿠버네티스 런타임에서 도커를 제거하더라도 도커에서 만든 컨테이너 이미지를 등록하고 실행하는 것은 가능합니다. 도커가 생성하는 이미지는 도커에만 특정된 이미지가 아닌 OCI(Open Container Initiative)와 호환되는 이미지이기 때문이죠.

모든 OCI 호환 이미지는 해당 이미지를 빌드하는데 사용하는 도구와 상관없이 쿠버네티스에서 동일하게 보입니다. 이는 containerd나 CRI-O 등의 컨테이너 런타임에서도 도커 이미지를 가져와 실행할 수 있다는 뜻이죠.

그래서 개발은 여전히 도커로 진행하되, 이를 실행하는 컨테이너 런타임만 다른 것으로 바꾸면 큰 불편 없이 익숙한 환경에서 쿠버네티스를 사용할 수 있습니다. 최근에는 도커가 도커 데스크톱(Docker Desktop)에서 리눅스를 기본 지원함은 물론 다양한 개발자 도구를 통합하는 도커 확장(Docker Extensions)도 제공한다고 하니 더 편리해지겠죠?

지금 패캐머들이 읽고있는 BEST 아티클이 궁금하다면

DevOps 아티클 더 보러가기 👉