Kubernetes & Docker

发布于 2020-12-09 · 本文总共 2495 字 · 阅读大约需要 8 分钟

Don’t Panic: Kubernetes and Docker

So why the confusion and what is everyone freaking out about?

Inside of your Kubernetes cluster, there’s a thing called a container runtime that’s responsible for pulling and running your container images.

Docker is a popular choice for that runtime (other common options include containerd and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and that causes a problem.

What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker?

Any OCI-compliant image, regardless of the tool you use to build it, will look the same to Kubernetes. Both containerd and CRI-O know how to pull those images and run them.

Docker与Kubernetes

Kubelet 之前使用的是一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持;

Docker 并不支持 CRI（容器运行时接口）这一 Kubernetes 运行时 API，而 Kubernetes 用户一直以来所使用的其实是名为“dockershim”的桥接服务; Dockershim 能够转换 Docker API 与 CRI，但在后续版本当中，Kubernetes 将不再提供这项桥接服务;

CRI运行时

CRI是Container Runtime Interface，容器运行时接口；是一组接口规范；

这一插件规范让Kubernetes无需重新编译就可以使用更多的容器运行时；CRI包含Protocol Buffers、gRPC API及运行库支持，还有尚在开发的标准规范和工具；

CRI概述

CRI最核心的两个概念就是PodSandbox和container；

RuntimeService：

ImageService：

LogService：

为什么需要CRI

在CRI存在之前，容器运行时需要通过实现Kubelet里面high-level的接口才能集成进来；

这样集成的成本很高，需要开发人员了解整个Kubelet的架构，并且会将代码合并到Kubelet主项目里面；非常不利于Kubelet的扩展性，因为每个新改动都会增加维护难度；

Kubernetes的目标是具有高度的可扩展性，而CRI为方便使用一个可插拔的容器运行时（Docker/rkt）并构建一个健康的Kubernetes生态迈出了一小步；

不是所有的容器运行时都原生的支持Pod概念；为了支持所有这些Pod特性，当这些容器运行时与Kubernetes集成时，需要花费大量的工作来实现一个Shim；
高层次的接口让代码共享和重用变得困难；
Pod Spec演化速度快，pod经常添加新的特征，任何Pod级别的特性修改或增加都会导致容器运行时的修改；

如何使用CRI

Docker CRI实现：

设置kubelet flag，–experimental-cri=true –container-runtime=docker

Kubeklet会启动一个Local Unix Socket的gRPC CRI server进行PodSandBox、Pod、container的生命周期管理；

cri-o CRI实现：

在节点上启动runtime service，如cri-o，https://github.com/cri-o/cri-o；

设置kubelet flag，–experimental-cri=true –container-runtime=remote –container-runtime-endpoint=unix:///var/run/oci.sock –image-service-endpoint=unix:///var/run/oci.sock

CRI的目标

提升Kubernetes的扩展性，让更多的容器运行时更容易集成到Kubernetes中；
提升Pod Feature的更新迭代效率；
构建易于维护的代码体系；

containerd

https://github.com/containerd/containerd/

CRI-O

https://github.com/cri-o/cri-o

CRI-O 是主要由 Red Hat 员工开发的 CRI 运行时。它的最大区别在于并不依赖于 Docker，而且目前已经在 Red Hat OpenShift 中得到使用；

总结

1.可以考虑使用CRI运行时，例如containerd与CRI-O；

contianerd与Docker相兼容，二者共享相同的核心组件；

如果要使用Kubernetes的最低功能选项，CRI-O可能更为适合；

2.明确CRI运行时与OCI运行时之间功能与作用范围；

refs

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md