前端-css-01-CFANZ编程社区

k8s的flannel和cilium的pod网络访问链路解析

1. k8s环境中基础模型
2. flannel相关配置
3. 实际的ipip路由解析
- 3.1 veth-pair解析
- 3.2. node上的路由表
4. 疑问和思考
5. 参考文档

Kubernetes (K8s)的Pod网络访问要求可以根据应用程序的需要和安全策略而定，以下是一些常见的要求：

内部通信：Pod之间需要能够相互通信，通常在同一个Kubernetes集群或命名空间中的Pod可以直接通过其网络地址进行通信。
外部访问：Pod可能需要从集群外部的网络访问，这可以通过创建一个Service对象来实现。Service对象可以公开Pod的网络端口，使其能够从集群外部被访问。

本文经过简单分析和研究k8s环境下，pod访问之间的网络模型，并探讨各类网络模型下的协议和相关的优劣。

k8s的svc流量通过iptables和ipvs转发到pod的流程解析

1. k8s环境中基础模型

Kubernetes (K8s)的Pod网络访问要求可以根据应用程序的需要和安全策略而定，以下是一些常见的要求：

内部通信：Pod之间需要能够相互通信，通常在同一个Kubernetes集群或命名空间中的Pod可以直接通过其网络地址进行通信。
外部访问：Pod可能需要从集群外部的网络访问，这可以通过创建一个Service对象来实现。Service对象可以公开Pod的网络端口，使其能够从集群外部被访问。

因此常见的网络模型有如下几种

虚拟网桥
多路复用
硬件交换

1.1. Pod接入网络的具体实现

1.1.1. 虚拟网桥

虚拟网桥：
brdige，用纯软件的方式实现一个虚拟网络，用一个虚拟网卡接入到我们虚拟网桥上去。这样就能保证每一个容器和每一个pod都能有一个专用的网络接口，从而实现每一主机组件有网络接口。每一对网卡一半留在pod之上一半留在宿主机之上并接入到网桥中。甚至能接入到真实的物理网桥上能顾实现物理桥接的方式。

在这里插入图片描述

1.1.2. 多路复用

MacVLAN，基于mac的方式去创建vlan，为每一个虚拟接口配置一个独有的mac地址，使得一个物理网卡能承载多个容器去使用。这样子他们就直接使用物理网卡并直接使用物理网卡中的MacVLAN机制进行跨节点之间进行通信了。需要借助于内核级的VLAN模块来实现。
在这里插入图片描述

1.1.3. 硬件交换

使用支持单根IOV（SR-IOV）的方式，一个网卡支持直接在物理机虚拟出多个接口来，所以我们称为单根的网络连接方式，现在市面上的很多网卡都已经支持"单根IOV的虚拟化"了。它是创建虚拟设备的一种很高性能的方式，一个网卡能够虚拟出在硬件级多个网卡来。然后让每个容器使用一个网卡

在这里插入图片描述

1.2. 实现思路

对于任何一种第三方解决方案来说，如果它要实现k8s集群内部多节点间的pod通信都要从三个方面来实现：

构建一个网络
将pod接入到这个网络中
实时维护所有节点上的路由信息，实现隧道的通信

1.2.1. 流程图

在这里插入图片描述

所有节点的内核都启用了VXLAN的功能模块，每个节点都有一个唯一的编号
节点内部的pod的跨节点通信需要借助于VXLAN内部的路由机制或隧道转发机制实现通信
每个cni0上维护了各个节点所在的隧道网段的路由列表
node上的pod发出请求到达cni0，根据内核的路由列表判断对端网段的节点在哪里
然后经由隧道设备对数据包进行封装标识，接下来对端节点的隧道设备解封标识数据包，
当前数据包一看当前节点的路由表发现有自身的ip地址，这直接交给本地的pod
多个节点上的路由表信息维护，就是各种网络解决方案的工作位置

1.2.2 常见插件

根据我们刚才对pod通信的回顾，多节点内的pod通信，k8s是通过CNI接口来实现网络通信的。CNI基本思想：创建容器时，先创建好网络名称空间，然后调用CNI插件配置这个网络，而后启动容器内的进程

CNI插件类别：main、meta、ipam

main，实现某种特定的网络功能，如loopback、bridge、macvlan、ipvlan
meta，自身不提供任何网络实现，而是调用其他插件，如flanne
ipam，仅用于分配IP地址，不提供网络实现

常见的CNI解决方案有：

Flannel
提供叠加网络，基于linux TUN/TAP，使用UDP封装IP报文来创建叠加网络，并借助etcd维护网络分配情况
Calico
基于BGP的三层网络，支持网络策略实现网络的访问控制。在每台机器上运行一个vRouter，利用内核转发数据包，并借助iptables实现防火墙等功能
Canal
由Flannel和Calico联合发布的一个统一网络插件，支持网络策略
Weave Net
多主机容器的网络方案，支持去中心化的控制平面，数据平面上，通过UDP封装实现L2 Overlay
Contiv
思科方案，直接提供多租户网络，支持L2(VLAN)、L3(BGP)、Overlay(VXLAN)
kube-router
K8s网络一体化解决方案，可取代kube-proxy实现基于ipvs的Service，支持网络策略、完美兼容BGP的高级特性

2. flannel相关配置

2.1. 集群节点的网络分配

# 插件配置文件
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16", # flannel网段
      "Backend": {
        "Type": "vxlan"  # 使用vxlan模式
      }
    }

flannel启动程序的命令
      containers:
      - args:
        - --ip-masq          # 使用IP伪装
        - --kube-subnet-mgr  # 使用kube-apiServer管理子网

2.2 各节点flannel分配情况

master1 ~]# ifconfig 
cni0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.244.0.1  netmask 255.255.255.0  broadcast 10.244.0.255
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.0.0  netmask 255.255.255.255  broadcast 0.0.0.0

master2 ~]# ifconfig 
cni0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.244.1.1  netmask 255.255.255.0  broadcast 10.244.1.255
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.1.0  netmask 255.255.255.255  broadcast 0.0.0.0

master3 ~]# ifconfig 
cni0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.244.2.1  netmask 255.255.255.0  broadcast 10.244.2.255
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.2.0  netmask 255.255.255.255  broadcast 0.0.0.0

node1 ~]# ifconfig 
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.3.1  netmask 255.255.255.0  broadcast 10.244.3.255
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

node2 ~]# ifconfig 
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.4.1  netmask 255.255.255.0  broadcast 10.244.4.255
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.244.4.0  netmask 255.255.255.255  broadcast 0.0.0.0

2.3 flannel运行方式

# k8s节点上所有节点都运行了flannel容器
]# kubectl get pod -n kube-system -o wide| grep -i flannel
kube-flannel-ds-82rw8             1/1     Running   0               15d   192.168.10.26   master1   <none>           <none>
kube-flannel-ds-pdlnk             1/1     Running   0               15d   192.168.10.30   node2     <none>           <none>
kube-flannel-ds-w294q             1/1     Running   0               15d   192.168.10.27   master2   <none>           <none>
kube-flannel-ds-x6clp             1/1     Running   0               15d   192.168.10.28   master3   <none>           <none>
kube-flannel-ds-z4bgg             1/1     Running   1 (2d19h ago)   15d   192.168.10.29   node1     <none>           <none>

kube-apiserver为了更方便后续 flannel与etcd 直接的交流，单独分配一个url用于flannel和etcd的交流 – 在二进制部署集群中可以看到效果。

2.4. Flannel模型分类

模型	解析
vxlan	VXLAN使用UDP封装虚拟网络数据包，并在数据包中添加一个VXLAN头部。pod与Pod经由隧道封装后通信，各节点彼此间能通信就行，不要求在同一个二层网络vxlan
ipip	IPIP是一种隧道技术，用于在IP网络中封装IP数据包，它允许将IP数据包传输到另一个IP网络。pod与Pod经由隧道封装后通信，各节点彼此间能通信就行，不要求在同一个二层网络vxlan
直连路由	位于同一个二层网络上的、但不同节点上的Pod间通信，无须隧道封装；但非同一个二层网络上的节点上的Pod间通信，仍须隧道封装
host-gw	od与Pod不经隧道封装而直接通信，要求各节点位于同一个二层网络

2.4.1. vxlan模型

节点上的pod通过虚拟网卡，连接到cni0的虚拟网络交换机上,当有外部网络通信的时候，借助于 flannel.1网卡向外发出数据包
经过 flannel.1 网卡的数据包，借助于flanneld实现数据包的封装和解封最后送给宿主机的物理接口，发送出去
对于pod来说，它以为是通过 flannel.x -> vxlan tunnel -> flannel.x 实现数据通信
因为它们的隧道标识都是".1"，所以认为是一个vxlan，直接路由过去了，没有意识到底层的通信机制。

2.4.2. host-gw模型

根据我们当前的实践来说，所有集群中的主机节点处于同一个可以直接通信的二层网络，本来就可以直接连通，那么还做二层的数据包封装，pod通信效率会非常差，所以flannel就出现了host-gw的通信模式。

在这里插入图片描述

节点上的pod通过虚拟网卡，连接到cni0的虚拟网络交换机上。
pod向外通信的时候，到达CNI0的时候，不再直接交给flannel.1由flanneld来进行打包处理了。
cni0直接借助于内核中的路由表，通过宿主机的网卡交给同网段的其他主机节点
对端节点查看内核中的路由表，发现目标就是当前节点，所以交给对应的cni0，进而找到对应的pod。

2.4.3. 直连路由

在这里插入图片描述

pod向外通信的时候，到达CNI0的时候，不再直接交给flannel.1由flanneld来进行打包处理了。
如果两个pod不是处于同一网段，那么还是通过源始的方式进行正常的隧道封装通信。
如果两个pod是处于同一网段内。
cni0直接借助于内核中的路由表，通过宿主机的网卡交给同网段的其他主机节点
对端节点查看内核中的路由表，发现目标就是当前节点，所以交给对应的cni0，进而找到对应的pod

2.4.4. ipip

如果 Kubernetes 集群的节点不在同一个子网里，没法通过二层网络把 IP 包发送到下一跳地址，这种情景下就可以使用 IPIP 模式。
在这里插入图片描述
我们理一下网络数据包如何从节点 1 上的 Pod A（IP 172.25.0.130）到达节点 2 上的 Pod B（IP 172.25.0.195）中：

首先看一下 Pod A 的网络栈：

$ nsenter -n -t ${PID}
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether 92:6b:a2:6b:c8:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.25.0.130/32 scope global eth0
    valid_lft forever preferred_lft forever
$ ip route
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link

在 Pod A 中访问 Pod B 中的服务，目的 IP 为 172.25.0.195，数据包根据默认路由来到容器的 eth0 网卡上，即 Veth Pair 在容器内的一端。169.254.1.1 这个 IP 地址写死在 Calico 项目的代码中，使用 Calico 网络插件的 Kubernetes 集群中所有容器的路由表都一样。

切换到宿主机视角：

$ ip route
default via 10.211.55.1 dev eth0 proto dhcp metric 100
10.211.55.0/24 dev eth0 proto kernel scope link src 10.211.55.101 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
blackhole 172.25.0.128/26 proto bird
172.25.0.129 dev calib17705e4170 scope link
172.25.0.130 dev calibfd619d4ca3 scope link
172.25.0.131 dev cali35a4ac9a8fc scope link
172.25.0.192/26 via 10.211.55.116 dev tunl0 proto bird onlink

当目的 IP 为 172.25.0.195 的数据包来到 Veth Pair 在宿主机的一端，将命中最后一条路由 172.25.0.192/26 via 10.211.55.116 dev tunl0 proto bird onlink（毫无疑问是 Calico 网络插件创建出来的），下一跳 IP 地址是 10.211.55.116，也就是 Pod B 所在的节点 2，发送数据包的设备叫 tunl0，这是一个 IP 隧道。

ipip
数据包到达 IP 隧道设备后，Linux 内核将它封装进一个宿主机网络的 IP 包中，并通过宿主机的 eth0 网卡发送出去。IPIP 数据包到达节点 2 的 eth0 网卡后，内核将拆开 IPIP 封包，拿到原始的数据包。

$ ip route
default via 10.211.55.1 dev eth0 proto dhcp metric 100
10.211.55.0/24 dev eth0 proto kernel scope link src 10.211.55.116 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.25.0.128/26 via 10.211.55.101 dev tunl0 proto bird onlink
blackhole 172.25.0.192/26 proto bird
172.25.0.193 dev calif94e20e3327 scope link
172.25.0.194 dev cali96e8aac71b5 scope link
172.25.0.195 dev calid74ab5d8f78 scope link

目的 IP 为 172.25.0.195 数据包根据路由表前往名为 calid74ab5d8f78 的 Veth Pair 设备，并流向容器内的另一端。

以上参与全过程的网络设备和路由规则。

3. 实际的ipip路由解析

获取flannel的网络配置

kubectl -n kube-system get cm kube-flannel-cfg -oyaml 
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "192.168.0.0/16",
      "Backend": {
        "Type": "ipip"
      }
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2022-08-03T15:22:25Z"
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
  resourceVersion: "11676"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
  uid: d71f425c-ce5c-4438-84ec-907a29e53a59

# 单台机器的网段配置
# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=192.168.0.0/16
FLANNEL_SUBNET=192.168.2.1/24
FLANNEL_MTU=1480
FLANNEL_IPMASQ=true
[root@tcs-10.100.0.155 ~]#

我们选择一台服务器的podip以及相关路由关系进行网络分析。

auth                 authn-6bb476f54c-ccsfk                                        1/1     Running                      0          31h     192.168.2.189    10.100.0.155   <none>           <none>
tcs-global-monitor   prometheus-kube-prometheus-stack-prometheus-0                     3/3     Running                      1          13d     192.168.2.176    10.100.0.155   <none>           <none>
tcs-system           localpv-csi-loopdevice-plugin-bbhf9                               5/5     Running                      0          13d     192.168.2.175    10.100.0.155   <none>           <none>
tke                  tke-gateway-w7m28                                                 1/1     Running                      0          13d     192.168.2.177    10.100.0.155   <none>           <none>

3.1 veth-pair解析

如下配置是相关的容器veth-pair

192.168.2.175   0.0.0.0         255.255.255.255 UH    0      0        0 v-he029917d6
192.168.2.176   0.0.0.0         255.255.255.255 UH    0      0        0 v-hf2692edc1
192.168.2.177   0.0.0.0         255.255.255.255 UH    0      0        0 v-hf709b40f4
192.168.2.189   0.0.0.0         255.255.255.255 UH    0      0        0 v-hafdc9b6c6

# ip link show
355: v-he029917d6@if354: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 16:fa:a5:51:b4:c0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
357: v-hf2692edc1@if356: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP mode DEFAULT group default 
    link/ether da:26:39:ca:cb:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 1
359: v-hf709b40f4@if358: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 0a:4f:52:48:37:ce brd ff:ff:ff:ff:ff:ff link-netnsid 2
383: v-hafdc9b6c6@if382: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP mode DEFAULT group default 
    link/ether d6:6c:fc:20:2d:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 3

查看相关容器的网络配置

# kubectl -n tcs-system exec -it localpv-csi-loopdevice-plugin-bbhf9   -c plugin bash 
[root@localpv-csi-loopdevice-plugin-bbhf9 /]# cat /sys/class/net/eth0/iflink 
355
[root@localpv-csi-loopdevice-plugin-bbhf9 /]# 
[root@localpv-csi-loopdevice-plugin-bbhf9 /]# route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         169.254.1.1     0.0.0.0         UG    0      0        0 eth0
169.254.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 eth0

355对应v-he029917d6@if354 网卡，结合容器中的的路由表，可以获知，在容器中发送的流量会通过eth0网卡发送出来，并通过v-he029917d6@if354发送到对应的node节点。

3.2. node上的路由表

[root@tcs-10.100.-0-155 ~]# route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.100..0.129     0.0.0.0         UG    0      0        0 bond1
10.0.0.0        10.100..0.129     255.0.0.0       UG    0      0        0 bond1
10.100..0.128     0.0.0.0         255.255.255.128 U     0      0        0 bond1
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 bond1
192.168.0.0     10.100..0.159     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.0.0     10.100..0.129     255.255.0.0     UG    0      0        0 bond1
192.168.1.0     10.100..0.152     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.2.175   0.0.0.0         255.255.255.255 UH    0      0        0 v-he029917d6
192.168.2.176   0.0.0.0         255.255.255.255 UH    0      0        0 v-hf2692edc1
192.168.2.177   0.0.0.0         255.255.255.255 UH    0      0        0 v-hf709b40f4
192.168.2.189   0.0.0.0         255.255.255.255 UH    0      0        0 v-hafdc9b6c6
192.168.3.0     10.100..0.156     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.4.0     10.100..0.31      255.255.255.0   UG    0      0        0 flannel.ipip
192.168.5.0     10.100..0.170     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.6.0     10.100..0.27      255.255.255.0   UG    0      0        0 flannel.ipip
192.168.7.0     10.100..0.171     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.16.0    10.100..0.29      255.255.255.0   UG    0      0        0 flannel.ipip
192.168.17.0    10.100..0.33      255.255.255.0   UG    0      0        0 flannel.ipip
192.168.18.0    10.100..0.161     255.255.255.0   UG    0      0        0 flannel.ipip
192.168.19.0    10.100..0.164     255.255.255.0   UG    0      0        0 flannel.ipip

通过该路由表可知

如果是相同节点上的不同pod通信，会命中v-hafdc9b6c6相关路由表，在节点内部转发
如果是不同节点之间的不同pod通信，会命中flannel.ipip相关路由表，通过flannel.ipip并进行ipip封包转发到其他的服务器，对端服务器接收到相关的流量包后，会进行ipip解包。
如果是不同节点之间的pod/node通信，会命中bond1相关路由表，并通过bond1转发到对应的服务器

因此k8s通过这样的cni插件，将复杂的overlay-underlay网络模型，转化成简单的underlay网络模型，并通过underlay机器的路由表指引相关网络包的发送、接受。