精通k8s（8）Calico网络：CNI接口

大家好，欢迎来到IT知识分享网。

在前面的文章提到Pod网络，它主要和Calico网络有关，那么这个Calico网络究竟是什么呢？在说明这个问题之前，首先理解CNI的概念。

什么是CNI？

我们创建容器之后，就像是买了一个房子，但是这个房子现在还没有连网。话说现在哪个房子能缺少网络呢？因此，我们的房子必须能“上网”。那么这个网怎么建呢？

kubelet是节点上的一个重要程序，它负责接收命令创建Pod。因此联网这个事情自然就落到它头上，但是kubelet说，这个网我不会建呀。怎么办呢？CNI规范就出台了，它的思路是：你可以叫别人帮你建嘛。这就好比我们是房子主人，联网这个事应该找电信工程师来做，我们只需要告诉它一个基本信息就可以了。

但如果你想做“电信工程师”这个角色，就得按照我的规范来，因此CNI就是一套规范，字面翻译就是容器网络接口。

CNI的架构

我们喊一个工程师（也就是插件）来装网，但是网络如何安装、我们当前的环境是怎样的，这些信息要发送给插件，那么信息怎么组织呢？CNI认为，这应该有一个规范，和k8s的资源配置一样，想要做什么按着规范格式来写，下面是一个JSON的示例配置：

{ "cniVersion": "0.3.1", // 遵循的 CNI 版本 "name": "k8s-pod-network", // 网络名称（对应 CNI 配置文件中的 name） "containerID": "abc123...", // 容器的唯一 ID（类似快递单号） "netns": "/var/run/netns/cni-xxx", // 容器的网络命名空间路径（类似容器的“网络隔离室”地址） "podNamespace": "default", // Pod 所在的命名空间 "podName": "my-test-pod", // Pod 的名字 "ipam": { "type": "calico-ipam" // 指定用 calico-ipam 分配 IP } }

CNI插件要能读懂这个配置，然后按照配置的要求执行。这是其一，接着CNI又规定，插件除了能理解规范的配置，而且要提供规范的接口，比如：添加（ADD）、删除（DELETE）、检查（CHECK）和版本查询（VERSION），就像软件开发中的interface一样，必须实现这几个功能。

Calico插件

calico插件就是实现CNI规范的一个应用程序，无论规范多么好，最终还是要有一个执行的人才行，那么calico就是最终的执行人。它能接收CNI规范，并且实现了规范要求的添加、删除、检查和版本查询的功能，架构如下：

大致流程：

1. kubelet接收命令，然后调用容器运行时创建容器。
2. 容器运行时调用calico创建网络，发送的是CNI规范的JSON配置文件。
3. calico接收命令之后，又同样通过CNI规范的配置文件调用calico-ipam分配IP地址。
4. 网络创建完成，calico返回结果给容器运行时。

calico具体做了什么

1. 在主机上创建虚拟网卡（calixxx），一端连主机，一端连容器（作为容器的 eth0）。
2. 配置容器内的网络参数（IP、子网掩码、网关等）。
3. 设置主机上的路由规则（让主机知道这个 Pod 的 IP 该从哪个虚拟网卡转发）。

但是Calico在做这些之前，需要为Pod提供一个IP地址，同样的，它把这个工作委托给calico-ipam。

calico-ipam具体做了什么

calico-ipam是“IP 地址管理工具”，负责从 Calico 的 IP 池中为新 Pod 分配 IP 地址，并记录哪些 IP 已被使用（避免冲突）。相当于calico问它：“我要创建一个新 Pod，能给个 IP 吗？” 它回复：“用 10.244.36.81 吧，这个没人用。”

可以看出calico-ipam是一个帮手的角色，它辅助calico创建网络。

calico和calico-ipam是在什么时候产生的？

我们已经搞清楚了那些小东西，像veth网卡对、IP地址、网关等这些是怎么弄出来的。那么calico和calico-ipam这两个二进制程序是什么时候创建的呢？

在节点机加入集群之后，会创建一个calico-node的容器，然后这个容器再将calico和calico-ipam复制到/etc/cni/bin目录。我们看下它们之间的架构关系：

calico-node容器做了什么

讨论完calico和calico-ipam之后，再来看calico-node容器，它是每个节点上安装的一个容器，里面主要有两个进程：

当felix监测到Pod创建之后，就会在本地写入一条路由规则，比如

10.244.36.99 dev cali798fc4190ee scope link 

bird进程收到felix传递的本地网段信息后，会将这些信息通过BGP协议散发到其它节点上，然后接收到的节点会将node1上面这个Pod的信息写到路由规则中，如下：

至此，我们已经分析完了calico的大致工作流程。

总结

1. kubelet调用容器运行时创建Pod之后，容器内的网络是空的。
2. kubelet想建网，但是它没有这个能力。于是它要使用第三方插件实现，插件用哪个，位置在哪里？在kubelet的启动参数中指定。
3. 通过参数找到了calico插件之后，容器运行时和calico插件进行交互。
4. 和calico插件交互需要遵守CNI规范，它就传一个符合CNI规范的JSON的配置文件。
5. calico开始工作，创建veth网卡、网关等等，在这之前它调用calico-ipam插件产生IP，同样这一步也要传一个符合CNI规范的JSON文件，因为calico-ipam也是一个CNI规范的插件。
6. 完成工作后，calico会返回一个结果给容器运行时。
7. calico-node容器中的felix监听到新建的Pod后，在本地写了一条路由，然后将信息传递给bird。
8. bird通过BGP协议将信息同步到集群其它节点，其它节点的bird接收之后再上传给felix，felix将这个路收写到主机，那么Pod就可以访问了。