[kubernetes] ☸️쿠버네티스의 도커 지원 중단에 대한 모든 것

vinca·2023년 11월 21일
5

☸️ kubernetes

목록 보기
13/35
post-thumbnail

🌟 쿠버네티스의 도커 지원 중단

쿠버네티스의 사용이 중단된 과정왜 중단하게 되었는 지, 그 과정에 대해서 그림을 통해서 그 과정을 알아봅시다.

☸️쿠버네티스는...

쿠버네티스는 원래 도커와의 호환이 잘 되는 도구였습니다.👌

🧐하지만... 시간이 갈수록 클러스터 운영자들은 쿠버네티스에서 도커가 아닌 다른 컨테이너 런타임을 사용하고 싶어했습니다.

운영하는 워크로드에 따라서 🔒보안에 중점을 둔 런타임, 🪄성능에 중점을 둔 런타임입맞에 맞게 유연하게 쓰고 싶었기 때문이죠.

이에 2020년12월8일. 쿠버네티스는 여러 컨테이너 런타임과 통신할 수 있도록 하는 CRI라는 표준 인터페이스🪟를 설계했습니다.

⚠️하지만 여기에는 큰 문제가 있었습니다.

바로, Docker는 이러한 CRI 인터페이스가 생기기전에 존재한 기술이였기 때문에 CRI 인터페이스에 맞지 않았죠.

이로 인해, 도커는 더이상 컨테이너 런타임으로써의 사용이 불가능해졌습니다.

✅ 이에 쿠버네티스의 운영진들은 이러한 도커를 컨테이너 런타임으로 계속 사용할 수 있도록 하기 위해서 dockershim이라는 어댑터 컴포넌트를 📟하드코딩하여 만들었고, 이러한 dockershim은 도커와 쿠버네티스의 중간에 번역하는 역할을 수행하면서, 도커와 CRI 사이의 차이를 메우는 역할을 하게 되었습니다.

이로써 어찌저찌 문제가 잘 해결된 것처럼 보였죠.

😧하지만, 이 쉼(shim)은 영구적인 해결방법이 되지 못했습니다.

시간이 지남에 따라 이 쉼의 존재는 kubelet 자체에 많은 불필요한 복잡성을 도입했고, 일부 통합은 이 쉼 때문에 Docker에 대해 일관성 없게 구현되었으며, 이로 인해 유지 관리 부담이 증가했습니다

특히나 이처럼 벤더 특정 코드(특정 제품인 Docker에 종속적인 코드)를 유지 관리하는 것은 ☸️쿠버네티스의 오픈 소스 철학에 부합하지 않았습니다.🧐

따라서, 쿠버네티스는 이러한 유지 관리 부담을 줄이고 오픈 표준을 지원하는 더 협력적인 커뮤니티로 나아가기 위해서 2020년 12월30일 👨🏻‍💻Wojciech Tyczynski씨가 dockershim의 제거를 제안했고(KEP-2221), 2022년4월 쿠버네티스 v1.24에서 결국 dockershim완전히 제거되게 되었습니다.

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

그렇다면 큰일 난 걸까요? 전혀 문제가 되는 부분이 없습니다!😃

컨테이너 런타임으로 도커쉼(dokcershim)을 사용해야하는 🐋도커를 사용하지 않고, 쿠버네티스 CRI를 준수하는 다른 컨테이너 런타임을 사용하면 됩니다.

컨테이너를 생성하고 실행하기 위해 필요한 컨테이너 런타임은 도커 이외에도 많으니까요!

그렇다면 쿠버네티스 CRI와 호환되는 컨테이너 런타임이 어떤 것이 있을까요?

먼저 현재 가장 많이 사용되는 컨테이너 런타임으로, 🐋도커에서 분리된 🛒컨테이너디(containerd)가 있습니다.

사실 containerd는 도커를 컨테이너 런타임으로 사용할 때 내부적으로 사용되는 컨테이너 런타임 기술로, 이젠 이러한 기술을 도커에서 빼서 containerd만 따로 사용하는 것이죠!

이렇게 한다면 ☸️쿠버네티스와 🛄컨테이너 간에 따로 도커심과 같은 중간 매체가 필요 없습니다.

이를 로직으로 보면 다음과 같습니다.

그림으로 보면 다음과 같습니다.

도커는 그럼 이제 쓸모가 없을까요?

그렇다면 도커는 이제 완전히 쓸모가 없어진 것일까요? 그렇지 않습니다! 위 그림에서만 봐도 도커는 여전히 남아있습니다.

🐋도커가 ➡️ ☸️쿠버네티스에서의 컨테이너 런타임으로 더 이상 사용되지 않는 것일 뿐,
도커가 개발 도구로도 쓸 수 없다는 뜻은 아닙니다.

쿠버네티스 런타임에서 도커를 제거하더라도 도커에서 만든 컨테이너 이미지를 등록하고 실행하는 것은 여전히 가능합니다.

도커가 생성하는 이미지🖼️는 여전히 업계 표준이며 이는 도커에만 특정된 이미지가 아닌 OCI(Open Container Initiative)표준 이미지이기 때문입니다.

즉, 도커가 생성한 이미지는 도커 뿐만 아니라 OCI 표준을 준수하는 그 어떤 컨테이너 런타임에서도 실행할 수 있습니다.

예를 들어, YAML 파일을 통해 파드를 배포하는 경우를 생각해봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: myapp
spec:
  containers:
  - name: mycontainer
    # 🐋도커로 생성된 이미지 파일🖼️
    image: nginx:latest

image 필드에 지정된 nginx:latest 이미지는 🐋도커를 통해 빌드된 이미지 입니다.

또한 이 이미지는 컨테이너 런타임인 containerd가 컨테이너를 생성할 때 🐋도커 레지스트리(Docker Hub🏤)에서 이미지를 다운로드하고 실행합니다.

어떤가요? 여전히 도커가 관여하는 부분이 많지 않나요?

도커는 버려야 하는 기술이 아닙니다! 사실 버릴 수 있는 기술도 아니고 말이죠.😅

✨결론

🎉따라서, 개발여전히 도커로 진행하되, 이를 실행하는 컨테이너 런타임다른 것으로 변경하면 여전히 동일한 환경으로 쿠버네티스를 사용할 수 있습니다.🤓

컨테이너 런타임에서 dockershim을 사용하지 못할 뿐 달라진 건 없습니다. 걱정하지마시고 운영하세요!

Reference

쿠버네티스가 도커 지원을 중단한다고? 뭐가 달라지나요?
https://careerly.co.kr/comments/76316
쿠버네티스 도커 지원 중단
https://fastcampus.co.kr/story_article_kubernetes

profile
붉은 배 오색 딱다구리 개발자 🦃Cloud & DevOps

0개의 댓글