K8S CNI CRI CSI

在Kubernetes（K8s）生态系统中，CNI（Container Networking Interface）、CRI（Container Runtime Interface）和CSI（Container Storage Interface）是三个关键的接口，它们分别负责容器网络、容器运行时和容器存储的管理。

1. CNI（Container Networking Interface）

概念：
CNI是一个标准，用于定义容器应如何在网络层面进行交互和通信。它指定了一系列网络配置和接口，容器运行时可以通过这些接口为容器配置网络。
作用：
CNI使得Kubernetes可以无缝集成各种网络解决方案，如Weave、Calico、Flannel、Cilium等。这些网络解决方案可以提供Pod网络、服务发现、负载均衡等功能。
工作原理：
当Pod被创建或删除时，Kubernetes会调用配置的CNI插件来分配或回收网络资源，如IP地址。CNI插件负责设置Pod的网络命名空间、创建网络接口和设置路由规则等。

作用

1. 网络配置：CNI插件负责在容器启动时为其分配网络资源，如IP地址、网络命名空间、网络接口等。这些配置确保了容器能够正确地与其他容器、Pods、服务以及外部网络进行通信。
2. 网络隔离：通过为每个Pod分配独立的网络命名空间，CNI帮助实现了网络隔离。这种隔离保证了Pod之间的网络通信是安全的，并且每个Pod都可以拥有自己的网络堆栈。
3. 网络策略：一些CNI插件还支持网络策略的实施，允许管理员定义哪些Pod可以相互通信，哪些端口应该被暴露给外部网络等。这有助于增强集群的安全性。
4. 服务发现：虽然CNI本身不直接负责服务发现，但它通过为Pods提供稳定的网络标识（如IP地址）来支持服务发现机制。这使得Pods能够相互发现并进行通信。

CNI 插件

Kubernetes社区和第三方供应商提供了多种CNI插件，以满足不同的网络需求。一些流行的CNI插件包括：

• Calico：一个开源的、高度可扩展的网络和网络安全解决方案，提供了丰富的网络策略功能。
• Flannel：一个简单的覆盖网络（overlay network）解决方案，它通过封装UDP或VXLAN等协议来跨节点传输容器间的流量。
• Weave Net：一个基于加密的、快速的多主机容器网络，提供了自动的网络连接、加密和主机间通信优化。
• Cilium：一个基于BPF（Berkeley Packet Filter）和XDP（eXpress Data Path）的开源CNI插件，提供了高性能的网络、安全性和可见性。

CNI 的工作原理

当Kubernetes创建一个新的Pod时，它会通过CNI插件来配置Pod的网络。这个过程通常包括以下几个步骤：

1. Pod创建：Kubernetes API服务器接收到Pod的创建请求后，将其存储在etcd中，并通知kubelet进行实际的Pod创建。
2. 调用CNI插件：kubelet在节点上调用配置的CNI插件，并传递Pod的元数据和规格信息。
3. 网络配置：CNI插件根据Pod的信息和插件的配置，为其分配网络资源，并设置必要的网络接口和路由规则。
4. Pod启动：一旦网络配置完成，kubelet就会启动Pod中的容器，并使它们能够通过网络进行通信。

操作

CNI插件的操作类型只有四种：ADD，DEL，CHECK和VERSION。插件调用者通过环境变量CNI_COMMAND来指定需要执行的操作。
接口定义：

type CNI interface {
    AddNetworkList (net *NetworkConfigList, rt *RuntimeConf) (types.Result, error)
    DelNetworkList (net *NetworkConfigList, rt *RuntimeConf) error
    AddNetwork (net *NetworkConfig, rt *RuntimeConf) (types.Result, error)
    DelNetwork (net *NetworkConfig, rt *RuntimeConf) error
}

1. ADD
   描述：
   当Kubernetes创建一个新的Pod时，CNI插件会被调用以执行ADD操作。这个操作负责为Pod配置网络，包括创建网络命名空间、分配IP地址、设置路由规则、配置网络设备等。
   流程：

• 接收来自kubelet的ADD请求，该请求包含了Pod的ID、网络命名空间路径、CNI配置文件名等信息。
• 读取CNI配置文件，解析出网络配置参数。
• 根据配置参数，为Pod创建并配置网络命名空间。
• 分配IP地址给Pod，并确保该地址在集群中是唯一的。
• 设置必要的路由规则，确保Pod能够与其他容器、Pods、服务以及外部网络进行通信。
• 配置网络设备（如veth pair、网桥等），以实现Pod间的网络连接。
• 返回网络配置的结果给kubelet，包括分配的IP地址、子网掩码、网关等信息。

2. DEL
   描述：
   当Kubernetes销毁一个Pod时，CNI插件会被调用以执行DEL操作。这个操作负责清理与该Pod关联的网络资源，确保不会留下任何无用的网络配置或设备。
   流程：

• 接收来自kubelet的DEL请求，该请求包含了Pod的ID和网络命名空间路径等信息。
• 根据Pod的ID和网络命名空间路径，找到并清理与该Pod关联的网络配置和设备。
• 释放Pod的IP地址，将其返回给IP池或进行其他处理。
• 删除为该Pod创建的网络命名空间（如果配置允许）。
• 返回操作结果给kubelet，通常是一个表示成功或失败的状态码。

3. CHECK（可选）
   描述：
   CHECK操作是可选的，但一些CNI插件支持此操作以验证网络配置的正确性。它在ADD操作后执行，用于检查网络配置是否按预期设置。
   流程：

• 接收来自kubelet的CHECK请求，该请求包含了Pod的ID和网络命名空间路径等信息。
• 根据Pod的ID和网络命名空间路径，验证网络配置是否正确。
• 返回验证结果给kubelet，通常是一个表示配置是否正确的状态码或错误信息。

4. VERSION（信息性，非配置操作）
   虽然VERSION操作不直接涉及网络配置或清理，但它对于插件的兼容性和调试非常有用。
   描述：
   VERSION操作允许kubelet或用户查询CNI插件的版本信息。这对于确保插件与Kubernetes版本兼容或进行故障排除非常有帮助。
   流程：

• 接收来自kubelet或用户的VERSION请求。
• 返回插件的版本信息给请求者。

2. CRI（Container Runtime Interface）

概念：
CRI是Kubernetes用来与容器运行时进行交互的标准接口。它定义了一套RPC（远程过程调用）API，这些API被用来管理容器的生命周期。
作用：
CRI使得Kubernetes能够支持多种容器运行时，如Docker、containerd、CRI-O等。这提高了系统的灵活性，允许用户根据自己的需要选择合适的容器运行时。
工作原理：
Kubelet通过CRI与容器运行时进行通信，包括容器的启动、停止、状态查询等操作。CRI将这些操作转换成容器运行时能够理解的命令和调用。
历史背景：
在Kubernetes的早期版本中，对于容器环境的支持是通过Dockershim（hard code）方式直接调用Docker API的。后来为了支持更多的容器运行时和更精简的容器运行时，Kubernetes在遵循OCI（Open Container Initiative）基础上提出了CRI。2020年，Kubernetes宣布弃用dockershim，标志着容器运行时正式向CRI切换，以满足对更多Runtime的支持，提高Kubernetes生态的开放性和扩展性。

概述

• 定义：CRI是Kubernetes定义的一组与容器运行时进行交互的接口，它充当kubelet和容器运行时之间的桥梁。
• 引入时间：CRI在Kubernetes 1.5中引入，旨在提高Kubernetes生态的开放性和扩展性。
• 作用：通过CRI，Kubernetes可以支持多种容器运行时，而无需直接依赖于特定的容器技术（如Docker）。

组成

CRI接口主要由两部分组成：

• RuntimeService：负责容器的生命周期管理，包括容器的创建、启动、停止、删除等操作。这些操作通过RuntimeServiceServer属性来描述。
• ImageService：负责容器镜像的管理，包括镜像的拉取、推送、删除等操作。这些操作通过ImageServiceServer属性来描述。

实现

目前，已经实现了CRI spec的Runtime包括DockerEngine、containerd、CRI-O、Mirantis Container Runtime（Docker企业版）等。这些运行时通过提供CRI接口的实现，使得kubelet能够与之交互，从而管理容器和镜像。

• DockerEngine：早期Kubernetes通过dockershim直接与Docker API交互，但随着Kubernetes的发展，dockershim被逐渐废弃，并推荐使用其他实现了CRI的容器运行时。
• containerd：由Docker公司创建并捐赠给CNCF的容器运行时，是目前使用最广泛的CRI实现之一。
• CRI-O：基于OCI（Open Container Initiative）标准开发的独立容器管理引擎，专注于在Kubernetes中运行容器，具有较好的独立性和兼容性。

优势

1. 解耦：通过CRI，Kubernetes与容器运行时之间实现了解耦，使得Kubernetes能够支持多种容器运行时。
2. 扩展性：CRI的标准化接口使得生态圈中的开发者能够按照CRI spec实现自己的运行时插件，从而提供个性化的运行时扩展能力。
3. 维护性：将kubelet核心主干代码与Runtime相关代码解耦，有助于降低维护成本和提高系统的稳定性。

接口

1. 容器生命周期管理
   RuntimeService提供的操作：

• 创建容器：kubelet通过CRI请求容器运行时创建一个新的容器实例。这通常涉及准备容器的运行环境，如分配必要的资源、配置网络等。
• 启动容器：在容器被创建后，kubelet通过CRI请求容器运行时启动该容器。启动容器意味着将容器的进程启动起来，并使其开始执行。
• 停止容器：当容器不再需要时，kubelet通过CRI请求容器运行时停止该容器。停止容器会优雅地关闭容器内的进程，并释放占用的资源。
• 删除容器：kubelet通过CRI请求容器运行时删除指定的容器实例。删除容器会移除与容器相关的所有资源，包括文件系统、网络配置等。
• 查询容器状态：kubelet可以通过CRI请求容器运行时提供容器的当前状态信息，以便进行监控和管理。状态信息可能包括容器的运行状态、资源使用情况等。

2. 镜像管理
   ImageService提供的操作：

• 拉取镜像：当需要运行一个容器时，如果本地没有该容器的镜像，kubelet会通过CRI请求容器运行时从远程仓库拉取镜像。拉取镜像涉及下载镜像文件并存储到本地。
• 查看镜像列表：kubelet可以通过CRI请求容器运行时提供当前已拉取的镜像列表。这有助于了解本地可用的镜像资源。
• 删除镜像：当镜像不再需要时，kubelet可以通过CRI请求容器运行时删除指定的镜像。删除镜像会移除与镜像相关的文件和数据。

3. PodSandbox管理
   RuntimeService提供的操作：

• 创建PodSandbox：在启动Pod之前，kubelet会通过CRI请求容器运行时创建一个PodSandbox。PodSandbox为Pod中的容器提供隔离的环境，包括网络、存储等资源。
• 停止和删除PodSandbox：当Pod被删除时，kubelet会通过CRI请求容器运行时停止并删除PodSandbox。这包括停止PodSandbox中的所有容器并释放占用的资源。
• 查询PodSandbox状态：kubelet可以通过CRI请求容器运行时提供PodSandbox的当前状态信息。状态信息可能包括PodSandbox的运行状态、资源分配情况等。

3. CSI（Container Storage Interface）

概念：
CSI是一个标准接口，用于将外部存储系统（如云提供商的存储服务或本地存储系统）连接到Kubernetes中。它定义了一套标准的API，用于容器和存储系统之间的交互。
作用：
通过CSI，Kubernetes用户可以使用各种存储解决方案，而无需等待Kubernetes本身去集成这些解决方案。这大大加快了新存储技术的采用速度，并使得存储解决方案的提供者能够更快地向市场推出他们的产品。
工作原理：
当Kubernetes需要挂载存储卷到Pod上时，它会调用CSI插件来创建、配置和挂载卷。同样地，当卷不再需要时，CSI插件会负责卸载卷并执行必要的清理工作。
架构：
Kubernetes CSI的架构包括两个主要组件：CSI驱动程序和CSI节点插件。CSI驱动程序是一个独立的进程，负责与Kubernetes API交互，并处理存储插件的请求。CSI节点插件则是在每个节点上运行的进程，它将容器请求映射到CSI驱动程序，并与容器运行时一起管理存储。

概述

• 定义：CSI是Kubernetes中用于容器编排系统与外部存储系统交互的标准化接口。
• 目的：允许第三方存储提供商开发符合标准的插件，以便这些存储解决方案能够无缝集成到Kubernetes集群中，为Pod提供持久化存储服务。

架构与组件

• CSI Driver：由存储供应商提供的一个或一组守护进程，实现了CSI规范定义的一系列接口。这些接口涵盖了从创建、挂载、卸载到删除卷等一系列操作，确保Kubernetes可以通过CSI Driver与底层存储系统进行通信。
  • 控制器插件：负责处理集群层面的存储管理操作，如动态配置PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 对象，以及根据需要调整存储资源。
  • 节点插件：运行在每个工作节点上，负责处理与本地节点相关的存储任务，如格式化、挂载和卸载存储卷，确保数据能被Pod访问或安全地释放。
• CSI Identity服务：提供驱动程序的信息，如版本号、名称和支持的功能列表等。

功能与操作

• 卷生命周期管理：
  • CreateVolume：根据请求创建一个新的存储卷。
  • DeleteVolume：当不再需要时，删除指定的存储卷。
  • ControllerPublishVolume和NodeStageVolume：将存储卷发布给特定节点，并准备其挂载点。
  • NodePublishVolume：实际在节点上挂载存储卷到Pod中。
  • ControllerUnpublishVolume、NodeUnstageVolume和 NodeUnpublishVolume：在不使用时，执行反向操作来卸载并释放存储资源。
• 外部组件：
  • Driver Registrar：负责将插件注册到kubelet中。
  • External Provisioner：负责Provision供应阶段，即调用External Persistent Storage的API来分配存储。
  • External Attacher：负责Attach附加物阶段，即将存储绑定到Node节点上。

优势与影响

• 灵活性：通过CSI，Kubernetes用户可以灵活地选择和部署各种兼容的存储解决方案，而无需担心与容器编排系统的集成问题。
• 可扩展性：存储供应商可以更容易地将其产品推广到Kubernetes生态系统中，同时保持其产品的独立性和更新能力。
• 标准化：CSI标准的引入促进了存储插件的标准化，降低了存储插件的开发和维护成本。

应用与部署

• 编写CSI插件：存储供应商需要编写符合CSI规范的插件代码，包括控制器插件和节点插件的实现。
• 部署CSI插件：将编写好的CSI插件部署到Kubernetes集群中，并确保插件可以正常运行。
• 配置StorageClass和PVC：创建StorageClass来定义存储类别和CSI插件名称等信息，然后创建PersistentVolumeClaim来请求存储资源。