笔记

Kubernetes与CRI

kubelet是node上最核心的组件，对上负责与Master通信，对下负责与容器运行时通信，负责容器的生命周期管理、容器网络、容器存储能力建设。

1. 通过CRI与各种容器运行时通信，管理容器生命周期
2. 通过CNI与容器网络插件通信，负责集群网络的管理
3. 通过CSI与容器存储插件通信，负责集群内容器存储资源的管理

CRI 概述

CRI定义了容器和镜像服务的接口，该接口基于gRpc，使用Protocol Buffer协议。该接口定义了kubelet与不同容器运行时交互的规范，接口包含客户端CRI Client与服务端CRI Server。其中CRI Server作为服务端，监听在本地的unix socket上，kubelete中含有CRI Client，作为客户端通过gRpc与CRI Server交互。CRI Server还负责容器网络配置，不一定强制使用CNI，只不过使用CNI规范可以与K8s网络模型保持一直，从而支持社区众多的网络插件。

RuntimeServer

RuntimeServer主要负责pod及container生命周期的管理，包括四大类。

1. PodSandbox管理：和k8s的Pod一一对应，主要为pod运行提供一个隔离环境，并准备该pod运行所需要的网络基础设施。在runc场景下对应一个pause容器
2. container管理：用于在上述Sandbox中管理容器的生命周期，如创建、启动、销毁容器。该接口属于容器粒度的接口。
3. Streaming API：该接口主要用于kubelet进行Exec、Attach、PortForward交互，该类接口返回给kubelet的是Streaming Server的Endpoint，用于接收后续kubelet的Exec、Attach、PortForward请求。
4. Runtime API：主要是查询该CRI Server的状态，如CRI、CNI状态，以及更新Pod CIDR配置等。该接口属于Node粒度的接口。

ImageService

ImageService相对比较简单，主要是运行容器所需的几个镜像的接口，如拉取镜像、删除镜像、查询镜像信息、查询镜像列表，以及查询镜像文件系统信息等。注意，镜像接口没有推送镜像功能，因为容器运行只需要将镜像拉到本地即可，推送镜像并部署CRI Server必须的能力。

containerd 与 CRI Plugin

CRI Plugin是k8s容器运行时接口CRI的具体实现，内置在containerd中，作为containerd的原生插件默认开启。这个插件实现了CRI中的Image Service和RuntimeService，其架构如下图所示。

1. Image Service和RuntimeService通过containerd Client SDK调用containerd接口来管理容器和镜像
2. RuntimeService通过CNI插件给pod配置容器网络
3. go-cni为containerd封装的调用CNI插件的go代码库

下面通过一个单容器的pod举例说明pod启动时CRI Plugin的工作流程

1. kubelet 通过CRI调用CRI Plugin中的RunSandbox API，创建pod对应的Sandbox环境
2. 创建Pod Sanbox时，会创建pod的网络命名空间，然后通过CNI配置容器网络；之后会为Sandbox创建并启动一个特殊的容器，即Pause容器，然后将该容器加入上述的网络命名空间。
3. 之后，调用ImageService API 拉取容器镜像；如果容器不存在于本地，会调用containerd的接口去拉取镜像
4. kubelet 利用刚刚拉取的镜像调用RuntimeService API，在Pod Sandbox中创建并启动容器。
5. CRI Plugin最终通过containerd client sdk调用containerd的接口创建容器，并在pod所在的Cgroup和namespace中启动容器

容器网络接口CNI

CNI概述

CNI 作为一个统一的接口层，提出了一种基于插件的通用网络解决方案。采用CNI规范的运行时无需关注网络的使用具体细节，只需要按照CNI规范来调用即可实现容器的网络配置

为了清洗的阐述，CNI规范定义了如下的几个术语

1. 容器：是一个独立的网络隔离域，可以是一个Linux network namespace，或者一台虚拟机
2. 网络：是一组具有唯一地址且可以相互通信的实体的集合。这些实体可以是一个单独的容器、一台虚拟机，或者一台路由器等。容器可以加入一个或多个网络，也可以从一个或多个网络中移除
3. CNI插件：执行特定网络配置功能的程序
4. 容器运行时：负责调用CNI插件

containerd 数据存储

容器镜像

Dockerfile中的一些命令会生成一个镜像层，在镜像中所有的镜像层都是只读的。当容器运行时使用该镜像创建容器时，会在该镜像添加一层可写层，所有容器中的修改操作都会反映到可写层上。

存储目录
root = /var/lib/containerd
state = /run/containerd

1. root目录：/var/lib/containerd，主要存储containerd中的持久化数据，一些插件的信息也会被保存早这个目录中。root目录中的内容是根据namespace隔离的。对于containerd加载的插件，每个插件都有自己的目录来保存数据。containerd本身不具备保存数据的能力，都是插件保存的
2. state目录：/run/containerd，主要存储多种类型的临时数据，如socket、pid、运行时状态、挂载的信息等。还会存储一些其他插件保存的数据，这些数据机器重启时无需保留。