Kubernetes 网络架构及相关网卡

前言

因为 Kubernetes 的网络可以使用第三方网络插件，所以给我们提供了多样化的网络解决方案，让我们可以根据自身情况选择自己需要的网络方案。

CNM & CNI 阵营：

容器网络发展到现在，形成了两大阵营，就是 Docker 的 CNM 和 Google、CoreOS、Kuberenetes 主导的 CNI。首先明确一点，CNM 和 CNI 并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用 Flannel 也好、用 Calico 也好，他们并不关心，CNM 和 CNI 关心的是网络管理的问题。
CNM (Docker LibnetworkContainer Network Model)
CNI（Container Network Interface）

Kubernetes 网络设计模型：

在 Kubernetes 网络中存在两种 IP（Pod IP 和 Service Cluster IP），Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP 它是一个虚拟 IP，是由 kube-proxy 使用 Iptables 规则重新定向到其本地端口，再均衡到后端 Pod 的。

基本原则：

每个 Pod 都拥有一个独立的 IP 地址（IPper Pod），而且假定所有的 pod 都在一个可以直接连通的、扁平的网络空间中。

设计原因：

用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑将容器端口映射到主机端口等问题。

网络要求：

所有的容器都可以在不用 NAT 的方式下同别的容器通讯；所有节点都可在不用 NAT 的方式下同所有容器通讯；容器的地址和别人看到的地址是同一个地址。

K8S 网络主要解决以下网络通信问题：

同一 pod 下容器与容器的通信；
同一节点下不同的 pod 之间的容器间通信；
不同节点下容器之间的通信；
集群外部与内部组件的通信；
pod 与 service 之间的通信；

1、容器间通信：

同一个 Pod 的容器共享同一个网络命名空间，它们之间的访问可以用

localhost 地址 + 容器端口就可以访问。

2、同一 Node 中 Pod 间通信：

同一 Node 中 Pod 的默认路由都是 docker0 的地址，由于它们关联在同一个 docker0（cni0）网桥上，地址网段相同，所有它们之间应当是能直接通信的。

3、不同 Node 中 Pod 间通信：

不同 Node 中 Pod 间通信要满足 2 个条件：

*Pod 的 IP 不能冲突*； 将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让 Pod 可以互相访问。所以就要用到 flannel 或者 calico 的网络解决方案。

对于此场景，情况现对比较复杂一些，这就需要解决 Pod 间的通信问题。在 Kubernetes 通过 flannel、calico 等网络插件解决 Pod 间的通信问题。以 flannel 为例说明在 Kubernetes 中网络模型，flannel 是 kubernetes 默认提供网络插件。Flannel 是由 CoreOs 团队开发社交的网络工具，CoreOS 团队采用 L3 Overlay 模式设计 flannel，规定宿主机下各个 Pod 属于同一个子网，不同宿主机下的 Pod 属于不同的子网。

查看宿主机网卡

1 packet dropped by kernel
[root@node12 /]# ifconfig
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.3.1  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::1c39:e0ff:fefd:bc01  prefixlen 64  scopeid 0x20<link>
        ether 1e:39:e0:fd:bc:01  txqueuelen 1000  (Ethernet)
        RX packets 215461844  bytes 49255741900 (45.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210219198  bytes 99380196541 (92.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:3a:fe:ce:d7  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 18.16.200.142  netmask 255.255.255.0  broadcast 18.16.200.255
        inet6 fe80::4e56:dbf1:fdb1:bbd9  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:fb:f2:44  txqueuelen 1000  (Ethernet)
        RX packets 271704820  bytes 128411272052 (119.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 234410728  bytes 75423059029 (70.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.3.0  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::8087:1ff:fe29:ed7c  prefixlen 64  scopeid 0x20<link>
        ether 82:87:01:29:ed:7c  txqueuelen 0  (Ethernet)
        RX packets 52059332  bytes 8640899916 (8.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38918760  bytes 6548881752 (6.0 GiB)
        TX errors 0  dropped 20 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 23487  bytes 1343648 (1.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 23487  bytes 1343648 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth0b52cfb8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet6 fe80::bca4:22ff:fea7:349  prefixlen 64  scopeid 0x20<link>
        ether be:a4:22:a7:03:49  txqueuelen 0  (Ethernet)
        RX packets 5345585  bytes 2672632806 (2.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5451377  bytes 3371977575 (3.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth3867ca45: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet6 fe80::7035:a5ff:fecd:e4d0  prefixlen 64  scopeid 0x20<link>
        ether 72:35:a5:cd:e4:d0  txqueuelen 0  (Ethernet)
        RX packets 4210336  bytes 3083434674 (2.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4364899  bytes 5908811645 (5.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0网卡

Docker 安装时会自动在 host 上创建三个网络：none，host，和bridge；详细说明可参考其它文档。

我们可用 docker network ls 命令查看：

[root@node12 /]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
0ee6eb650f66        bridge              bridge              local
30a3e66f751c        host                host                local
2d1ae28eb78b        none                null                local

基于DRIVER是bridge的网络都会有一个对应的linux bridge被创建：

在默认环境中，一个名为docker0的linux bridge自动被创建好了，其上有一个 docker0 内部接口，IP地址为172.17.0.1/16(掩码为255.255.0.0)

再用docker network inspect指令查看bridge网络：其Gateway就是网卡/接口docker0的IP地址：172.17.0.1。

[root@node12 /]# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "0ee6eb650f66797ca4dde49db3985a4006affdf69f2e208791e11dd3f977a9ab",
        "Created": "2019-12-27T09:25:56.921594934+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

这时就会出现如何识别docker0的虚拟网卡和容器的对应关系，例如，图示中有两个容器和docker0中的两个接口：

安装Linux网桥管理工具bridge-utils

[root@node12 /]# yum install bridge-utils

[root@node12 /]# brctl show
bridge name	bridge id		STP enabled	interfaces
docker0         8000.3a1d7362b4ee       no              veth65f9
                                             vethdda6
                                             vetha596

flannel网络

flannel简介

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。

Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

Flannel实质上是一种“覆盖网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式，默认的节点间数据通信方式是UDP转发。

flannel网络

flannel 的 IP 地址是通过 Etcd 管理的，在 k8s 初始化的时候指定 pod 大网的网段 --pod-network-cidr=10.244.0.0/16，flanneld 可以直接通过 Etcd 管理，如果启动的时候指定了 --kube-subnet-mgr，可以直接通过 k8s 的 apiserver 来获得一个小网段的租期，通过 kubectl get -o jsonpath='{.spec.podCIDR}' 可以获取对应节点的 CIDR 表示的网段，flannel 是以节点为单元划分小网段的，每个节点上的 pod 在这个例子当中是划分一个 10.244.x.0/24 的网段，所以总共能分配 255 个节点，每个节点上可以分配 253 个 pod。结构如下图所示，每个节点上都会有一个 flanneld 用于管理自己网段的租期。

可以通过在 host 上 cat /run/flannel/subnet.env 查看同步下来的信息，例如：

[root@node12 /]# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.3.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

说明当前节点分配的网段是 10.244.0.1/24。在每个节点上因为已经确定了网段，用 ipam 就可以管理这一范围 ip 地址的分配，所以本身 pod 的 IP 分配和中心 Etcd 没有太多联系。

容器间跨宿主如何运行

如下图所示，集群范围内的网络地址空间为10.1.0.0/16，Machine A获取的subnet为10.1.15.0/24，且其中的两个容器IP分别为10.1.15.2/24和10.1.15.3/24，两者都在10.1.15.0/24这一子网范围内，对于下方的Machine B同理。

如果上方Machine A中IP地址为10.1.15.2/24的容器要与下方Machine B中IP地址为10.1.16.2/24的容器进行通信，封包是如何进行转发的。从上文可知，每个主机的flanneld会将自己与所获取subnet的关联信息存入etcd中，例如，subnet 10.1.15.0/24所在主机可通过IP 192.168.0.100访问，subnet 10.1.16.0/24可通过IP 192.168.0.200访问。反之，每台主机上的flanneld通过监听etcd，也能够知道其他的subnet与哪些主机相关联。如上图，Machine A上的flanneld通过监听etcd已经知道subnet 10.1.16.0/24所在的主机可以通过Public 192.168.0.200访问，而且熟悉docker桥接模式的同学肯定知道，目的地址为10.1.16.2/24的封包一旦到达Machine B，就能通过cni0网桥转发到相应的pod，从而达到跨宿主机通信的目的。

因此，flanneld只要想办法将封包从Machine A转发到Machine B就OK了，而上文中的backend就是用于完成这一任务。不过，达到这个目的的方法是多种多样的，所以我们也就有了很多种backend. 在这里我们举例介绍的是最简单的一种方式hostgw : 因为Machine A和Machine B处于同一个子网内，它们原本就能直接互相访问。因此最简单的方法是：在Machine A中的容器要访问Machine B的容器时，我们可以将Machine B看成是网关，当有封包的目的地址在subnet 10.1.16.0/24范围内时，就将其直接转发至B即可。而这通过图中那条红色标记的路由就能完成，对于Machine B同理可得。由此，在满足仍有subnet可以分配的条件下，我们可以将上述方法扩展到任意数目位于同一子网内的主机。而任意主机如果想要访问主机X中subnet为S的容器，只要在本主机上添加一条目的地址为R，网关为X的路由即可。

veth网卡

Linux container 中用到一个叫做veth的东西，这是一种新的设备，专门为 container 所建。veth 从名字上来看是 Virtual ETHernet 的缩写，它的作用很简单，就是要把从一个 network namespace 发出的数据包转发到另一个 namespace。veth 设备是成对的，一个是 container 之中，另一个在 container 之外，即在真实机器上能看到的。
VETH设备总是成对出现，送到一端请求发送的数据总是从另一端以请求接受的形式出现。创建并配置正确后，向其一端输入数据，VETH会改变数据的方向并将其送入内核网络子系统，完成数据的注入，而在另一端则能读到此数据。（Namespace，其中往veth设备上任意一端上RX到的数据，都会在另一端上以TX的方式发送出去）veth工作在L2数据链路层，veth-pair设备在转发数据包过程中并不串改数据包内容。

veth设备特点

veth和其它的网络设备都一样，一端连接的是内核协议栈
veth设备是成对出现的，另一端两个设备彼此相连
一个设备收到协议栈的数据发送请求后，会将数据发送到另一个设备上去

cni0网卡

查看cni0网卡对应的桥接网卡

[root@node12 /]# brctl show
bridge name	bridge id		STP enabled	interfaces
cni0		8000.1e39e0fdbc01	no		veth07cd1879
							veth0b52cfb8
							veth4238d279
							veth6389b6d5
							veth724d6510
							veth78b32a65
							veth96aa8f2a
							vethad79f5c0
							vethb4ae9fae
							vethcaba2513
							vethd9bb4726