이 글은 아래 링크(Kubernetes Blog)의 내용을 번역한 내용으로 이루어져 있습니다.
Authors: Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
Kubernetes는 v1.20 이후 버전에서 더 이상 Docker를 컨테이너 런타임으로 지원하지 않게됩니다.
생각하는 것 처럼 급격한 변화는 아니며, 패닉에 빠질 이유는 없습니다.
런타임으로서 Docker를 지원하지 않는 이유는 Kubernetes를 위한 CRI(Container Runtime Interface)를 사용하는 런타임을 사용하기 위함입니다. Docker를 통해 생성된 이미지는 여전히 클러스터에서 다른 모든 런타임을 통해 사용할 수 있습니다.
Kubernetes 엔드유저라면 전체적으로 많은 것이 바뀌지는 않을것입니다. Docker 런타임을 Kubernetes에서 지원하지 않는 것이 Docker의 종말을 의미하지는 않으며, Docker를 더 이상 개발 도구로 사용할 수 없거나 사용 해선 안된다는 의미는 아닙니다. Docker는 여전히 컨테이너를 빌드하는데 유용한 도구이며, docker build
를 통해 빌드된 이미지를 Kubernetes 클러스터에서 계속 사용할 수 있습니다.
GKE, EKS, AKS 등 containerd가 기본인 관리형 Kubernetes 서비스를 사용한다면 Kubernetes 미래 버전에서 Docker 런타임이 제거되기 전에 워커노드가 지원 가능한 컨테이너 런타임을 사용중인지 확인해야 합니다. 노드를 커스텀해서 사용중이라면 사용중인 환경과 런타임 요구 사항에 따라 업데이트를 진행해야 할 수도 있습니다. 적절한 업그레이드 테스트와 계획이 진행될 수 있도록 서비스 제공자와 협력 할 것이 권고됩니다.
직접 구축한 클러스터를 운영중이라면, 클러스터가 사용 불가한 상태가 되는것을 피하기 위해 몇가지 변화를 주어야 합니다. v1.20에서는, Docker에 대한 Deprecation 워닝을 받게 됩니다. Docker 런타임 지원이 미래의 Kubernetes 릴리즈(현재 계획은 2021년 후반의 v1.22 입니다)에서 사라지게 되면, containerd 또는 CRI-O와 같은 지원되는 컨테이너 런타임으로 전환해야 합니다. logging과 같은 Docker 데몬 설정이 지원되는 런타임을 선택해주시기 바랍니다.
많은 사람이 혼란스럽고 두려워하는 이유는 무엇입니까?
혼란이 생길 수 있는 2가지 환경에 대해 이야기 하고자 합니다. Kubernetes 클러스터 안에는 컨테이너 런타임이라는, 컨테이너 이미지를 pulling하고 running하는데 책임이 있는 구성요소가 있습니다. Docker는 이 런타임으로 인기있는 선택지이며, 다른 일반적인 옵션으로 containerd와 CRI-O가 있습니다. 하지만 Docker는 Kubernetes에 내장형으로 설계되지 않아 문제를 일으킬 여지가 존재합니다.
우리가 Docker라고 부르는 것은 사실 하나의 구성요소가 아닙니다. Docker는 하나의 기술 스택이며, 이 스택 중 하나가 containerd입니다. containerd는 그 자체로 높은 레벨의 컨테이너 런타임 입니다. Docker는 사용자가 개발을 하는 동안, 사람과 상호작용하기 쉽도록 UX적인 강화가 이루어졌기 때문에 매우 쿨하고 유용하지만, 이러한 UX 향상은 Kubernetes에는 필요하지 않습니다. Kubernetes가 사람이 아니기 때문이죠.
이러한 인간 친화적 추상화 레이어가 추가된 결과로 Kubernetes 클러스터는 Dockershim이라는 또 다른 도구를 사용해서, 진짜로 필요한 containerd를 얻어내야 합니다. 이것은 추가적인 운영 요소를 만들며, 고장날 수 있기 때문에 좋지 않죠. "Docker Deprecated"에서 실제로 일어나는 일은 Dockershim이 Kubelet에서 빠르면 v1.23에서부터 사라지게 되며, 이에 따라 Docker에 대한 컨테이너 런타임 지원이 종료되게 되는 것 입니다. 여기까지 읽었을 때, containerd가 Docker 스택에 포함되어있는데 왜 Dockershim이 필요하지? 라는 의문이 생기실 수 있습니다.
그렇다면 이 변화가 개발자에 의미하는 바는 무엇인가요? 우리는 계속해서 Dockerfile들을 작성하게 되나요? Docker를 통해 이미지를 빌드해도 되나요?
Docker는 CRI(Container Runtime Interface)에 호환되지 않습니다. 만약 가능하다면 우리는 Dockershim이 필요 없을것이며, 아무런 문제도 되지 않겠죠. 하지만 이 문제는 사실 해결 불가능한 것이 아니며, 패닉에 빠질 필요도 없습니다. 그저 컨테이너 런타임을 Docker에서 호환 가능한 다른 런타임으로 바꾸기만 하면 됩니다.
알아두어야 할 사실은, Docker Socket(/var/run/docker.sock)을 클러스터 내부의 워크플로우의 일부로 사용중이라면(의존성이 존재한다면), 다른 컨테이너 런타임으로 바꿀 때 사용 불가능하게 될 수 있습니다. 이러한 패턴은 Docker in Docker 패턴으로 불립니다. 이러한 특별한 유스케이스에 대해 kaniko, img, buildah와 같은 옵션이 존재합니다.
이 변화는 Docker와 상호작용하는 대부분의 케이스와 다른 환경을 제공하게 됩니다. 사용중인 개발 환경에 Docker를 설치하는 것은 Kubernetes 클러스터 내부에 Docker 런타임을 설치하는 것과는 상관이 없습니다. 혼란스러우실 수 있습니다. 개발자는 여전히 Docker를 Kubernetes의 변화가 발표되기 이전과 동일하게 유용하게 사용할 수 있습니다. Docker가 생성하는 이미지는 Docker에서만 특정하게 사용 가능한 이미지는 아닙니다. OCI(Open Container Initiative)이미지로 생성되죠. 모든 OCI 호환 이미지는 빌드 툴과 관련 없이 Kubernetes에서 동일하게 보이게 됩니다. containerd와 CRI-O는 모두 이러한 이미지를 pull 하고 run 할 수 있습니다. 이것이 왜 컨테이너에 대한 표준이 필요한지에 대한 이유가 될 수 있겠죠.
아무튼 이 변화는 곧 이뤄집니다. 누군가에게는 이슈가 될 수 있지만, 재앙적이진 않을것이며, 보편적으로는 좋은 일이 될 것입니다. Kubernetes를 어떻게 사용하는지에 따라 아무런 영향이 없을 수도 있고, 약간의 작업이 필요할 수도 있겠죠. 길게 보면 모든 과정이 쉽게 될 것입니다. 여전히 혼란스러우시더라도 괜찮습니다. Kubernetes는 수 많은 구성 요소가 동작하고 있으며, 어느 누구도 모든것에 100% 전문가일수는 없습니다. 우리는 경험 레벨과 복잡도와 상관 없이 어떤, 그리고 모든 질문을 환영합니다. 우리의 목표는 모든 사람이 다가올 변화에 대해 충분히 알게 되는 것 입니다.