Cisco思科網絡插件Contiv (三) Plugin 實現原理

Contiv網絡結構

上圖爲Contiv的網絡模型，大致上可分爲Master和Host Agent兩個組件,其中Plugin運行在每臺宿主機上, 主要負責1. 與Container Runtime交互實現插件邏輯. 2. 配置底層 open vswitch進程實現具體的網絡功能.

Contiv-Plugin組件

Plugin Logic

Plugin Logic 是與Container Runtime交互的核心邏輯, 以經常使用的 docker 爲例, 該邏輯便是實現CNM框架下所規定的種種接口, 實現與Libnetwork的消息交互, 關於CNM和Libnetwork, 請查看Libnetwork與CNM框架與實現

Distributed KV Store

同 Master 中的做用同樣, 下文將以etcd表示該數據庫

Linux Host Routing/Switching

待完成

ARP/DNS Responder

待完成

Service LB

待完成

Route Distribution

待完成

Contiv-Plugin源碼分析

plugin daemon 初始化

Plugin 進程的入口在 /netplugin/netd.go , 主要完成命令行參數的解析. 而後建立一個Agent

plugin agent 建立

Agent的建立入口在 /netplugin/agent/agent.go,

• Cluster 初始化
  建立一個名爲 objdbClient 的 etcd client, 它的做用是處理cluster級別的消息, 好比一臺宿主機上的Plugin進程啓動後須要讓其餘宿主機上的Master進程和Plugin進程感知到本身的存在,那麼就須要經過這個client向etcd寫入本身運行的服務, 這個過程也稱爲Service註冊, 同時反過來,Plugin進程也能夠經過該client偵測到其餘plugin的啓動, 這個過程稱爲 Peer Discovery. 言而言之,cluster 初始化使得plugin進程成爲整個系統的一部分.
• Netplugin 初始化
  Netplugin的初始化主要包括State driver的初始化和Network driver的初始化.
  State driver的初始化主要是從etcd中獲取Master進程寫入的轉發模式(Fwd Mode)和私有子網(PvtSubnet)等信息並校驗和Plugin進程啓動時的命令行一致, 若是沒有獲得, 說明 Master進程尚未啓動, 須要等待.
  Network driver的初始化, 其實是底層ovs的驅動的初始化, Plugin進程須要等待ovs進程鏈接上來.
• Container runtime plugin 初始化
  這部分要根據插件模式(k8s 或者 docker) 進行插件邏輯的初始化, k8s對應CNI模型的插件. docker對應CNM模型的插件
  以docker爲例, 這部分將啓動一個Http Server, 用以響應 docker 進程發送過來的各種消息, 好比CreateNetwork, CreateEndpoint等等

狀態恢復

Contiv是跨主機容器網絡, 所以, 當某臺宿主機上的Plugin進程啓動後, 須要將系統中其餘節點已經建立的Contiv網絡和容器加入網絡的狀況同步到本地, 這個過程就是狀態恢復. 除了基本的network和endpoint信息, 能夠看到這一步還須要同步BGPEGPServiceLBSvcProvider這些信息.

Post 初始化

Post初始化完成兩項工做.

• 啓動Cluster 初始化時建立的 objdbClient, 使其完成Service註冊和並開始Peer Discovery.
• 啓動一個REST Http Server, 開放9090端口, 用戶能夠經過這個端口查看Plugin的一些工做狀況

啓動外部事件響應循環

在前面, Plugin進程從etcd中同步當前整個系統中的狀態做爲初始狀態. 那麼, 當網絡狀態發生變化後,Plugin進程也應該及時響應. 因此Plugin最後會啓動外部事件響應循環, 這裏根據事件類型的不一樣,實際會啓動若干個Go routine, 在這些routine裏, Plugin進程監視etcd中相應Key的變換, 並做出響應.