一个 Linux 容器能看见的“网络栈”，实际上是被隔离在它自己的 Network Namespace 当中的。而所谓“网络栈”，就包括了：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和iptables规则。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。
作为一种最简单的使容器与目标网络联通起来的方法，就是将他以某种形式借用宿主机的网络栈。
借用宿主机网络栈
容器可以声明直接使用宿主机的网络栈（–net=host），即：不开启 Network Namespace，比如：
$ docker run –d –net=host --name nginx-host nginx
在这种情况下，这个容器启动后，直接监听的就是宿主机的80端口。像这样直接使用宿主机网络栈的方式，虽然可以为容器提供良好的网络性能，但也会不可避免地引入共享网络资源的问题，比如端口冲突。所以，在大多数情况下，我们都希望容器进程能使用自己Network Namespace里的网络栈，即：拥有属于自己的IP地址和端口。
Veth设备
这个被隔离的容器进程，要跟其他Network Namespace里的容器进程、甚至宿主机进行交互，需要一个联通到宿主机的连线。通过创建Veth设备可以解决这个问题：
- veth和其它的网络设备都一样，一端连接的是内核协议栈
- veth设备是成对出现的，另一端两个设备彼此相连
- 一个设备收到协议栈的数据发送请求后，会将数据发送到另一个设备上去
基于以上几点，veth设备非常适合于作为连接不同Network Namespace的连线。
事实上，我们进入容器看到的网卡，其实就是veth设备的一端，它的另一端在宿主机的主network namespace上。要让容器或者pod具备独立的网络栈，基本上都是从这个veth设备入手进行考虑，在宿主机上添加各种路由策略、网桥等，使容器流量去往正确的方向。
CNI是什么
CNI便是k8s用于实现以上任务的标准接口。通过编写支持这套协议方法的插件，可以实现自己对k8s网络的管理。包括：
- CNI Plugin负责给容器配置网络，它包括两个基本的接口：
配置网络: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
清理网络: DelNetwork(net NetworkConfig, rt RuntimeConf) error - IPAM Plugin负责给容器分配IP地址，主要实现包括host-local和dhcp。而虎牙Athena容器云所实现的ip不变的方案，便是通过在ipam plugin中控制ip的分配策略所实现。
以上两种插件的支持，使得k8s的网络可以支持各式各样的管理模式，当前在业界也出现了大量的支持方案，其中比较流行的比如flannel、calico等。
kubernetes配置了cni网络插件后，其容器网络创建流程为：
- kubernetes先创建pause容器生成对应的network namespace
- 调用网络driver，因为配置的是CNI，所以会调用CNI相关代码
- CNI driver根据配置调用具体的CNI插件
- CNI插件给pause容器配置正确的网络，pod中其他的容器都是用pause的网络
其中，CNI Plugin是独立的可执行文件，被上层的容器管理平台(kubelet)调用。网络插件只有两件事情要做：把容器加入到网络(AddNetwork)以及把容器从网络中删除(DelNetwork)。
对应于具体的CNI框架内的实现，即两个基本操作ADD和DEL，前者用于加入容器网络，后者用于从容器网络中退出。
当CNI插件被调用时，首先进入main函数，main函数会对环境变量和标准输入中的配置信息进行解析，接着根据解析得到的操作方式（ADD或DEL），转入具体的执行函数完成网络的配置工作。如果是ADD操作，则调用cmdAdd()函数，反之，如果是DEL操作，则调用cmdDel()函数。从宏观角度来看，以上为CNI插件的实现框架主体。
编写自己的cni插件
按照上述说法，由于cni插件是kubelet以二进制的形式调用的，具体实现上主体为cmdAdd,cmdDel两大函数。
package main
import (
...
)
const (
...
)
func cmdAdd(args *skel.CmdArgs) error {
conf := types.NetConf{}
if err := json.Unmarshal(args.StdinData, &conf); err != nil {
log.Errorf("Error loading config from args: %v", err)
return errors.Wrap(err, "add cmd: error loading config from args")
}
versionDecoder := &cniversion.ConfigDecoder{}
confVersion, err := versionDecoder.Decode(args.StdinData)
if err != nil {
return err
}
// 在此实现：
// 1. 调用ipam plugin接口进行ip申请
// 2. 容器及宿主机各自网络栈内的操作，如创建veth，配置ip地址，配置路由等
ips := []*current.IPConfig{{Version: "4", Address: *ipnet}}
result := ¤t.Result{
IPs: ips,
}
return cnitypes.PrintResult(result, confVersion)
}
func cmdDel(args *skel.CmdArgs) error {
conf := types.NetConf{}
if err := json.Unmarshal(args.StdinData, &conf); err != nil {
log.Errorf("Error loading config from args: %v", err)
return errors.Wrap(err, "add cmd: error loading config from args")
}
versionDecoder := &cniversion.ConfigDecoder{}
confVersion, err := versionDecoder.Decode(args.StdinData)
if err != nil {
return err
}
// 在此实现：
// 1. 调用ipam plugin接口进行ip释放
// 2. 容器及宿主机各自网络栈内的操作，如删除veth，删除路由等
return nil
}
func main() {
log.SetLevel(log.DebugLevel)
ConfigLocalFilesystemLogger(logPath, 24*60*time.Hour, 24*time.Hour)
exitCode := 0
if e := skel.PluginMainWithError(cmdAdd, nil, cmdDel, cniversion.All, "<版本说明等信息>"); e != nil {
exitCode = 1
log.Error("Failed CNI request: ", e)
if err := e.Print(); err != nil {
log.Error("Error writing error JSON to stdout: ", err)
}
}
os.Exit(exitCode)
}
至于其中ipam接口如何调用，则不一定按照官方的ipam plugin规范编写，甚至可将ipam相关逻辑结合到cni plugin中。也可以独立服务，并通过API、RPC等方式调用。
坑在哪
本文介绍了容器网络CNI插件的原理，简化后的代码接口清晰简洁，主体流程围绕在：解析参数、执行add/del、返回结果上，按照CNI规范的结构编写配置、入参、返回值，可实现简单CNI逻辑。
但CNI特点在于具体的网络配置、网络连通方案、ip分配方案可由插件自定义，k8s仅负责调用。因此CNI的出现，使k8s网络架构更为灵活多变，也引入了更加复杂的因素：
- 因为k8s与容器网络的相对分离，容易形成容器的声明周期与其网络资源的生命周期相脱节
kubelet通过pleg进行的pod声明周期管理，使pod可控，但容器网络不可控。CNI的编写上，需要支持上层（kubelet）调用的多次重入及幂等，且pod与cni无强依赖，容易导致容器网络遗漏、残留等问题发生。
因此，在cni插件编写上，需进行更多的一致性校验及补漏、清理工作。
