Kuryr kubernetes 流程图

译自：https://docs.openstack.org/kuryr-kubernetes/latest/devref/kuryr_kubernetes_design.html#cni-daemon

Kuryr kubernetes集成利用了kubernetes CNI插件，并引入了Kuryr-K8s CNI驱动程序。基于设计决定，kuryr-kubernetes CNI Driver应该通过kubernetes控制平面获取所有需要的信息，以便连接和绑定Pod，而不应该依赖于Neutron。 CNI插件/驱动程序由kubelet（Kubernetes节点代理程序）以阻塞方式调用，因此，当成功或错误状态确定时，它将返回。

Kuryr-K8s CNI驱动程序有两个Pod绑定信息源：kubelet /节点环境和Kubernetes API。 Kuryr-K8s控制器服务和CNI共享定义了控制器服务器添加和CNI驱动程序读取的Pod注释的协议。该协议是os_vif VIF

从Pod对象注释加载VIF对象后，CNI驱动程序将执行Pod插入。 Kuryr-K8s CNI驱动程序使用ov_vif库执行Pod插入和拔出操作。 CNI驱动程序应完成其作业，并在所有网络插接完成后将控制权返回给Kubelet。在Neutron最初创建端口处于“停止”状态的情况下，CNI驱动程序将插入Pod，但必须在将控制权返回给调用者之前，将Pod注释的vif状态更改为“激活”。

CNI守护程序是应该在每个Kubernetes节点上运行的可选服务。它负责监视正在运行的节点上的pod事件，应对来自CNI驱动程序的调用并在准备好时附加VIF。将来它还将保存关于内存池中的信息。这有助于限制创建多个Pod时产生的进程数量，因为对于每个节点，单个Watcher就足够了，CNI Driver只会在本地网络套接字上等待守护进程的响应。

(如果多个pod同时启动，导致多个CNI插件启动，而且这些CNI插件同时watch k8sAPI, 导致资源浪费。将watch 功能从CNI抽离出来，移到守护进程可以解决这个问题)

目前CNI守护进程由两个进程组成，即Watcher和Server。进程使用Python的multiprocessing.Manager和一个共享字典对象相互通信。 Watcher负责从Pod事件中提取VIF注释并将其放入共享字典中。服务器是一个常规的WSGI服务器，它将回答CNI驱动程序调用。当CNI请求到来时，Server正在等待VIF对象出现在共享字典中。由于注释是从kubernetes API读取的，并通过Watcher线程添加到注册表中，因此Server最终将获得它需要连接到给定Pod的VIF。然后等待VIF在返回到CNI驱动程序之前变为活动状态。

CNI守护程序服务器正在本地网络套接字上启动HTTP服务器（默认为127.0.0.1:50036）。目前服务器正在侦听2个API调用。这两个调用都会从调用的主体中加载CNIParameters（预计会是JSON）。

供参考，请参阅更新的容器创建流程图：