요약
1. docker는 여러가지 기능이 모여있는 tech stack이다.
2. kubernetes의 runtime으로는 docker의 일부분인 containerd만 있으면 충분하다.
3. containerd는 예전부터 지원했고 앞으로도 지원하니까 이걸 사용해라.
익명(223.62)2020-12-04 20:28
답글
그냥 다 지들껄로 쓰라는뜻?
익명(113.130)2020-12-04 21:55
답글
containerd가 docker껀데 이걸 계속 쓰겠다는데 다 지들껄로 쓰라는뜻은 뭔소린지
익명(223.62)2020-12-04 22:10
답글
containerd는 docker랑 k8s랑 다른 레이어임. k8s는 containerd가 제공해주는 container runtime만 있으면되고 docker를 버리는 이유는 docker가 제공하는 human friendly abstraction layer 때문에 오히려 CRI 표준을 못지킴 그래서 k8s가 docker를 다루려면 shim이 따로 필요했는데
익명(115.23)2020-12-04 22:14
답글
굳이 human friendly abstraction layer가 k8s한테 필요도 없고 유지보수 개선에 오버헤드만 되니 deprecate하겠단건데 충분히 reasonable한듯
익명(115.23)2020-12-04 22:16
답글
나도 합리적이라고 생각한다 kubernetes가 굳이 docker를 통해서 containerd에 접근해서 관리할 필요가 없어지니까
지들이 도커 짭이면서 상도덕도 없네
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
요약 1. docker는 여러가지 기능이 모여있는 tech stack이다. 2. kubernetes의 runtime으로는 docker의 일부분인 containerd만 있으면 충분하다. 3. containerd는 예전부터 지원했고 앞으로도 지원하니까 이걸 사용해라.
그냥 다 지들껄로 쓰라는뜻?
containerd가 docker껀데 이걸 계속 쓰겠다는데 다 지들껄로 쓰라는뜻은 뭔소린지
containerd는 docker랑 k8s랑 다른 레이어임. k8s는 containerd가 제공해주는 container runtime만 있으면되고 docker를 버리는 이유는 docker가 제공하는 human friendly abstraction layer 때문에 오히려 CRI 표준을 못지킴 그래서 k8s가 docker를 다루려면 shim이 따로 필요했는데
굳이 human friendly abstraction layer가 k8s한테 필요도 없고 유지보수 개선에 오버헤드만 되니 deprecate하겠단건데 충분히 reasonable한듯
나도 합리적이라고 생각한다 kubernetes가 굳이 docker를 통해서 containerd에 접근해서 관리할 필요가 없어지니까