0%

【Kubernetes】Container Network Interface

CNI 是 CNCF 旗下的一个项目,由一组用于配置 Linux 容器的网络接口的规范和库组成,同时还包含了一些插件。CNI 仅关心容器创建时的网络分配,和当容器被删除时释放网络资源。

其实,我们在前面介绍容器网络的时候,就提到了CNI网络规范,CNI相对于CNM(Container Network Model)对开发者的约束更少,更开放,不依赖于Docker。

实现一个CNI网络插件只需要一个配置文件一个可执行的文件

  • 配置文件描述插件的版本、名称、描述等基本信息
  • 可执行文件会被上层的容器管理平台调用,一个CNI可执行文件自需要实现将容器加入到网络的ADD操作以及将容器从网络中删除的DEL操作(以及一个可选的VERSION查看版本操作)

Kubernetes使用CNI网络插件的基本工作流程:

  • kubelet先创建pause容器生成对应的netns网络命名空间
  • 根据配置调用具体的CNI插件,可以配置成CNI插件链来进行链式调用
  • 当CNI插件被调用时,它根据环境变量以及命令行参数来获得网络命名空间netns、容器的网络设备等必要信息,然后执行ADD操作
  • CNI插件给pause容器配置正确的网络,pod中其他的容器都是用pause容器的网络

接口定义

CNI 的接口中包括以下几个方法:

1
2
3
4
5
6
type CNI interface {
AddNetworkList (net *NetworkConfigList, rt *RuntimeConf) (types.Result, error)
DelNetworkList (net *NetworkConfigList, rt *RuntimeConf) error
AddNetwork (net *NetworkConfig, rt *RuntimeConf) (types.Result, error)
DelNetwork (net *NetworkConfig, rt *RuntimeConf) error
}

该接口只有四个方法,添加网络、删除网络、添加网络列表、删除网络列表。

设计考量

CNI 设计的时候考虑了以下问题:

  • 容器运行时必须在调用任何插件之前为容器创建一个新的网络命名空间。
  • 然后,运行时必须确定这个容器应属于哪个网络,并为每个网络确定哪些插件必须被执行。
  • 网络配置采用 JSON 格式,可以很容易地存储在文件中。网络配置包括必填字段,如 nametype 以及插件(类型)。网络配置允许字段在调用之间改变值。为此,有一个可选的字段 args,必须包含不同的信息。
  • 容器运行时必须按顺序为每个网络执行相应的插件,将容器添加到每个网络中。
  • 在完成容器生命周期后,运行时必须以相反的顺序执行插件(相对于执行添加容器的顺序)以将容器与网络断开连接。
  • 容器运行时不能为同一容器调用并行操作,但可以为不同的容器调用并行操作。
  • 容器运行时必须为容器订阅 ADD 和 DEL 操作,这样 ADD 后面总是跟着相应的 DEL。 DEL 可能跟着额外的 DEL,但是,插件应该允许处理多个 DEL(即插件 DEL 应该是幂等的)。
  • 容器必须由 ContainerID 唯一标识。存储状态的插件应该使用(网络名称,容器 ID)的主键来完成。
  • 运行时不能调用同一个网络名称或容器 ID 执行两次 ADD(没有相应的 DEL)。换句话说,给定的容器 ID 必须只能添加到特定的网络一次。

CNI 插件

CNI 插件必须实现一个可执行文件,这个文件可以被容器管理系统(例如 rkt 或 Kubernetes)调用。

CNI 插件负责将网络接口插入容器网络命名空间(例如,veth 对的一端),并在主机上进行任何必要的改变(例如将 veth 的另一端连接到网桥)。然后将 IP 分配给接口,并通过调用适当的 IPAM 插件来设置与 “IP 地址管理” 部分一致的路由。

参数

CNI 插件必须支持以下操作:

将容器添加到网络

参数:

  • 版本调用者正在使用的 CNI 规范(容器管理系统或调用插件)的版本。
  • 容器 ID由运行时分配的容器的唯一明文标识符。一定不能是空的。
  • 网络命名空间路径要添加的网络名称空间的路径,即 /proc/[pid]/ns/net 或绑定挂载 / 链接。
  • 网络配置描述容器可以加入的网络的 JSON 文档。架构如下所述。
  • 额外的参数这提供了一个替代机制,允许在每个容器上简单配置 CNI 插件。
  • 容器内接口的名称这是应该分配给容器(网络命名空间)内创建的接口的名称;因此它必须符合 Linux 接口名称上的标准限制。

结果:

  • 接口列表根据插件的不同,这可以包括沙箱(例如容器或管理程序)接口名称和 / 或主机接口名称,每个接口的硬件地址以及接口所在的沙箱(如果有的话)的详细信息。
  • 分配给每个接口的 IP 配置分配给沙箱和 / 或主机接口的 IPv4 和 / 或 IPv6 地址,网关和路由。
  • DNS 信息包含 nameserver、domain、search domain 和 option 的 DNS 信息的字典。

从网络中删除容器

参数:

  • 版本调用者正在使用的 CNI 规范(容器管理系统或调用插件)的版本。
  • 容器 ID,如上所述。
  • 网络命名空间路径,如上定义。
  • 网络配置,如上所述。
  • 额外的参数,如上所述。
  • 上面定义的容器内的接口的名称。

  • 所有参数应与传递给相应的添加操作的参数相同。

  • 删除操作应释放配置的网络中提供的 containerid 拥有的所有资源。

报告版本

  • 参数:无。
  • 结果:插件支持的 CNI 规范版本信息。
1
2
3
4
5
6
7
8
9
{
"cniVersion":"0.3.1",// 此输出使用的 CNI 规范的版本
"supportedVersions":[
"0.1.0",
"0.2.0",
"0.3.0",
"0.3.1"
] // 此插件支持的 CNI 规范版本列表
}

CNI 插件的详细说明请参考:CNI SPEC

IP 分配

作为容器网络管理的一部分,CNI 插件需要为接口分配(并维护)IP 地址,并安装与该接口相关的所有必要路由。这给了 CNI 插件很大的灵活性,但也给它带来了很大的负担。众多的 CNI 插件需要编写相同的代码来支持用户需要的多种 IP 管理方案(例如 dhcp、host-local)。

为了减轻负担,使 IP 管理策略与 CNI 插件类型解耦,我们定义了 IP 地址管理插件(IPAM 插件)。CNI 插件的职责是在执行时恰当地调用 IPAM 插件。 IPAM 插件必须确定接口 IP/subnet,网关和路由,并将此信息返回到 “主” 插件来应用配置。 IPAM 插件可以通过协议(例如 dhcp)、存储在本地文件系统上的数据、网络配置文件的 “ipam” 部分或上述的组合来获得信息。

IPAM 插件

像 CNI 插件一样,调用 IPAM 插件的可执行文件。可执行文件位于预定义的路径列表中,通过 CNI_PATH 指示给 CNI 插件。 IPAM 插件必须接收所有传入 CNI 插件的相同环境变量。就像 CNI 插件一样,IPAM 插件通过 stdin 接收网络配置。

CNI Plugin Chains

CNI还支持Plugin Chains,即指定一个插件列表,由Runtime依次执行每个插件。这对支持端口映射(portmapping)、虚拟机等非常有帮助。

Network Configuration Lists

CNI SPEC 支持指定网络配置列表,包含多个网络插件,由 Runtime 依次执行。注意

  • ADD 操作,按顺序依次调用每个插件;而 DEL 操作调用顺序相反
  • ADD 操作,除最后一个插件,前面每个插件需要增加 prevResult 传递给其后的插件
  • 第一个插件必须要包含 ipam 插件

端口映射示例

下面的例子展示了 bridge+portmap 插件的用法。

首先,配置 CNI 网络使用 bridge+portmap 插件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# cat /root/mynet.conflist
{
"name": "mynet",
"cniVersion": "0.3.0",
"plugins": [
{
"type": "bridge",
"bridge": "mynet",
"ipMasq": true,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.10.0/24",
"routes": [
{"dst": "0.0.0.0/0"}
]
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}

然后通过 CAP_ARGS 设置端口映射参数:

1
2
3
4
5
6
7
8
9
10
# export CAP_ARGS='{
"portMappings": [
{
"hostPort": 9090,
"containerPort": 80,
"protocol": "tcp",
"hostIP": "127.0.0.1"
}
]
}'

测试添加网络接口:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# ip netns add test
# CNI_PATH=/opt/cni/bin NETCONFPATH=/root ./cnitool add mynet /var/run/netns/test
{
"interfaces": [
{
"name": "mynet",
"mac": "0a:58:0a:f4:0a:01"
},
{
"name": "veth2cfb1d64",
"mac": "4a:dc:1f:b7:56:b1"
},
{
"name": "eth0",
"mac": "0a:58:0a:f4:0a:07",
"sandbox": "/var/run/netns/test"
}
],
"ips": [
{
"version": "4",
"interface": 2,
"address": "10.244.10.7/24",
"gateway": "10.244.10.1"
}
],
"routes": [
{
"dst": "0.0.0.0/0"
}
],
"dns": {}
}

可以从 iptables 规则中看到添加的规则:

1
2
3
# iptables-save | grep 10.244.10.7
-A CNI-DN-be1eedf7a76853f303ebd -d 127.0.0.1/32 -p tcp -m tcp --dport 9090 -j DNAT --to-destination 10.244.10.7:80
-A CNI-SN-be1eedf7a76853f303ebd -s 127.0.0.1/32 -d 10.244.10.7/32 -p tcp -m tcp --dport 80 -j MASQUERADE

最后,清理网络接口:

1
# CNI_PATH=/opt/cni/bin NETCONFPATH=/root ./cnitool del mynet /var/run/netns/test

可用插件

Main:接口创建

  • bridge:创建网桥,并添加主机和容器到该网桥
  • ipvlan:在容器中添加一个 ipvlan 接口
  • loopback:创建一个回环接口
  • macvlan:创建一个新的 MAC 地址,将所有的流量转发到容器
  • ptp:创建 veth 对
  • vlan:分配一个 vlan 设备

IPAM:IP 地址分配

  • dhcp:在主机上运行守护程序,代表容器发出 DHCP 请求
  • host-local:维护分配 IP 的本地数据库

Meta:其它插件

  • flannel:根据 flannel 的配置文件创建接口
  • tuning:调整现有接口的 sysctl 参数
  • portmap:一个基于 iptables 的 portmapping 插件。将端口从主机的地址空间映射到容器。

Container Network Interface (CNI) 最早是由CoreOS发起的容器网络规范,是Kubernetes网络插件的基础。其基本思想为:Container Runtime在创建容器时,先创建好network namespace,然后调用CNI插件为这个netns配置网络,其后再启动容器内的进程。现已加入CNCF,成为CNCF主推的网络模型。

CNI插件包括两部分:

  • CNI Plugin负责给容器配置网络,它包括两个基本的接口
    • 配置网络: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
    • 清理网络: DelNetwork(net NetworkConfig, rt RuntimeConf) error
  • IPAM Plugin负责给容器分配IP地址,主要实现包括host-local和dhcp。

Kubernetes Pod 中的其他容器都是Pod所属pause容器的网络,创建过程为:

  1. kubelet 先创建pause容器生成network namespace
  2. 调用网络CNI driver
  3. CNI driver 根据配置调用具体的cni 插件
  4. cni 插件给pause 容器配置网络
  5. pod 中其他的容器都使用 pause 容器的网络

img

所有CNI插件均支持通过环境变量和标准输入传入参数:

1
2
3
$ echo '{"cniVersion": "0.3.1","name": "mynet","type": "macvlan","bridge": "cni0","isGateway": true,"ipMasq": true,"ipam": {"type": "host-local","subnet": "10.244.1.0/24","routes": [{ "dst": "0.0.0.0/0" }]}}' | sudo CNI_COMMAND=ADD CNI_NETNS=/var/run/netns/a CNI_PATH=./bin CNI_IFNAME=eth0 CNI_CONTAINERID=a CNI_VERSION=0.3.1 ./bin/bridge

$ echo '{"cniVersion": "0.3.1","type":"IGNORED", "name": "a","ipam": {"type": "host-local", "subnet":"10.1.2.3/24"}}' | sudo CNI_COMMAND=ADD CNI_NETNS=/var/run/netns/a CNI_PATH=./bin CNI_IFNAME=a CNI_CONTAINERID=a CNI_VERSION=0.3.1 ./bin/host-local

常见的CNI网络插件有

img

Bridge

Bridge是最简单的CNI网络插件,它首先在Host创建一个网桥,然后再通过veth pair连接该网桥到 container netns。

img

注意:Bridge模式下,多主机网络通信需要额外配置主机路由,或使用overlay网络。可以借助Flannel或者Quagga动态路由等来自动配置。比如overlay情况下的网络结构为

img

配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
{
"cniVersion": "0.3.0",
"name": "mynet",
"type": "bridge",
"bridge": "mynet0",
"isDefaultGateway": true,
"forceAddress": false,
"ipMasq": true,
"hairpinMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.10.0.0/16"
}
}
# export CNI_PATH=/opt/cni/bin
# ip netns add ns
# /opt/cni/bin/cnitool add mynet /var/run/netns/ns
{
"interfaces": [
{
"name": "mynet0",
"mac": "0a:58:0a:0a:00:01"
},
{
"name": "vethc763e31a",
"mac": "66:ad:63:b4:c6:de"
},
{
"name": "eth0",
"mac": "0a:58:0a:0a:00:04",
"sandbox": "/var/run/netns/ns"
}
],
"ips": [
{
"version": "4",
"interface": 2,
"address": "10.10.0.4/16",
"gateway": "10.10.0.1"
}
],
"routes": [
{
"dst": "0.0.0.0/0",
"gw": "10.10.0.1"
}
],
"dns": {}
}
# ip netns exec ns ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
9: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 0a:58:0a:0a:00:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.10.0.4/16 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::8c78:6dff:fe19:f6bf/64 scope link tentative dadfailed
valid_lft forever preferred_lft forever
# ip netns exec ns ip route
default via 10.10.0.1 dev eth0
10.10.0.0/16 dev eth0 proto kernel scope link src 10.10.0.4

IPAM

DHCP

DHCP插件是最主要的IPAM插件之一,用来通过DHCP方式给容器分配IP地址,在macvlan插件中也会用到DHCP插件。

在使用DHCP插件之前,需要先启动dhcp daemon:

1
/opt/cni/bin/dhcp daemon &

然后配置网络使用dhcp作为IPAM插件

1
2
3
4
5
6
{
...
"ipam": {
"type": "dhcp",
}
}

host-local

host-local是最常用的CNI IPAM插件,用来给container分配IP地址。

IPv4:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"ipam": {
"type": "host-local",
"subnet": "10.10.0.0/16",
"rangeStart": "10.10.1.20",
"rangeEnd": "10.10.3.50",
"gateway": "10.10.0.254",
"routes": [
{ "dst": "0.0.0.0/0" },
{ "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
],
"dataDir": "/var/my-orchestrator/container-ipam-state"
}
}

IPv6:

1
2
3
4
5
6
7
8
9
10
11
12
{
"ipam": {
"type": "host-local",
"subnet": "3ffe:ffff:0:01ff::/64",
"rangeStart": "3ffe:ffff:0:01ff::0010",
"rangeEnd": "3ffe:ffff:0:01ff::0020",
"routes": [
{ "dst": "3ffe:ffff:0:01ff::1/64" }
],
"resolvConf": "/etc/resolv.conf"
}
}

ptp

ptp插件通过veth pair给容器和host创建点对点连接:veth pair一端在container netns内,另一端在host上。可以通过配置host端的IP和路由来让ptp连接的容器之前通信。

1
2
3
4
5
6
7
8
9
10
11
{
"name": "mynet",
"type": "ptp",
"ipam": {
"type": "host-local",
"subnet": "10.1.1.0/24"
},
"dns": {
"nameservers": [ "10.1.1.1", "8.8.8.8" ]
}
}

CNI插件是可执行文件,会被kubelet调用。启动kubelet --network-plugin=cni,--cni-conf-dir 指定networkconfig配置,默认路径是:/etc/cni/net.d,并且,--cni-bin-dir 指定plugin可执行文件路径,默认路径是:/opt/cni/bin

CNI 网络方案优缺点及最终选择

整体架构

很多文章都是从跨主机容器如何通信 的来阐述网络方案,这或许是一个很不好的理解曲线,从实际来说,一定是先有网络,再为Pod “连上网”。

先说网络再说Pod

阿里巴巴的一本Kubernetes的册子提到容器网络的几个阶段(对于不同网络方案, 某些步骤可选),分阶段理解容器网络,即先有网络通信能力,再有Pod接入网络

  1. 集群阶段, 确定的集群的CIDR,为每个节点分配 podCIDR/网段
  2. 节点阶段
    1. 集群范围内,为每个节点增加路由表项
    2. 节点内,运行一些守护进程(以同步数据、接受指令),创建虚拟网桥cni0,以及与 cni0 相关的路 由。 这些配置的作用是,从节点外部进来的网络包,如果目的 IP 是 podCIDR,则会 被节点转发到 cni0 虚拟局域网里。 前两个阶段,集群实际上已经为 Pod 之间搭建了网络通信的干道
  3. pod 阶段。kubelet 会通过 cni 为这个 Pod 本身创建网络命名空间和 veth 设备,然后,把其中一个 veth 设备加入到 cni0 虚拟 网桥里,并为 Pod 内的 veth 设备配置 ip 地址。这样 Pod 就和网络通信的干道连接 在了一起。

先说Pod再说网络

理解 CNI 和 CNI 插件CNI 插件的实现通常包含两个部分:

  1. 一个二进制的 CNI 插件去配置 Pod 网卡和 IP 地址。这一步配置完成之后相当于给 Pod 上插上了一条网线,就是说它已经有自己的 IP、有自己的网卡了;

    img

    通常我们会用一个 “veth” 这种虚拟网卡,一端放到 Pod 的网络空间,一端放到主机的网络空间,这样就实现了 Pod 与主机这两个命名空间的打通

  2. 一个 Daemon 进程去管理 Pod 之间的网络打通。这一步相当于说将 Pod 真正连上网络,让 Pod 之间能够互相通信。

    1. 首先 CNI 在每个节点上运行的 Daemon 进程会学习到集群所有 Pod 的 IP 地址及其所在节点信息;学习的方式通常是通过监听 K8s APIServer,拿到现有 Pod 的 IP 地址以及节点,并且新的节点和新的 Pod 的创建的时候也能通知到每个 Daemon。

    2. 拿到 Pod 以及 Node 的相关信息之后,再去配置网络进行打通。首先 Daemon 会创建到

      整个集群所有节点的通道

      。这里的通道是个抽象概念,具体实现一般是通过 Overlay 隧道、阿里云上的 VPC 路由表、或者是自己机房里的 BGP 路由完成的。第二步是

      将所有 Pod 的 IP 地址跟上一步创建的通道关联起来

      。关联也是个抽象概念,具体的实现通常是通过 Linux 路由、fdb 转发表或者OVS 流表等完成的。

      1. Linux 路由可以设定某一个 IP 地址路由到哪个节点上去
      2. fdb 转发表是 forwarding database 的缩写,就是把某个 Pod 的 IP 转发到某一个节点的隧道端点上去(Overlay 网络)。
      3. OVS 流表是由 Open vSwitch 实现的,它可以把 Pod 的 IP 转发到对应的节点上。

深入了解一个网络组件的切入点就是:网络组件的cni plugin 与 网络组件的node agent 的分工边界。

CNI SPEC

CNI (Container Network Interface): Specification that act as interface between Container runtime and networking model implementations。

The cni specification is lightweight; it only deals with the network connectivity of containers,as well as the garbage collection of resources once containers are deleted.

img

cni 接口规范,不是很长Container Network Interface Specification 对 CNI SPEC 的解读 Understanding CNI (Container Networking Interface)

kubernetes 对CNI 的实现(SPEC复杂的描述体现在 code 上就是几个函数

github.com/containernetworking/cni/libcni/api.go
1
2
3
4
5
6
type CNI interface {
AddNetworkList(net *NetworkConfigList, rt *RuntimeConf) (types.Result, error)
DelNetworkList(net *NetworkConfigList, rt *RuntimeConf) error
AddNetwork(net *NetworkConfig, rt *RuntimeConf) (types.Result, error)
DelNetwork(net *NetworkConfig, rt *RuntimeConf) error
}

wiki 在描述驱动系统时提到:A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details about the hardware being used. CNI interface 将一个复杂的系统收敛到几个“入口”,运用之妙存乎一心。

使用CNI binary

裸机使用cni

1
2
3
4
5
$ mkdir cni && cd cni
$ curl -O -L https://github.com/containernetworking/cni/releases/download/v0.4.0/cni-amd64-v0.4.0.tgz
$ tar -xzvf cni-amd64-v0.4.0.tgz
$ ls # 可以看到这里解压后实际上是不同插件的二进制文件
bridge cni-amd64-v0.4.0.tgz cnitool dhcp flannel host-local ipvlan loopback macvlan noop ptp tuning

创建一个网络命名空间 cosmos,当前网络命名空间都为空,没有任何网络配置,通过 ip netns exec cosmos ifconfig 查看无响应:

1
2
3
4
$ ip netns add cosmos
$ ip netns list
cosmos
$ ip netns exec cosmos ifconfig # 可以看到此时cosmos网络命名空间为空,无任何配置

接下来创建 mybridge.conf 作为 bridge 插件的配置文件,调用 cni plugincosmos 这个 network namespace ADD 到 network 上,这也就对应着将容器 Add 到某个网络上。可以看到在 mybridge.conf 中定义了这个命名空间的 subnet 和 路由表,同时加入网络时通过环境变量指定了网口名称等信息:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
$ cat > mybridge.conf <<"EOF"
{
"cniVersion": "0.2.0",
"name": "mybridge",
"type": "bridge",
"bridge": "cni_bridge0",
"isGateway": true,
"ipMasq": true,
"ipam": {
"type": "host-local",
"subnet": "10.15.20.0/24",
"routes": [
{ "dst": "0.0.0.0/0" },
{ "dst": "1.1.1.1/32", "gw":"10.15.20.1"}
]
}
}
EOF

$ CNI_COMMAND=ADD CNI_CONTAINERID=cosmos CNI_NETNS=/var/run/netns/cosmos CNI_IFNAME=eth12 CNI_PATH=`pwd` ./bridge < mybridge.conf
2021/01/28 10:55:02 Error retriving last reserved ip: Failed to retrieve last reserved ip: open /var/lib/cni/networks/mybridge/last_reserved_ip: no such file or directory
{
"ip4": {
"ip": "10.15.20.2/24",
"gateway": "10.15.20.1",
"routes": [
{
"dst": "0.0.0.0/0"
},
{
"dst": "1.1.1.1/32",
"gw": "10.15.20.1"
}
]
},
"dns": {}
}

这里返回了一个错误是因为 IPAM 驱动不能够找到它本地存储 IP 信息的文件,这个文件将在第一次运行上述命令时创建。如果你在另一个网络命名空间再运行一次上述命令,就不会再得到上述错误了。命令执行结果返回了一个 JSON 文件,其中表明了插件相关的网络配置。在这里,bridge 会收到 10.15.20.1/24 作为 IP 地址,而 网络命令空间的 Interface 收到 10.15.20.1/24 。同时,bridge 插件也配置了 1.1.1.1/32 的路由。

接下来再来查看 cosmos 这个网络命名空间的配置,可以看到相比于原来,现在多了两个网络接口,一个是先创建的 cni_bridge0 网桥,另一个是 veth 对的一边。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ ifconfig
cni_bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.15.20.1 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::3064:b8ff:fe98:6b0c prefixlen 64 scopeid 0x20<link>
ether 0a:58:0a:0f:14:01 txqueuelen 1000 (Ethernet)
RX packets 9 bytes 600 (600.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 30 bytes 4430 (4.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

veth0311918a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::8029:32ff:fe55:6cbf prefixlen 64 scopeid 0x20<link>
ether 82:29:32:55:6c:bf txqueuelen 0 (Ethernet)
RX packets 9 bytes 726 (726.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 38 bytes 5066 (4.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
...

接下来我们到 Network Namespace Interface 里面去看看,可以看到:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ ip netns exec cosmos ifconfig
eth12: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.15.20.3 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::2460:91ff:fe20:8a0 prefixlen 64 scopeid 0x20<link>
ether 0a:58:0a:0f:14:03 txqueuelen 0 (Ethernet)
RX packets 11 bytes 906 (906.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 796 (796.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

$ ip netns exec cosmos ip route
default via 10.15.20.1 dev eth12
1.1.1.1 via 10.15.20.1 dev eth12
10.15.20.0/24 dev eth12 proto kernel scope link src 10.15.20.3

这个例子并没有什么实际的价值,但将 cni plugin 操作 network namespace 从cni繁杂的上下文中抽取出来,让我们看到它最本来的样子。

Using CNI with container runtime

net=none 创建的容器,为其配置网络 与 上文的为 network namespace 配置网络是一样的。

首先我们通过 docker run 运行一个容器,这里指定 net=none 告诉 Docker 为容器去创建一个网络命名空间,但是并不将这个网络命名空间挂到其他的任何地方。通过 ifconfig 查看容器内部网络,只能看到一个本地回环网口。这个时候我们是访问不了容器的内部服务的,因为我们根本不知道其地址。

1
2
3
4
5
6
7
8
9
$ docker run --name cnitest --net=none -d jonlangemak/web_server_1
$ docker exec cnitest ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

接下来我们像上面一样,使用 CNI 将为容器设置网络,在此之前我们需要知道容器的网络命名空间和容器ID:

1
2
3
$ docker inspect cnitest | grep -E 'SandboxKey|Id'
"Id": "988f72b8069ed381243ca8e06d25e9bf9c1482d11fa7baf4ed76a8b0cac0c3e2",
"SandboxKey": "/var/run/docker/netns/0582ad9f14ef",

同样,设置 CNI 配置文件,然后启动 bridge 这个插件,通过环境变量为其传递参数:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
$ cat > mybridge2.conf <<"EOF"
{
"cniVersion": "0.2.0",
"name": "mybridge",
"type": "bridge",
"bridge": "cni_bridge1",
"isGateway": true,
"ipMasq": true,
"ipam": {
"type": "host-local",
"subnet": "10.15.30.0/24",
"routes": [
{ "dst": "0.0.0.0/0" },
{ "dst": "1.1.1.1/32", "gw":"10.15.30.1"}
],
"rangeStart": "10.15.30.100",
"rangeEnd": "10.15.30.200",
"gateway": "10.15.30.99"
}
}
EOF

$ CNI_COMMAND=ADD CNI_CONTAINERID=988f72b8069ed381243ca8e06d25e9bf9c1482d11fa7baf4ed76a8b0cac0c3e2 CNI_NETNS=/var/run/docker/netns/0582ad9f14ef CNI_IFNAME=eth0 CNI_PATH=`pwd` ./bridge < mybridge2.conf
{
"ip4": {
"ip": "10.15.30.100/24",
"gateway": "10.15.30.99",
"routes": [
{
"dst": "0.0.0.0/0"
},
{
"dst": "1.1.1.1/32",
"gw": "10.15.30.1"
}
]
},
"dns": {}
}

这时候再在主机上查看,我们可以看到主机上多了一个 cni_bridge1 和另一个 veth 端。 cni_bridge1 的 IP 地址就是我们在上面设置的 gateway 地址。

1
2
3
4
5
6
7
8
cni_bridge1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.15.30.99 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::ec4e:c5ff:feed:729f prefixlen 64 scopeid 0x20<link>
ether 0a:58:0a:0f:1e:63 txqueuelen 1000 (Ethernet)
RX packets 6 bytes 681 (681.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 41 bytes 5322 (5.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

至此容器网络配置完毕,我们可以进入容器内部查看网络设置,可以看到:

  • 容器内部 IP 地址就是 IPAM 定义的起始地址 10.15.30.100
  • 容器内部网络设备名称为设置的 eth0
  • 容器内部网络路由默认由网关 10.15.30.99 处理
  • 将对 1.1.1.1/32 的访问路由到设置的网关 10.15.30.1 处理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ docker exec cnitest ifconfig
eth0 Link encap:Ethernet HWaddr 0a:58:0a:0f:1e:64
inet addr:10.15.30.100 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:36 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4912 (4.9 KB) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
$ docker exec cnitest ip route
default via 10.15.30.99 dev eth0
1.1.1.1 via 10.15.30.1 dev eth0
10.15.30.0/24 dev eth0 proto kernel scope link src 10.15.30.100

到现在,容器已经有其 IP 地址,直接访问这个地址可以得到容器内部服务的响应:

1
2
3
4
5
6
$ curl http://10.15.30.100
<body>
<html>
<h1><span style="color:#FF0000;font-size:72px;">Web Server #1 - Running on port 80</span></h1>
</body>
</html>

Using CNI with CRI

img

在 Kubernetes 中,处理容器网络相关的逻辑并不会在kubelet 主干代码里执行(上图这块有偏差),而是会在具体的 CRI 实现里完成。对于 Docker 项目来说,它的 CRI 实现叫作 dockershim,相关代码在 pkg/kubelet/dockershim

CRI 设计的一个重要原则,就是确保这个接口本身只关注容器, 不关注Pod。但CRI 里有一个 PodSandbox,抽取了 Pod 里的一部分与容器运行时相关的字段,比如 Hostname、DnsConfig 等。作为具体的容器项目,自己决定如何使用这些字段来实现一个k8s期望的Pod模型。

img

kubelet中调用CRI shim提供的imageService,ContainerService接口,作为gRPC client,dockershim实现了CRI gRPC Server服务端的服务实现,但是dockershim仍然整合到了kubelet中,作为kubelet默认的CRI shim实现.

dockershim 封了一个pkg/kubelet/dockershim/libdocker 会使用docker提供的client来调用cli接口,没错!就是github.com/docker/docker/client

顺着上文思路,当 kubelet 组件需要创建 Pod 的时候,它第一个创建的一定是 Infra 容器,这体现在上图的 RunPodSandbox 中

img

RunPodSandbox creates and starts a pod-level sandbox. Runtimes should ensure the sandbox is in ready state.For docker, PodSandbox is implemented by a container holding the network namespace for the pod.Note: docker doesn’t use LogDirectory (yet).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
func (ds *dockerService) RunPodSandbox(ctx context.Context, r *runtimeapi.RunPodSandboxRequest) (*runtimeapi.RunPodSandboxResponse, error) {
config := r.GetConfig()
// Step 1: Pull the image for the sandbox.
err := ensureSandboxImageExists(ds.client, defaultSandboxImage);
// Step 2: Create the sandbox container.
createConfig, err := ds.makeSandboxDockerConfig(config, image)
createResp, err := ds.client.CreateContainer(*createConfig)
ds.setNetworkReady(createResp.ID, false)
defer func(e *error) {
// Set networking ready depending on the error return of the parent function
if *e == nil {
ds.setNetworkReady(createResp.ID, true)
}
}(&err)
// Step 3: Create Sandbox Checkpoint.
ds.checkpointManager.CreateCheckpoint(createResp.ID, constructPodSandboxCheckpoint(config));
// Step 4: Start the sandbox container. Assume kubelet's garbage collector would remove the sandbox later, if startContainer failed.
err = ds.client.StartContainer(createResp.ID)
// Rewrite resolv.conf file generated by docker.
containerInfo, err := ds.client.InspectContainer(createResp.ID)
err := rewriteResolvFile(containerInfo.ResolvConfPath, dnsConfig.Servers, dnsConfig.Searches, dnsConfig.Options);
// Do not invoke network plugins if in hostNetwork mode.
if config.GetLinux().GetSecurityContext().GetNamespaceOptions().GetNetwork() == runtimeapi.NamespaceMode_NODE {
return resp, nil
}
// Step 5: Setup networking for the sandbox.
// All pod networking is setup by a CNI plugin discovered at startup time. This plugin assigns the pod ip, sets up routes inside the sandbox,
// creates interfaces etc. In theory, its jurisdiction ends with pod sandbox networking, but it might insert iptables rules or open ports
// on the host as well, to satisfy parts of the pod spec that aren't recognized by the CNI standard yet.
err = ds.network.SetUpPod(config.GetMetadata().Namespace, config.GetMetadata().Name, cID, config.Annotations, networkOptions)
return resp, nil
}

kubeGenericRuntimeManager 类似,dockerService 方法分散在各个文件中

go文件 包含方法
docker_service.go dockerService struct 定义 以及GetNetNS/Start/Status等
docker_sandbox.go RunPodSandbox等
docker_container.go CreateContainer/StartContainer等
docker_image.go PullImage等

img

从左到右可以看到用户请求 怎么跟cni plugin(binary file) 产生关联的

golang中一个接口可以包含一个或多个其他的接口,这相当于直接将这些内嵌接口的方法列举在外层接口中一样。

加载 CNI plugin

网络是容器创建成功后分配的

img

cniNetworkPlugin.Init 方法逻辑如下

1
2
3
4
5
6
7
8
9
10
11
12
13
func (plugin *cniNetworkPlugin) Init(host network.Host, hairpinMode kubeletconfig.HairpinMode, nonMasqueradeCIDR string, mtu int) error {
err := plugin.platformInit()
...
plugin.host = host
plugin.syncNetworkConfig()
return nil
}

func (plugin *cniNetworkPlugin) syncNetworkConfig() {
network, err := getDefaultCNINetwork(plugin.confDir, plugin.binDirs)
...
plugin.setDefaultNetwork(network)
}

confDir 加载 xx.conflist,结合 binDirs 构造 defaultNetwork

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
func getDefaultCNINetwork(confDir string, binDirs []string) (*cniNetwork, error) {
files, err := libcni.ConfFiles(confDir, []string{".conf", ".conflist", ".json"})
sort.Strings(files)
for _, confFile := range files {
var confList *libcni.NetworkConfigList
if strings.HasSuffix(confFile, ".conflist") {
confList, err = libcni.ConfListFromFile(confFile)
...
}
network := &cniNetwork{
name: confList.Name,
NetworkConfig: confList,
CNIConfig: &libcni.CNIConfig{Path: binDirs},
}
return network, nil
}
return nil, fmt.Errorf("No valid networks found in %s", confDir)
}

docker service 作为grpc server 实现,最终还是操作了 CNI,CNIConfig接收到指令后, 拼凑“shell指令及参数” 执行 cni binary文件。CNI 插件的初始化就是 根据binary path 初始化CNIConfig,进而初始化NetworkPlugin。至于cni binary 本身只需要执行时运行即可,就像 go 运行一般的可执行文件一样

1
2
3
4
5
6
7
8
9
10
11
12
13
github.com/containernetworking/cni/pkg/invoke/raw_exec.go
func (e *RawExec) ExecPlugin(ctx context.Context, pluginPath string, stdinData []byte, environ []string) ([]byte, error) {
stdout := &bytes.Buffer{}
c := exec.CommandContext(ctx, pluginPath)
c.Env = environ
c.Stdin = bytes.NewBuffer(stdinData)
c.Stdout = stdout
c.Stderr = e.Stderr
if err := c.Run(); err != nil {
return nil, pluginErr(err, stdout.Bytes())
}
return stdout.Bytes(), nil
}

CNI 实现

github.com/containernetworking/cni/pkg/skel/skel.go 定义了 dispatcherCmdArgs struct

1
2
3
4
5
6
7
8
9
10
11
12
13
// github.com/projectcalico/cni-plugin/cmd/calico/calico.go
func main() {
plugin.Main(VERSION)
}
// github.com/projectcalico/cni-plugin/pkg/plugin/plugin.go
func Main(version string) {
...
skel.PluginMain(cmdAdd, nil, cmdDel,
cniSpecVersion.PluginSupports("0.1.0", "0.2.0", "0.3.0", "0.3.1"),
"Calico CNI plugin "+version)
}
func cmdAdd(args *skel.CmdArgs) error {...}
func cmdDel(args *skel.CmdArgs) error {...}

cni plugin 是一个二进制文件,执行时 执行main 方法 ==> skel.PluginMain ==> dispatcher.pluginMain ,CmdArgs 约定了调用参数,任何插件都是这样一个套路,只需实现cmdAdd 和 cmdDel 即可,用于对应添加网卡和删除网卡两个操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
// github.com/projectcalico/cni-plugin/pkg/plugin/plugin.go
func cmdAdd(args *skel.CmdArgs) error {
...
// 获取Calico的配置,节点的名称,Calico客户端,是为了生成这个Pod唯一的WEP(Workload Endpoint)名称,也即网卡的名称。
calicoClient, err := utils.CreateClient(conf)
...
if wepIDs.Orchestrator == api.OrchestratorKubernetes {
if result, err = k8s.CmdAddK8s(ctx, args, conf, *wepIDs, calicoClient, endpoint); err != nil {
return err
}
}
...
}
// github.com/projectcalico/cni-plugin/pkg/k8s/k8s.go
func CmdAddK8s(ctx context.Context, args *skel.CmdArgs, conf types.NetConf, ...) (*current.Result, error) {
...
client, err := newK8sClient(conf, logger)
if conf.IPAM.Type == "host-local" {...}
if conf.Policy.PolicyType == "k8s" {...}
ipAddrsNoIpam := annot["cni.projectcalico.org/ipAddrsNoIpam"]
ipAddrs := annot["cni.projectcalico.org/ipAddrs"]
... // 构造routes, endpoint, 从pod 中获取annotation 等数据, 可以通过设置 pod annotation 来控制pod的 网络配置,比如ip地址等
switch {
case ipAddrs == "" && ipAddrsNoIpam == "":
...
case ipAddrs != "" && ipAddrsNoIpam != "":
...
case ipAddrsNoIpam != "":
...
case ipAddrs != "":
...
result, err = ipAddrsResult(ipAddrs, conf, args, logger)// 调用IPAM插件,获得一个IP地址
...
}
d, err := dataplane.GetDataplane(conf, logger)
hostVethName, contVethMac, err := d.DoNetworking(args, result, desiredVethName, routes, endpoint, annot)
}
// github.com/projectcalico/cni-plugin/pkg/dataplane/dataplane.go
func (d *linuxDataplane) DoNetworking(
args *skel.CmdArgs,
result *current.Result,
desiredVethName string,
routes []*net.IPNet,
endpoint *api.WorkloadEndpoint,
annotations map[string]string)(...){
// Clean up if hostVeth exists.
ns.WithNetNSPath(args.Netns, func(hostNS ns.NetNS) error {
// 先是建立veth pair,一边是contVethName,将来是容器内的,另一边是hostVethName,将来是容器外的。 主机端 cali 开头,后面 11 位是容器的 id 开头
veth := &netlink.Veth{
LinkAttrs: netlink.LinkAttrs{
Name: contVethName,
Flags: net.FlagUp,
MTU: d.mtu,
},
PeerName: hostVethName,
}
netlink.LinkAdd(veth)
// host veth 给容器外的网卡设置MAC地址,状态设置为UP
hostVeth, err := netlink.LinkByName(hostVethName)
netlink.LinkSetHardwareAddr(hostVeth, "EE:EE:EE:EE:EE:EE")
netlink.LinkSetUp(hostVeth)
// container veth 给容器内的网卡设置MAC地址,IP地址,路由等
contVeth, err := netlink.LinkByName(contVethName)
// Fetch the MAC from the container Veth. This is needed by Calico.
contVethMAC = contVeth.Attrs().HardwareAddr.String()
if hasIPv4 {
// Add a connected route to a dummy next hop so that a default route can be set, 169.254.1.1在这里
gw := net.IPv4(169, 254, 1, 1)
gwNet := &net.IPNet{IP: gw, Mask: net.CIDRMask(32, 32)}
err := netlink.RouteAdd(
&netlink.Route{
LinkIndex: contVeth.Attrs().Index,
Scope: netlink.SCOPE_LINK,
Dst: gwNet,
},
)
for _, r := range routes {
ip.AddRoute(r, gw, contVeth)
}
}
if hasIPv6 {...}
}
// Now add the IPs to the container side of the veth.
for _, addr := range result.IPs {
netlink.AddrAdd(contVeth, &netlink.Addr{IPNet: &addr.Address})
}
// Now that the everything has been successfully set up in the container, move the "host" end of the
// veth into the host namespace. 将host端的网卡从容器移出去,配置路由
netlink.LinkSetNsFd(hostVeth, int(hostNS.Fd()))
}
// Moving a veth between namespaces always leaves it in the "DOWN" state. Set it back to "UP" now that we're
// back in the host namespace.
hostVeth, err := netlink.LinkByName(hostVethName)
netlink.LinkSetUp(hostVeth)
// Now that the host side of the veth is moved, state set to UP, and configured with sysctls, we can add the routes to it in the host namespace.
SetupRoutes(hostVeth, result) // 配置外界到容器的路由
...
}

github.com/vishvananda/netlink 提供 封装了系统调用,可以实现 ip link 命令的效果。

其它

Kubernetes Pod 如何获取 IP 地址 集群 CIDR 和 节点podCIDR: 如果要求所有 Pod 具有 IP 地址,那么就要确保整个集群中的所有 Pod 的 IP 地址是唯一的。这可以通过为每个节点分配一个唯一的子网(podCIDR)来实现,即从子网中为 Pod 分配节点 IP 地址。

Kube-controller-manager(配置了集群的CIDR) 为每个节点分配一个 podCIDR。从 podCIDR 中的子网值为节点上的 Pod 分配了 IP 地址。由于所有节点上的 podCIDR 是不相交的子网,因此它允许为每个 pod 分配唯一的IP地址。

CNI 配置文件的位置是可配置的,默认值为 /etc/cni/net.d/<config-file>。集群管理员需要在每个节点上交付 CNI 插件。CNI 插件的位置也是可配置的,默认值为 /opt/cni/bin

Kubernetes 集群管理员可配置和安装 kubelet、container runtime、network provider,并在每个节点上分发 CNI 插件。Network provider agent(比如flanneld) 启动时,将生成 CNI 配置(flannel 以pod 运行时,会有一个init 容器在所在节点 创建 /etc/cni/net.d/10-flannel.conflist 文件,当 Flanneld 启动时,它将从 apiserver 中获取 podCIDR 和其他与网络相关的详细信息,并将它们存储在文件中/run/flannel/subnet.env)。在节点上调度 Pod 后,kubelet 会调用 CRI 插件来创建 Pod。之后, CRI 插件调用 CNI 配置中指定的 CNI 插件来配置 Pod 网络。

参考资料