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, 请查看
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等等
状态恢复
Post 初始化
- 启动Cluster 初始化时创建的 objdbClient, 使其完成Service注册和并开始Peer Discovery.
- 启动一个REST Http Server, 开放9090端口, 用户可以通过这个端口查看Plugin的一些工作情况
