微信公众号:运维开发故事,作者;夏老师
CRI shim是什么?
实现了 CRI 接口的容器运行时通常称为 CRI shim, 这是一个 gRPC Server,监听在本地的 unix socket 上;而 kubelet 作为 gRPC 的客户端来调用 CRI 接口,来进行 Pod 和容器、镜像的生命周期管理。另外,容器运行时需要自己负责管理容器的网络,推荐使用 CNI。
kubelet 调用下层容器运行时的执行过程,并不会直接调用Docker 的 API,而是通过一组叫作 CRI(Container Runtime Interface,容器运行时接口)的 gRPC 接口来间接执行的,意味着需要使用新的连接方式与 docker 通信,为了兼容以前的版本,k8s 提供了针对 docker 的 CRI 实现,也就是 kubelet 包下的dockershim包,dockershim是一个 grpc 服务,监听一个端口供 kubelet 连接,dockershim收到 kubelet 的请求后,将其转化为 REST API 请求,再发送给docker daemon。Kubernetes 项目之所以要在 kubelet 中引入这样一层单独的抽象,当然是为了对 Kubernetes 屏蔽下层容器运行时的差异。
![image.png](https://img-blog.csdnimg.cn/img_convert/1edc2d18b36868c9614a5d4b13f413ed.png#clientId=ubfa83de4-e122-4&from=paste&height=512&id=HKTqm&margin=[object Object]&name=image.png&originHeight=1024&originWidth=2436&originalType=binary&ratio=1&size=135204&status=done&style=none&taskId=u82f88702-9519-4448-a937-872aeaa02d8&width=1218)
解决思路再次体现了《代码大全2》里提到的那句经典名言:
any problem in computer science can be sloved by another layer of indirecition。计算机科学领域的任何问题都可以通过增加一个中间层来解决,我们的 CRI shim就是加了这样一层。
CRI shim server 接口图示
**CRI 接口包括 RuntimeService 和 ImageService 两个服务,这两个服务可以在一个 gRPC server 中实现,也可以分开成两个独立服务。**目前社区的很多运行时都是将其在一个 gRPC server 里面实现。
![image.png](https://img-blog.csdnimg.cn/img_convert/88f85851df0cd60dcc2f401951a363a7.png#clientId=u6f450f7d-9368-4&from=paste&height=606&id=fnxe3&margin=[object Object]&name=image.png&originHeight=1212&originWidth=2122&originalType=binary&ratio=1&size=181649&status=done&style=none&taskId=ud6e49e52-c0c8-4e34-95e3-f2415c38710&width=1061)
ImageServiceServer 提供了 5 个接口,用于管理容器镜像。
管理镜像的 ImageService 提供了 5 个接口:
- 查询镜像列表;
- 拉取镜像到本地;
- 查询镜像状态;
- 删除本地镜像;
- 查询镜像占用空间等。
关于容器镜像的操作比较简单,所以我们就暂且略过。接下来,我主要为你讲解一下 RuntimeService 部分。
RuntimeService 则提供了更多的接口,按照功能可以划分为四组:
- PodSandbox 的管理接口:CRI 设计的一个重要原则,就是确保这个接口本身,只关注容器,不关注 Pod。
- PodSandbox 是对 Kubernete Pod 的抽象,用来给容器提供一个隔离的环境(比如挂载到相同的 CGroup 下面),并提供网络等共享的命名空间。PodSandbox 通常对应到一个 Pause 容器或者一台虚拟机;
- Container 的管理接口:在指定的 PodSandbox 中创建、启动、停止和删除容器;
![image.png](https://img-blog.csdnimg.cn/img_convert/1da4627bd83d58049d645c75d9df443d.png#clientId=u7f106c04-82a1-4&from=paste&height=238&id=Zi9ok&margin=[object Object]&name=image.png&originHeight=475&originWidth=1080&originalType=binary&ratio=1&size=331757&status=done&style=none&taskId=ue02c5d23-ed18-4c3b-98b0-b3469381a40&width=540)
- Streaming API 接口:包括 Exec、Attach 和 PortForward 等三个和容器进行数据交互的接口,这三个接口返回的是运行时 Streaming Server 的 URL,而不是直接跟容器交互。kubelet 需要跟容器项目维护一个长连接来传输数据。这种 API,我们就称之为 Streaming API。
- 状态接口:包括查询 API 版本和查询运行时状态。
我们通过 kubectl 命令来运行一个 Pod,那么 Kubelet 就会通过 CRI 执行以下操作:
- 首先调用 RunPodSandbox 接口来创建一个 Pod 容器,Pod 容器是用来持有容器的相关资源的,比如说网络空间、PID空间、进程空间等资源;
- 然后调用 CreatContainer 接口在 Pod 容器的空间创建业务容器;
- 再调用 StartContainer 接口启动运行容器
- 最后调用停止,销毁容器的接口为 StopContainer 与 RemoveContainer。
就完成了整个Container的生命周期。
Streaming API
CRI shim 里对 Streaming API 的实现,依赖于一套独立的 Streaming Server 机制。Streaming API 用于客户端与容器进行交互,包括 Exec、PortForward 和 Attach 等三个接口。kubelet 内置的 Docker 通过 nsenter、socat 等方法来支持这些特性,但它们不一定适用于其他的运行时,也不支持 Linux 之外的其他平台。因而,CRI 也显式定义了这些 API,并且要求容器运行时返回一个 Streaming Server 的 URL 以便 kubelet 重定向 API Server 发送过来的流式请求。
![image.png](https://img-blog.csdnimg.cn/img_convert/a31402d825d4f98d9fee08efbd0688f4.png#clientId=u6abb2437-a6fd-4&from=paste&height=348&id=dRIkw&margin=[object Object]&name=image.png&originHeight=695&originWidth=1937&originalType=binary&ratio=1&size=147078&status=done&style=none&taskId=u2727d943-eecb-43a8-b6aa-a31ad63edcb&width=968.5)
因为所有容器的流式请求都会经过 kubelet,这可能会给节点的网络流量带来瓶颈,因而 CRI 要求容器运行时启动一
个对应请求的单独的流服务器,将地址返回给 kubelet。kubelet 将这个信息再返回给 Kubernetes API Server,会直接打开与运行时提供的服务器相连的流连接,并通过它与客户端连通。
这样一个完整的 Exec 流程就如上图所示,分为多个阶段:
- 客户端 kubectl exec -i -t …;
- kube-apiserver 向 kubelet 发送流式请求 /exec/;
- kubelet 通过 CRI 接口向 CRI Shim 请求 Exec 的 URL;
- CRI Shim 向 kubelet 返回 Exec URL;
- kubelet 向 kube-apiserver 返回重定向的响应;
- kube-apiserver 重定向流式请求到 Exec URL,然后将 CRI Shim 内部的 Streaming Server 跟 kube-apiserver 进行数据交互,完成 Exec 的请求和响应。
也就是说 apiserver 其实实际上是跟 streaming server 交互来获取我们的流式数据的。这样一来让我们的整个 CRI Server 接口更轻量、更可靠。
注意:当然,这个 Streaming Server 本身,是需要通过使用 SIG-Node 为你维护的 Streaming API 库来实现的。并且,Streaming Server 会在 CRI shim 启动时就一起启动。此外,Stream Server 这一部分具体怎么实现,完全可以由 CRI shim 的维护者自行决定。比如,对于 Docker 项目来说,dockershim 就是直接调用 Docker 的 Exec API 来作为实现的。
CRI-containerd架构解析与主要接口解析
![image.png](https://img-blog.csdnimg.cn/img_convert/5dd816ec1950eeb29da6638d74a35d19.png#clientId=u6b46695e-eb1c-4&from=paste&height=338&id=u2e9b7200&margin=[object Object]&name=image.png&originHeight=675&originWidth=1620&originalType=binary&ratio=1&size=218172&status=done&style=none&taskId=u18bd24b2-4b67-41dc-b8ac-8b4d6d3272b&width=810)
![image.png](https://img-blog.csdnimg.cn/img_convert/8344e052008131de4eb35099df361410.png#clientId=u7f106c04-82a1-4&from=paste&height=198&id=vwJx9&margin=[object Object]&name=image.png&originHeight=395&originWidth=1080&originalType=binary&ratio=1&size=225113&status=done&style=none&taskId=uf690d137-f035-4d9a-b4c9-da3ea33587c&width=540)
整个架构看起来非常直观。这里的 Meta services、Runtime service 与 Storage service 都是 containerd 提供的接口。它们是通用的容器相关的接口,包括镜像管理、容器运行时管理等。CRI 在这之上包装了一个 gRPC 的服务。右侧就是具体的容器的实现。比如说,创建容器时就要创建具体的 runtime 和它的containerd-shim。 Container 和 Pod Sandbox组成了一个Pod。
CRI-containerd 的一个好处是,containerd 还额外实现了更丰富的容器接口,所以它可以用 containerd 提供的 ctr 工具来调用这些丰富的容器运行时接口,而不只是 CRI 接口
CRI实现了两个GRPC协议的API,提供两种服务ImageService和RuntimeService。
// grpcServices are all the grpc services provided by cri containerd.
type grpcServices interface {
runtime.RuntimeServiceServer
runtime.ImageServiceServer
}
// CRIService is the interface implement CRI remote service server.
type CRIService interface {
Run() error
// io.Closer is used by containerd to gracefully stop cri service.
io.Closer
plugin.Service
grpcServices
}
CRI的实现CRIService中包含了很多重要的组件:其中最重要的是cni.CNI,用于配置容器网络。还有containerd.Client,用于连接containerd来创建容器。
// criService implements CRIService.
type criService struct {
// config contains all configurations.
config criconfig.Config
// imageFSPath is the path to image filesystem.
imageFSPath string
// os is an interface for all required os operations.
os osinterface.OS
// sandboxStore stores all resources associated with sandboxes.
sandboxStore *sandboxstore.Store
// sandboxNameIndex stores all sandbox names and make sure each name
// is unique.
sandboxNameIndex *registrar.Registrar
// containerStore stores all resources associated with containers.
containerStore *containerstore.Store
// containerNameIndex stores all container names and make sure each
// name is unique.
containerNameIndex *registrar.Registrar
// imageStore stores all resources associated with images.
imageStore *imagestore.Store
// snapshotStore stores information of all snapshots.
snapshotStore *snapshotstore.Store
// netPlugin is used to setup and teardown network when run/stop pod sandbox.
netPlugin cni.CNI
// client is an instance of the containerd client
client *containerd.Client
// streamServer is the streaming server serves container streaming request.
streamServer streaming.Server
// eventMonitor is the monitor monitors containerd events.
eventMonitor *eventMonitor
// initialized indicates whether the server is initialized. All GRPC services
// should return error before the server is initialized.
initialized atomic.Bool
// cniNetConfMonitor is used to reload cni network conf if there is
// any valid fs change events from cni network conf dir.
cniNetConfMonitor *cniNetConfSyncer
// baseOCISpecs contains cached OCI specs loaded via `Runtime.BaseRuntimeSpec`
baseOCISpecs map[string]*oci.Spec
}
我们知道 Kubernetes 的一个运作的机制是面向终态的,在每一次调协的循环中,Kubelet 会向 apiserver 获取调度到本 Node 的 Pod 的数据,再做一个面向终态的处理,以达到我们预期的状态。
循环的第一步,首先通过 List 接口拿到容器的状态。确保有镜像,如果没有镜像则 pull 镜像再通过 Sandbox 和 Container 接口来创建容器。
需要注意的是,我们的 CNI(容器网络接口)也是在 CRI 进行操作的,因为我们在创建 Pod 的时候需要同时创建网络资源然后注入到 Pod 中(PS:CNI包含在创建Pod 这个动作里)。接下来就是我们的容器和镜像。我们通过具体的容器创建引擎来创建一个具体的容器。
执行流程为:
- Kubelet 通过 CRI runtime service API 调用 CRI plugin 创建 pod
- CRI 通过 CNI 创建 pod 的网络配置和 namespace
- CRI使用 containerd 创建并启动 pause container (sandbox container) 并且把这个 container 置于 pod 的 cgroups/namespace
- Kubelet 接着通过 CRI image service API 调用 CRI plugin, 获取容器镜像
- CRI 通过 containerd 获取容器镜像
- Kubelet 通过 CRI runtime service API 调用 CRI, 在 pod 的空间使用拉取的镜像启动容器
- CRI 通过 containerd 创建/启动 应用容器, 并且把 container 置于 pod 的 cgroups/namespace. Pod 完成启动。
ctr命令行工具初始用
打印服务端和客户端版本:
# ctr version
Client:
Version: v1.4.4
Revision: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
Go version: go1.15.8
Server:
Version: v1.4.4
Revision: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
UUID: dee82270-b4b4-429c-befa-45df1421da7e
pull docker hub中的redis镜像:
# pull镜像
ctr images pull docker.io/library/redis:alpine3.13
# 查看镜像
ctr i ls
pull私有仓库的镜像,需要使用-u :给定镜像仓库的用户名和密码:
ctr images pull -u user:password harbor.my.org/library/nginx:1.1
启动这个测试的redis容器:
ctr run -d docker.io/library/redis:alpine3.13 redis
查看容器(container和task):
ctr container ls
CONTAINER IMAGE RUNTIME
redis docker.io/library/redis:alpine3.13 io.containerd.runc.v2
ctr task ls
TASK PID STATUS
redis 20808 RUNNING
注意: 在containerd中,container和task是分离的,container描述的是容器分配和附加资源的元数据对象,是静态内容,task是任务是系统上一个活动的、正在运行的进程。 task应该在每次运行后删除,而container可以被多次使用、更新和查询。这点和docker中container定义是不一样的。
进入到容器中执行redis命令:
ctr task exec -t --exec-id redis-sh redis sh
/data # redis-cli
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> get k1
"v1"
查看一下系统中的进程信息:
ps -ef | grep runc | grep redis
/usr/local/containerd/bin/containerd-shim-runc-v2 -namespace default -id redis -address /run/containerd/containerd.sock
可以看出containerd中是存在namespace概念的,这样可以将不同业务和应用进行隔离,例如k8s使用containerd和直接使用ctr创建的容器可以隔离开。查看一下当前的namespace:
ctr ns ls
NAME LABELS
default
k8s.io
不同namespace下pull的镜像也是隔离显示的,可以使用-n指定具体的namespace:
ctr -n default i ls
ctr -n k8s.io i ls
crictl命令行工具配置和初始用
crictl是k8s cri-tools的一部分,它提供了类似于docker的命令行工具,不需要kubelet就可以通过CRI跟容器运行时通信。 crictl是专门为k8s设计的,提供了Pod、容器和镜像等资源的管理命令,可以帮助用户调试容器应用或者排查异常问题。 crictl 可以用于所有实现了CRI接口的容器运行时。可以排查常见的PLEG的问题。
尝试使用ctictl命令行工具查看一下镜像,给了一个警告信息:
crictl images
WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock]. As the default settings are now deprecated, you should set the endpoint instead.
ERRO[0002] connect endpoint 'unix:///var/run/dockershim.sock', make sure you are running as root and the endpoint has been started: context deadline exceeded
IMAGE TAG IMAGE ID SIZE
需要我们显示配置默认的endpoints:
crictl config runtime-endpoint unix:///run/containerd/containerd.sock
crictl config image-endpoint unix:///run/containerd/containerd.sock
上面的命令执行完成后将生成配置文件/etc/crictl.yaml:
runtime-endpoint: "unix:///run/containerd/containerd.sock"
image-endpoint: "unix:///run/containerd/containerd.sock"
timeout: 0
debug: false
pull-image-on-create: false
disable-pull-on-run: false
pull镜像:
crictl pull docker.io/library/redis:alpine3.13
crictl images
IMAGE TAG IMAGE ID SIZE
docker.io/library/redis alpine3.13 554d20f203657 10.9MB
crictl pull的镜像实际上是在k8s.io namespace下,可以使用ctr -n k8s.io i ls查看。
crictl不能像ctr那样通过参数给定用户名和密码的方式从开启认证的私有仓库中pull镜像。需要对containerd进行配置。 containerd提供的各种功能在其内部都是通过插件实现的,可以使用ctr plugins ls查看containerd的插件:
ctr plugins lsTYPE ID PLATFORMS STATUS
io.containerd.content.v1 content - ok
io.containerd.snapshotter.v1 aufs linux/amd64 error
io.containerd.snapshotter.v1 btrfs linux/amd64 error
io.containerd.snapshotter.v1 devmapper linux/amd64 error
io.containerd.snapshotter.v1 native linux/amd64 ok
io.containerd.snapshotter.v1 overlayfs linux/amd64 ok
io.containerd.snapshotter.v1 zfs linux/amd64 error
io.containerd.metadata.v1 bolt - ok
io.containerd.differ.v1 walking linux/amd64 ok
io.containerd.gc.v1 scheduler - ok
io.containerd.service.v1 introspection-service - ok
io.containerd.service.v1 containers-service - ok
io.containerd.service.v1 content-service - ok
io.containerd.service.v1 diff-service - ok
io.containerd.service.v1 images-service - ok
io.containerd.service.v1 leases-service - ok
io.containerd.service.v1 namespaces-service - ok
io.containerd.service.v1 snapshots-service - ok
io.containerd.runtime.v1 linux linux/amd64 ok
io.containerd.runtime.v2 task linux/amd64 ok
io.containerd.monitor.v1 cgroups linux/amd64 ok
io.containerd.service.v1 tasks-service - ok
io.containerd.internal.v1 restart - ok
io.containerd.grpc.v1 containers - ok
io.containerd.grpc.v1 content - ok
io.containerd.grpc.v1 diff - ok
io.containerd.grpc.v1 events - ok
io.containerd.grpc.v1 healthcheck - ok
io.containerd.grpc.v1 images - ok
io.containerd.grpc.v1 leases - ok
io.containerd.grpc.v1 namespaces - ok
io.containerd.internal.v1 opt - ok
io.containerd.grpc.v1 snapshots - ok
io.containerd.grpc.v1 tasks - ok
io.containerd.grpc.v1 version - ok
io.containerd.grpc.v1 cri linux/amd64 ok
私有镜像仓库相关的配置在cri插件中,文档Configure Image Registry中包含了镜像仓库的配置。 关于私有仓库和认证信息配置示例如下,修改/etc/containerd/config.toml:
...
[plugins]
...
[plugins."io.containerd.grpc.v1.cri"]
...
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."harbor.my.org"]
endpoint = ["https://harbor.my.org"]
[plugins."io.containerd.grpc.v1.cri".registry.configs]
[plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.my.org".tls]
insecure_skip_verify = true
[plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.my.org".auth]
username = "username"
password = "passwd"
# auth = "base64(username:password)"
...
配置完成后重启containerd,就可以使用crictl pull配置的私有仓库的镜像了:
crictl pull harbor.my.org/library/nginx:1.1
reference
https://time.geekbang.org/column/article/71499?utm_campaign=guanwang&utm_source=baidu-ad&utm_medium=ppzq-pc&utm_content=title&utm_term=baidu-ad-ppzq-title
https://blog.frognew.com/2021/04/relearning-container-02.html
https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md
[
](https://time.geekbang.org/column/article/71499?utm_campaign=guanwang&utm_source=baidu-ad&utm_medium=ppzq-pc&utm_content=title&utm_term=baidu-ad-ppzq-title)