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信息, 可以看到這一步還需要同步BGP\EGP\ServiceLB\SvcProvider這些信息.
Post 初始化
Post初始化完成兩項工作.
- 啓動Cluster 初始化時創建的 objdbClient, 使其完成Service註冊和並開始Peer Discovery.
- 啓動一個REST Http Server, 開放9090端口, 用戶可以通過這個端口查看Plugin的一些工作情況
啓動外部事件響應循環
在前面, Plugin進程從etcd中同步當前整個系統中的狀態作爲初始狀態. 那麼, 當網絡狀態發生變化後,Plugin進程也應該及時響應. 所以Plugin最後會啓動外部事件響應循環, 這裏根據事件類型的不同,實際會啓動若干個Go routine, 在這些routine裏, Plugin進程監視etcd中相應Key的變換, 並作出響應.
