当前位置：首页 > article >正文

Kubernetes中的网络通信

article 2024/11/13 3:35:31

华子目录

k8s通信整体架构
- 容器间通信
`flannel`网络插件组成
`flannel`跨`node主机`通信原理
- 什么是`fdb`
- `arp -n`
- `ip r`
`flannel`支持的`后端模式`
- 更改`flannel`的默认模式
`calico`网络插件
- `calico`简介
- `calico`网络架构
- 部署`calico`

k8s通信整体架构

k8s通过cni接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等
cni插件存放位置：/etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下
- 虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
- 多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
- 硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
容器间通信：
- 同一个pod内的多个容器间的通信，通过lo即可实现pod之间的通信
- 同一node节点的pod之间通过cni网桥转发数据包
- 不同node节点的pod之间的通信需要网络插件支持
pod和service通信：通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换
pod和外网通信：iptables的MASQUERADE
Service与集群外部用户的通信；（ingress、nodeport、loadbalancer）

[root@k8s-master net.d]# cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

容器间通信

同一个pod内的多个容器间的通信，通过lo即可实现pod之间的通信
同一node节点的pod之间通过cni网桥转发数据包
不同node节点的pod之间的通信需要网络插件支持

`flannel`网络插件组成

插件	功能
`vxlan`	即`Virtual Extensible LAN`（`虚拟可扩展局域网`），是`Linux`本身支持的一`网络虚拟化技术`。`VXLAN`可以完全`在内核态`实现`封装`和`解封装`工作，从而通过“`隧道`”机制，构建出`覆盖网络`（`Overlay Network`）
`vtep`	`VXLAN Tunnel End Point`（`虚拟隧道端点`），在`Flannel`中`vni`的默认值是`1`，这也是为什么宿主机的`VTEP`设备都叫`flannel.1`的原因
`cni0`	`网桥设备`，每创建一个`pod`都会创建一对`veth pair`。其中`一端`是`pod`中的`eth0`，另一端是`cni0`网桥中的`端口`（`网卡`）
`flannel.1`	`TUN`设备（`虚拟网卡`)，用来进行`vxlan报文`的`处理`（`封包`和`解包`）。不同`node主机`之间的`pod`数据`流量`都从`overlay设备`以`隧道`的`形式`发送到`对端`
`flanneld`	`flannel`在每个`主机`中运行`flanneld`作为`agent`，它会为`所在主机`从`集群`的`网络地址空间`中，获取一个`小`的`网段subnet`，`本主机内`所有`容器`的`IP地址`都将从中分配。同时`Flanneld`监听`K8s`集群`数据库`，为`flannel.1`设备提供`封装数据`时必要的`mac、ip`等`网络数据信息`

`flannel`跨`node主机`通信原理

在这里插入图片描述

当容器发送IP包，通过veth pair发往cni0网桥，再路由到本机的flannel.1设备进行处理
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理，flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器

什么是`fdb`

[root@k8s-master ~]# bridge fdb
01:00:5e:00:00:01 dev eth0 self permanent
33:33:00:00:00:01 dev docker0 self permanent
02:42:5a:2b:82:e1 dev docker0 vlan 1 master docker0 permanent
02:42:5a:2b:82:e1 dev docker0 master docker0 permanent
33:33:00:00:00:01 dev kube-ipvs0 self permanent
da:59:8b:26:3e:05 dev flannel.1 dst 172.25.254.20 self permanent
33:33:00:00:00:01 dev cni0 self permanent
a6:dd:38:df:df:5c dev cni0 vlan 1 master cni0 permanent
a6:dd:38:df:df:5c dev cni0 master cni0 permanent
a6:29:c3:54:b9:fe dev veth7f0d7ac0 master cni0
6a:f2:b6:53:9b:59 dev veth7f0d7ac0 vlan 1 master cni0 permanent
6a:f2:b6:53:9b:59 dev veth7f0d7ac0 master cni0 permanent
33:33:00:00:00:01 dev veth7f0d7ac0 self permanent
5a:d1:57:a3:cf:de dev vethda65673e master cni0
66:e3:ad:de:12:17 dev vethda65673e vlan 1 master cni0 permanent
66:e3:ad:de:12:17 dev vethda65673e master cni0 permanent
33:33:00:00:00:01 dev vethda65673e self permanent

这段命令输出是关于Linux网络桥接（bridge）的转发数据库（FDB, Forwarding Database）的信息。在Linux中，桥接是一种将多个网络接口连接在一起，使它们能够像单个网络接口一样工作的技术。FDB用于存储关于哪些MAC地址可以通过哪些端口（或接口）到达的信息

`arp -n`

[root@k8s-master ~]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.244.0.3               ether   5a:d1:57:a3:cf:de   C                     cni0
10.244.0.2               ether   a6:29:c3:54:b9:fe   C                     cni0
10.244.2.0               ether   da:59:8b:26:3e:05   CM                    flannel.1
172.25.254.10            ether   00:0c:29:db:48:d7   C                     eth0
172.25.254.1             ether   00:50:56:c0:00:08   C                     eth0
172.25.254.2             ether   00:50:56:e1:a6:ed   C                     eth0
10.244.1.0               ether   86:d8:ba:15:b9:0f   CM                    flannel.1
172.25.254.20            ether   00:0c:29:96:e7:67   C                     eth0

`ip r`

[root@k8s-master ~]# ip r
default via 172.25.254.2 dev eth0 proto static metric 100
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.25.254.0/24 dev eth0 proto kernel scope link src 172.25.254.100 metric 100

`flannel`支持的`后端模式`

网络模式	功能
`vxlan`	`报文封装`，`默认模式`
`Directrouting`	`直接路由`，`跨网段`使用`vxlan`，`同网段`使用`host-gw`模式
`host-gw`	`主机网关`，`性能好`，但`只能`在`二层网络`中，`不支持跨网络`，如果有`成千上万`的`Pod`，容易产生`广播风暴`，`不推荐`
`UDP`	`性能差`，`不推荐`

更改`flannel`的默认模式

[root@k8s-master ~]# kubectl -n kube-flannel edit cm kube-flannel-cfg

在这里插入图片描述
如果是host-gw模式，则cni会直接接到宿主机的eth0上

#删除之前模式的pod，它会重新自动创建新的pod
[root@k8s-master ~]# kubectl -n kube-flannel delete pods --all
pod "kube-flannel-ds-m7ksl" deleted
pod "kube-flannel-ds-q55gr" deleted
pod "kube-flannel-ds-twvv4" deleted

#我们发现接到`宿主机的eth0`上了
[root@k8s-master ~]# ip r
default via 172.25.254.2 dev eth0 proto static metric 100
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 172.25.254.10 dev eth0
10.244.2.0/24 via 172.25.254.20 dev eth0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.25.254.0/24 dev eth0 proto kernel scope link src 172.25.254.100 metric 100

`calico`网络插件

官网：https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises

`calico`简介

纯三层的转发，中间没有任何的NAT和overlay，转发效率最好
Calico仅依赖三层路由可达。Calico较少的依赖性使它能适配所有VM、Container、白盒或者混合环境场景

`calico`网络架构

在这里插入图片描述

Felix：监听etcd中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里

部署`calico`

删除flannel插件

[root@k8s-master ~]# kubectl delete -f kube-flannel.yml
namespace "kube-flannel" deleted
serviceaccount "flannel" deleted
clusterrole.rbac.authorization.k8s.io "flannel" deleted
clusterrolebinding.rbac.authorization.k8s.io "flannel" deleted
configmap "kube-flannel-cfg" deleted
daemonset.apps "kube-flannel-ds" deleted

删除所有节点上flannel配置文件，避免冲突

[root@k8s-master ~]# rm -rf /etc/cni/net.d/10-flannel.conflist

[root@k8s-node1 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist

[root@k8s-node2 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist

上传calico相关的文件

[root@k8s-master ~]# mkdir network
[root@k8s-master ~]# cd network/

在这里插入图片描述

[root@k8s-master network]# ls
calico-3.28.1.tar  calico.yaml

在这里插入图片描述

[root@k8s-master network]# docker load  -i calico-3.28.1.tar
6b2e64a0b556: Loading layer   3.69MB/3.69MB
38ba74eb8103: Loading layer  205.4MB/205.4MB
5f70bf18a086: Loading layer  1.024kB/1.024kB
Loaded image: calico/cni:v3.28.1
3831744e3436: Loading layer  366.9MB/366.9MB
Loaded image: calico/node:v3.28.1
4f27db678727: Loading layer  75.59MB/75.59MB
Loaded image: calico/kube-controllers:v3.28.1
993f578a98d3: Loading layer  67.61MB/67.61MB
Loaded image: calico/typha:v3.28.1

[root@k8s-master network]# docker tag calico/typha:v3.28.1 harbor.huazi.org/calico/typha:v3.28.1
[root@k8s-master network]# docker tag calico/kube-controllers:v3.28.1 harbor.huazi.org/calico/kube-controllers:v3.28.1
[root@k8s-master network]# docker tag calico/cni:v3.28.1 harbor.huazi.org/calico/cni:v3.28.1
[root@k8s-master network]# docker tag calico/node:v3.28.1 harbor.huazi.org/calico/node:v3.28.1

[root@k8s-master network]# docker push harbor.huazi.org/calico/typha:v3.28.1
[root@k8s-master network]# docker push harbor.huazi.org/calico/kube-controllers:v3.28.1
[root@k8s-master network]# docker push harbor.huazi.org/calico/cni:v3.28.1
[root@k8s-master network]# docker push harbor.huazi.org/calico/node:v3.28.1

修改calico.yaml文件的所有的image的位置

[root@k8s-master network]# vim calico.yaml

在这里插入图片描述

修改calico.yaml文件中的部分配置

[root@k8s-master network]# vim calico.yaml

在这里插入图片描述

[root@k8s-master network]# kubectl apply -f calico.yaml


#我们发现calico已经运行成功
[root@k8s-master network]# kubectl -n kube-system get pods
NAME                                       READY   STATUS    RESTARTS       AGE
calico-kube-controllers-6849cb478c-8q6vp   1/1     Running   0              65s
calico-node-77vwx                          1/1     Running   0              65s
calico-node-mbxgp                          1/1     Running   0              65s
calico-node-nbnr8                          1/1     Running   0              65s
calico-typha-fff9df85f-q2679               1/1     Running   0              65s
coredns-6c7f6478d8-gplcq                   1/1     Running   10 (19h ago)   34d
coredns-6c7f6478d8-vcqg9                   1/1     Running   10 (19h ago)   34d
etcd-k8s-master.org                        1/1     Running   10 (19h ago)   34d
kube-apiserver-k8s-master.org              1/1     Running   6 (19h ago)    16d
kube-controller-manager-k8s-master.org     1/1     Running   11 (19h ago)   34d
kube-proxy-5t25b                           1/1     Running   7 (19h ago)    17d
kube-proxy-g4gsb                           1/1     Running   7 (19h ago)    17d
kube-proxy-wsrvk                           1/1     Running   7 (19h ago)    17d
kube-scheduler-k8s-master.org              1/1     Running   11 (19h ago)   34d

测试

[root@k8s-master network]# kubectl run testpod --image myapp:v1
pod/testpod created
[root@k8s-master network]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP               NODE            NOMINATED NODE   READINESS GATES
testpod   1/1     Running   0          8s    10.224.114.128   k8s-node1.org   <none>           <none>


[root@k8s-master network]# curl 10.224.114.128
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

[root@k8s-master network]# ip a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:69:89:08 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    altname ens160
    inet 172.25.254.100/24 brd 172.25.254.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4e21:e4b4:36e:6d14/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:28:10:42:60 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether ca:b5:36:8b:17:4b brd ff:ff:ff:ff:ff:ff
    inet 10.109.194.34/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 172.25.254.50/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.103.58.149/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.10/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.97.129.250/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.1/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.103.130.163/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:47:d2:9c:c3:c9 brd ff:ff:ff:ff:ff:ff
    inet 10.244.0.1/24 brd 10.244.0.255 scope global cni0
       valid_lft forever preferred_lft forever
    inet6 fe80::b847:d2ff:fe9c:c3c9/64 scope link
       valid_lft forever preferred_lft forever
6: veth92b05de3@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni0 state UP group default
    link/ether 8a:fb:29:9c:6b:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::88fb:29ff:fe9c:6b04/64 scope link
       valid_lft forever preferred_lft forever
7: veth676b78d0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni0 state UP group default
    link/ether 62:f2:ff:c2:13:5a brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::60f2:ffff:fec2:135a/64 scope link
       valid_lft forever preferred_lft forever