kubernetes|【Kubernetes的开放接口】 rpc|java|网络|运维

Kubernetes作为云原生应用的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下三个接口，可以分别对接不同的后端，来实现自己的业务逻辑。

文章图片

CRI（Container Runtime Interface）：容器运行时接口，提供计算资源
CNI（Container Network Interface）：容器网络接口，提供网络资源
CSI（Container Storage Interface）：容器存储接口，提供存储资源

1.CRI - Container Runtime Interface（容器运行时接口） CRI中定义了容器和镜像的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务 —— RuntimeService和 ImageService 。

RuntimeService：容器和Sandbox运行时管理。
ImageService：提供了从镜像仓库拉取、查看、和移除镜像的RPC。

Container Runtime实现了CRI gRPC Server，CRI接口包含了上边两个gRPC服务， gRPC Server需要监听本地的Unix socket，而kubelet则作为gRPC Client运行。

gRPC，其实就是RPC框架的一种，RPC 框架就是让你可以像调用本地方法一样调用远程服务提供的方法，而不需要关心底层的通信细节。简单地说就让远程服务调用更加简单、透明。 RPC包含了客户端（Client）和服务端（Server）。
gRPC前面带了一个g，是一个高性能、开源和通用的 RPC 框架，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。面向服务端和移动端，基于 HTTP/2 设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。

文章图片

启用CRI 除非集成了rktnetes，否则CRI都是被默认启用了，从Kubernetes1.7版本开始，旧的预集成的docker CRI已经被移除
要想启用CRI只需要在kubelet的启动参数重传入参数： --container-runtime-endpoint远程运行时服务的端点。Linux上支持unix socket，windows上支持tcp。例如： unix:///var/run/dockershim.sock、tcp://localhost:373，默认是 unix:///var/run/dockershim.sock，即默认使用本地的docker作为容器运行时。
支持的CRI后端从Kubernetes 1.5开始已经开始支持CRI ，通过CRI接口可以指定使用其它容器运行时作为Pod的后端，目前支持 CRI 的后端有：

cri-o：同时兼容OCI和CRI的容器运行时
cri-containerd：基于 Containerd的Kubernetes CRI 实现
rkt：由CoreOS主推的用来跟docker抗衡的容器运行时
frakti：基于hypervisor的CRI
docker：kuberentes最初就开始支持的容器运行时，目前还没完全从kubelet中解耦，docker公司同时推广了 OCI标准
Clear Containers：由Intel推出的同时兼容OCI和CRI的容器运行时
Kata Containers：符合OCI规范同时兼容CRI
gVisor：由谷歌推出的容器运行时沙箱(Experimental)

2.CNI - Container Network Interface（容器网络接口） CNI（Container Network Interface）是CNCF旗下的一个项目，由一组用于配置Linux容器的网络接口的规范和库组成，同时还包含了一些插件。 CNI仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。
kubernetes中已经内置了CNI。
CNI接口只有四个方法，添加网络、删除网络、添加网络列表、删除网络列表。
CNI插件 CNI插件必须实现一个可执行文件，这个文件可以被容器管理系统调用。
CNI插件负责将网络接口插入容器网络命名空间，并在主机上进行任何必要的改变（例如将veth的另一端连接到网桥）。然后将IP分配给接口，并通过调用适当的IPAM插件来设置与“IP地址管理”部分一致的路由。
CNI插件必须支持以下操作：

将容器添加到网络
从网络中删除容器
IP分配

作为容器网络管理的一部分，CNI插件需要为接口分配（并维护）IP地址，并安装与该接口相关的所有必要路由。这给了CNI插件很大的灵活性，但也给它带来了很大的负担。为了减轻负担，使IP管理策略与CNI插件类型解耦，我们定义了 IP地址管理插件（IPAM插件）。CNI插件的职责是在执行时恰当地调用IPAM插件。 IPAM插件必须确定接口IP/subnet，网关和路由，并将此信息返回到“主”插件来应用配置。
IPAM插件---IP地址管理插件
像CNI插件一样，调用IPAM插件的可执行文件。可执行文件位于预定义的路径列表中，通过 CNI_PATH指示给CNI插件。 IPAM插件必须接收所有传入CNI插件的相同环境变量。就像CNI插件一样，IPAM插件通过stdin接收网络配置。
可用插件 Main：接口创建

bridge：创建网桥，并添加主机和容器到该网桥
ipvlan：在容器中添加一个 ipvlan接口
loopback：创建一个回环接口
macvlan：创建一个新的MAC地址，将所有的流量转发到容器
ptp：创建veth对
vlan：分配一个vlan设备

IPAM：IP地址分配

dhcp：在主机上运行守护程序，代表容器发出DHCP请求
host-local：维护分配IP的本地数据库

Meta：其它插件

flannel：根据flannel的配置文件创建接口
tuning：调整现有接口的sysctl参数
portmap：一个基于iptables的portmapping插件。将端口从主机的地址空间映射到容器。

3.CSI - Container Storage Interface（容器存储接口） CSI 代表容器存储接口，CSI 试图建立一个行业标准接口的规范，借助 CSI 容器编排系统（CO）可以将任意存储系统暴露给自己的容器工作负载。
csi 卷类型是一种 out-tree（即跟其它存储插件在同一个代码路径下，随 Kubernetes 的代码同时编译的）的 CSI 卷插件，用于 Pod 与在同一节点上运行的外部 CSI 卷驱动程序交互。部署 CSI 兼容卷驱动后，用户可以使用csi 作为卷类型来挂载驱动提供的存储。
CSI 持久化卷支持是在 Kubernetes v1.9 中引入的，作为一个 alpha 特性，必须由集群管理员明确启用。换句话说，集群管理员需要在 apiserver、controller-manager 和 kubelet 组件的 “ --feature-gates =” 标志中加上 “ CSIPersistentVolume = true”。
【kubernetes|【Kubernetes的开放接口】】CSI 持久化卷具有以下字段可供用户指定：

driver：一个字符串值，指定要使用的卷驱动程序的名称。必须少于 63 个字符，并以一个字符开头。驱动程序名称可以包含 “。”、“ - ”、“_” 或数字。
volumeHandle：一个字符串值，唯一标识从 CSI 卷插件的CreateVolume 调用返回的卷名。随后在卷驱动程序的所有后续调用中使用卷句柄来引用该卷。
readOnly：一个可选的布尔值，指示卷是否被发布为只读。默认是 false。