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的变换, 并做出响应.