해당 문서의 쿠버네티스 버전: v1.30

Kubernetes v1.30 문서는 더 이상 적극적으로 관리되지 않음. 현재 보고있는 문서는 정적 스냅샷임. 최신 문서를 위해서는, 다음을 참고. 최신 버전.

당황하지 마세요. 쿠버네티스와 도커

By Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas | Translated By 박재화(삼성SDS), 손석호(ETRI) |

업데이트: 쿠버네티스의 도커심을 통한 도커 지원이 제거되었습니다. 더 자세한 정보는 제거와 관련된 자주 묻는 질문을 참고하세요. 또는 지원 중단에 대한 GitHub 이슈에서 논의를 할 수도 있습니다.

쿠버네티스는 v1.20 이후 컨테이너 런타임으로서 도커를 사용 중단(deprecating)합니다.

당황할 필요는 없습니다. 말처럼 극적이진 않습니다.

요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 컨테이너 런타임 인터페이스(CRI)를 사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated). 도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서 계속 작동될 것입니다.

쿠버네티스의 엔드유저에게는 많은 변화가 없을 것입니다. 이 내용은 도커의 끝을 의미하지 않으며, 도커를 더 이상 개발 도구로 사용할 수 없다거나, 사용하면 안 된다는 의미도 아닙니다. 도커는 여전히 컨테이너를 빌드하는 데 유용한 도구이며, docker build 실행 결과로 만들어진 이미지도 여전히 쿠버네티스 클러스터에서 동작합니다.

AKS, EKS 또는 GKE와 같은 관리형 쿠버네티스 서비스를 사용하는 경우 쿠버네티스의 향후 버전에서 도커에 대한 지원이 없어지기 전에, 워커 노드가 지원되는 컨테이너 런타임을 사용하고 있는지 확인해야 합니다. 노드에 사용자 정의가 적용된 경우 사용자 환경 및 런타임 요구 사항에 따라 업데이트가 필요할 수도 있습니다. 서비스 공급자와 협업하여 적절한 업그레이드 테스트 및 계획을 확인하세요.

자체 클러스터를 운영하는 경우에도, 클러스터의 고장을 피하기 위해서 변경을 수행해야 합니다. v1.20에서는 도커에 대한 지원 중단 경고(deprecation warning)가 표시됩니다. 도커 런타임 지원이 쿠버네티스의 향후 릴리스(현재는 2021년 하반기의 1.22 릴리스로 계획됨)에서 제거되면 더 이상 지원되지 않으며, containerd 또는 CRI-O와 같은 다른 호환 컨테이너 런타임 중 하나로 전환해야 합니다. 선택한 런타임이 현재 사용 중인 도커 데몬 구성(예: 로깅)을 지원하는지 확인하세요.

많은 사람들이 걱정하는 이유는 무엇이며, 왜 이런 혼란이 야기되었나요?

우리는 여기서 두 가지 다른 환경에 대해 이야기하고 있는데, 이것이 혼란을 야기하고 있습니다. 쿠버네티스 클러스터 내부에는 컨테이너 이미지를 가져오고 실행하는 역할을 하는 컨테이너 런타임이라는 것이 있습니다. 도커를 컨테이너 런타임(다른 일반적인 옵션에는 containerd 및 CRI-O가 있음)으로 많이 선택하지만, 도커는 쿠버네티스 내부에 포함(embedded)되도록 설계되지 않았기에 문제를 유발합니다.

우리가 "도커"라고 부르는 것은 실제로는 하나가 아닙니다. 도커는 전체 기술 스택이고, 그 중 한 부분은 그 자체로서 고수준(high-level)의 컨테이너 런타임인 "containerd" 입니다. 도커는 개발을 하는 동안 사람이 정말 쉽게 상호 작용할 수 있도록 많은 UX 개선을 포함하므로 도커는 멋지고 유용합니다. 하지만, 쿠버네티스는 사람이 아니기 때문에 이런 UX 개선 사항들이 필요하지 않습니다.

이 인간 친화적인 추상화 계층의 결과로, 쿠버네티스 클러스터는 containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심(Dockershim)이라는 다른 도구를 사용해야 합니다. 이것은 좋지 않습니다. 왜냐하면, 이는 추가적인 유지 관리를 필요로 하고 오류의 가능성도 높이기 때문입니다. 여기서 실제로 일어나는 일은 도커심이 빠르면 v1.23 릴리스에 Kubelet에서 제거되어, 결과적으로 도커에 대한 컨테이너 런타임으로서의 지원이 제거된다는 것입니다. 여러분 스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이 쿠버네티스에 왜 필요할까요?

도커는 컨테이너 런타임 인터페이스인 CRI를 준수하지 않습니다. 만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나 이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지 컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.

참고할 사항 한 가지: 현재 클러스터 내 워크플로의 일부가 기본 도커 소켓 (/var/run/docker.sock)에 의존하고 있는 경우, 다른 런타임으로 전환하는 것은 해당 워크플로의 사용에 문제를 일으킵니다. 이 패턴은 종종 도커 내의 도커라고 합니다. 이런 특정 유스케이스에 대해서 kaniko, img와 buildah 같은 것들을 포함해 많은 옵션들이 있습니다.

그렇지만, 이 변경이 개발자에게는 어떤 의미인가요? 여전히 Dockerfile을 작성나요? 여전히 도커로 빌드하나요?

이 변경 사항은 사람들(folks)이 보통 도커와 상호 작용하는 데 사용하는 것과는 다른 환경을 제시합니다. 개발에 사용하는 도커의 설치는 쿠버네티스 클러스터 내의 도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다. 개발자에게 도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히 유용합니다. 도커가 생성하는 이미지는 실제로는 도커에만 특정된 이미지가 아니라 OCI(Open Container Initiative) 이미지입니다. 모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이 쿠버네티스에서 동일하게 보입니다. containerd와 CRI-O는 모두 해당 이미지를 가져와 실행하는 방법을 알고 있습니다. 이것이 컨테이너가 어떤 모습이어야 하는지에 대한 표준이 있는 이유입니다.

변경은 다가오고 있습니다. 이 변경이 일부 문제를 일으킬 수도 있지만, 치명적이지는 않으며, 일반적으로는 괜찮은 일입니다. 사용자가 쿠버네티스와 상호 작용하는 방식에 따라 이 변경은 아무런 의미가 없거나 약간의 작업만을 의미할 수 있습니다. 장기적으로는 일이 더 쉬워질 것입니다. 이것이 여전히 혼란스럽더라도 괜찮습니다. 이에 대해서 많은 일이 진행되고 있습니다. 쿠버네티스에는 변화되는 부분이 많이 있고, 이에 대해 100% 전문가는 없습니다. 경험 수준이나 복잡성에 관계없이 어떤 질문이든 하시기 바랍니다! 우리의 목표는 모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. 이 글이 여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다! ❤️

더 많은 답변을 찾고 계신가요? 함께 제공되는 도커심 제거 FAQ(2022년 2월에 갱신됨)를 확인하세요.