[Kubernetes] Kubernetes와 Docker (Kubernetes v1.20)

Kubernetes가 v1.20 업데이트 이후로 Docker를 Deprecate 하기로 결정했다.

(출처 : https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)

 

Docker를 바라보는 Kubernetes 관짝단

Deprecate Dockershim #94624

정확히 말하자면, Kubelet에서 Dockershim의 지원이 Deprecation 된 것이다. 

Kubernetes는 CRI (Container Runtime Interface) 인터페이스를 통해 컨테이너 런타임과 통신한다. CRI는 컨테이너 런타임과의 인터페이스 표준(API)을 정의한 것으로, Kubernetes CRI를 지원하면, 엔드 유저 입장에선 지금까지 써오던 Kubernetes와 크게 다르지 않게 사용할 수 있다. 

 

그러나 CRI가 정의된 이후에도 Docker는 자체적으로 CRI를 지원하지 않았고, CRI를 이용하기 위해 임시방편으로 마련해둔 'dockershim'을 지금까지 써왔다. 그러나 'dockershim'에서 잦은 이슈가 발생하고, 유지 보수 측면에서의 어려움이 지속되자 이번에 v1.20으로 업데이트하면서 'dockershim'을 deprecate 하기로 결정한 것이다.

 

즉, Docker API와 Kubernetes CRI 사이에서 '번역기'와 같은 역할을 담당하던 'dockershim'이 잦은 문제를 일으키니, Docker가 정식적으로 Kubernetes CRI를 지원하도록 약간의 압박(?)을 가했다고도 볼 수 있겠다.

 

Kubernetes가 생성하는 컨테이너는, 실제로는 Kubelet 컴포넌트가 자신과 연결된 Container Runtime에게 명령을 내려 생성하는 것이다. 따라서 Container Runtime이 굳이 Docker일 필요는 없다. 어떤 Runtime이든, Kubernetes가 내리는 명령을 정상적으로 이행할 수만 있으면 되기 때문이다. 요컨대, 사용자가 Kubernetes에 'Pod를 생성하는 명령'을 내리면, Kubernetes는 다양한 컴포넌트와 상호작용하여, 합리적이고 효율적인 위치에 컨테이너를 배치할 계획을 세운다. 그리고 실제 컨테이너를 해당 위치에 '생성'하는 것은 Container Runtime의 역할이다. 

 

간략하게 그리면 이렇다. (너무 간략한 것 같다)

Kubernetes CRI ('생성해!') -> 'dockershim' (번역) -> Docker API ('CREATION!')

이러한 상황에서 Kubernetes가 Docker의 기능을 모두 사용하는 것도 아니다. 그저 Container 생성 및 관리적인 측면에서 필요한 기능을 이용하는데, Docker를 Container Runtime으로 사용하자니, Kubernetes CRI를 지원하지 않아, 불필요한 기능도 모두 가져와야 하는 딜레마가 생긴다. 

 

그럼 Docker가 Deprecate되면, 우리가 사용할 수 있는 선택지는 무엇이 있을까?

대표적으로 'containerd'와 'CRI-O'가 있다.

containerd

containerd 로고. 그 옛날 콘솔 게임 로고처럼 생겼다. (출처 : containerd/containerd (github.com))

 

containerd는 Docker 사에서 16년 12월에 Docker의 Container Runtime 파트를 독립적인 오픈 소스로 분리하여 나온 프로젝트이다. 컨테이너를 실행하고 이미지를 관리하는 데 필요한 최소한의 기능 집합을 제공하는 OCI 호환 Container Runtime이다.

 

Docker와 달리, CRI를 통해 직접 제어할 수 있는 containerd (출처 : containerd/cri.png at master · containerd/containerd (github.com))

 

Kubernetes CRI를 지원하기 위해 containerd는 공식적으로 containerd plugin으로 CRI Plugin을 제공하고 있으며, Docker에서 분리되어 나온 덕분에(?), 별 차이 없이 잘 사용할 수 있다. containerd에 관해선 추후 포스팅으로 다룰 계획이다.

CRI-O

군더더기 없는 전형적인 오픈소스 로고. CRI-O (출처 : cri-o/cri-o (github.com))

CRI-O는 RedHat에서 개발한 CRI 런타임이다. Docker에 전혀 의존성이 없으며, RedHat OpenShift에서 사용하고 있다. 유일신과 같았던 Docker를 대체하고자 오픈 소스의 형태로 개발이 되고 있으며, Kubernetes와의 통합을 염두에 두고 발전해오고 있다. 다음에 기회가 된다면 containerd와 더불어 cri-o도 다뤄보고 싶다. (하지만 containerd부터 먼저 끝내고..)

 

아직 풀리지 않은 궁금증(Docker Image는..?)

결론부터 말하자면, Docker 이미지는 큰 문제없이 사용할 수 있을 것이다. Docker가 생성하는 이미지는 Docker에만 특화된 이미지가 아니라, OCI (Open Container Initiative) 표준을 준수하는 이미지이기 때문이다. OCI 표준을 준수하는 컨테이너 이미지는, 어떤 Container Runtime이건 이미지를 실행하는데 문제가 없다. 따라서 Docker가 deprecate 되더라도, 그동안 우리가 Docker로 빌드해 온 소중한 이미지들을 큰 문제가 없이 사용할 수 있다.

 

아 다행이다.. (후련)

끝으로

이 주제는 현재, Docker를 사용하던 유저라면 모를 수 없을 정도로 뜨거운 감자가 되었다. 오죽하면 Kubernetes 측에서 "Don't Panic: Kubernetes and Docker'라는 글을 써서 올렸을까. 

 

(대충 패닉하지 말라는 짤)

 

그동안 엔드 유저 입장에서 큰 불편함 없이 사용해오던 Docker이지만, Kubernetes의 장기적인 발전과 표준 확립을 위해서라도 언젠간 필요했을 움직임이라고 생각한다.

 

(다만 CKA를 준비하는 입장에선.. 어떤 내용이 추가되고 변경될지 불안한 건 사실이다ㅋㅋㅋ 그러니 미루지 말고 어서 시험을 보자!)

Reference

• Deprecate Dockershim #94624
• Kubernetes v1.20 Deprecation 
• Wait, Docker is deprecated in Kubernetes now? What do I do?
• containerd - kubernetes 표준 컨테이너 런타임