譯自：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）。
供參考，請參閱更新的容器建立流程圖：