K8S集群CNI网络插件之Flannel底层原理

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

目录

一.CNI网络插件概述

1.配置容器网络接口方案

不同的容器虚拟化网络解决方案中Pod网络名称空间创建虚拟接口设备的方式也会有所不同。

目前，较为主流的视线方式有: 虚拟网桥设备，多路复用及硬件交换三种。
    虚拟网桥(bridge): + 虚拟网卡对:
        创建一个网桥，并为每个容器创建一对虚拟以太网接口(veth)。
        一个接入容器内部，另一个留置于根名称空间内添加为Linux内核桥接功能或OpenVSwitch(OVS)网桥的从设备。

    多路复用 + 内核级的VALN模块:
    	多路复用可以由一个中间网络设备组成，它暴露多个虚拟接口，使用数据包转发规则来控制每个数据包转到目标接口。
        借助与Linux内核级vlan模块，典型代表是MACVLAN,IPVLAN等技术。
        	- MACVLAN:
        		为每个虚拟接口配置一个MAC地址并基于此地址完成二次报文收发。
        	- IPVLAN:
        		分配一个IP地址并共享单个MAC并根据目标IP完成容器报文转发。
        说白了，就是在同一个物理网卡上配置多个mac地址，每个mac给一个pod使用，然后借助物理网卡传输数据。

    硬件交换 + 硬件虚拟化(使用虚拟子接口)
        现今市面上有很多NIC都支持单根I/O虚拟化(SR-IOV)，它是创建虚拟设备的一种实现方式。
        每个虚拟设备自身表现为一个独立的PCI设备，并有着自己的VLAN及硬件强制关联的QoS。
        SR-IOV提供了接近硬件级别的性能，直接在物理主机虚拟出多个接口。
        
        
容器网络方案:
	任何一种能够让容器自由通信的网络解决方案，必须包含三个功能:
		- 1.构建一个网络;
		- 2.将容器接入到这个网络中;
		- 3.实时维护所有节点上的路由信息，实现容器的通信;

2.CNI概述

CNI全称为"Contianer Network Interface"，Google和CoreOS公司联合定制的多容器通信网络模型。

其实，在没有诞生"CNI"之前，flannel就是早期的K8S容器跨主机网络主流的解决方案。

后来有了CNI规范后，诞生了一系列支持CNI的网络插件，用户部署网络插件选择会越来越多。

以Flannel为例，其包含以下3个典型功能:
    - 所有节点的内核都启用了VXlan（跨网段通信的解决方案）的功能模块
        - 1.每个节点都启动一个CNI网卡，并维护所有节点所在的网段的路由列表。

    - worker node的Pod发出请求到达cni0(虚拟网桥):
        - 1.根据内核的路由列表判断对端网络的节点位置;
        - 2.经由隧道设备对数据包进行封装标识，对端节点的隧道设备解封标识数据包;;
        - 3.当前数据包一看到当前节点的路由表发现有自身的IP地址，这直接交给本地的pod;

    - 多个节点上的路由表信息维护，就是各种网络解决方案的工作位置。

温馨提示:
	我们可以部署多个网络解决方案，但是对于CNI来说，只会有一个生效，如果网络信息过多会导致冲突。

3. Overlay 和Underlay对比

网络类型 Underlay Network (承载网络) Overlay Network(叠加网络)
描述 承载网络，是物理基础设置。【看得见，摸得着，比如路由器，交换机，服务器】 叠加网络，是一种虚拟网络，基于底层网络。【看不见，摸不着，比如网桥，虚拟机。】
传输媒介 面向硬件设备。【比如：交换机，路由器，光纤，...】 面相虚拟设备。【比如：网桥设备】
传输时是否封装报文 面向物理设备，无需封装。 面相虚拟设备，需要封装，如Vxlan，GRE，IpSec等。
应用程序隔离 将应用程序划分到不同的underlay非常复杂，需要配置底层网络。 非常容易完成。
多路径转发 多路径转发设置复杂 支持虚拟网络的多路径转发。
多租户管理 需要使用基于NAT或VRF的隔离，在大型环境中可能面临挑战。 能够管理多个租户之间的重叠IP地址。
可扩展性 由于依赖于硬件，可扩展性较低。 可扩展性更强，例如：VLAN提供4096个VLAN支持，而VXLAN提供多达1600+万(2^24)个标识符。
安全性 直接基于IP进行访问，因此安全性不高。 使用加密方法（如IPSec）可以很容易增加安全性。
部署时间 由于依赖硬件，需要单独远程设备配置，因此部署周期长。 直接修改软件的配置文件，部署时间短，添加和更改非常快。
包封装和开销 数据包传递和可靠性发生在L2和L3。 需要跨源地址和目的地址封装数据包，因此会产生额外的开销。 
NetPlugin目前常用的实现方案有叠加网络(Overlay Network)和承载网络(Underlay Network)两类。
	- Overlay Network:
		借助于VXLAN，UDP，IPIP或者GRE等隧道协议。
		通过隧道协议报文封装Pod间的通信报文(IP报文或以太网帧)来构建虚拟网络。
        
    - Underlay Network:
    	通常使用direct routing(直接路由)技术在Pod的各子网间路由Pod的IP报文。
    	使用bridge，macvlan或者ipvlan等技术直接将容器暴露至外部网络中。
	
	
Overlay Network的底层网络依然是Underlay Network:
	- 1.Underlay Network的解决方案也就是一类非借助于隧道协议而构建的容器通信网络;
	- 2.相较于Underlay Network，Overlay Network由于存在额外的隧道报文封装，会存在一定程度的性能开销;
	- 3.但希望创建跨越多个L2或者L3的逻辑子网时，只能借助于Overlay Network封装协议实现;
	
	
关于Overlay Network和Underlay Network对比如上表所示。

4.常见的CNI插件

Kubernetes在启动Pod的pause容器之后，直接调用CNI网络插件，从而实现为Pod内部应用容器所在的Network Namespace配置符合预期的网络信息。

对容器网络的设置和操作都通过插件(plugin)进行具体实现，CNI插件包括两种类型：CNIPlugin和IPAM(IP Address Management)Plugin。

CNI  Plugin负责为容器网络配置网络资源，IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分，与CNI Plugin一起工作。


CNI插件类别:
	- Main Plugin:
		用来创建具体的网络设备的二进制文件，负责创建，删除网络以及向网络添加或者删除容器。
		它专注于连通容器与容器之间以及容器与宿主机之间的通信，同容器相关网络设备通常由该类插件所创建。
		典型代表：lookback，bridge，macvlan，ipvlan，host-device，ptp，veth，vlan等虚拟设备。
		
	- IPAM Plugin:
		IPAM全称为"IP Address Management"，仅用于创建，删除地址池，以及分配，回收容器的IP地址，不提供网络实现。
		该类插件主要实现有host-local和dhcp两个。
			- host-local:
				基于预置的地址范围进行地址分配。
			- dhcp:
				通过dhcp协议获取地址。
        
	- Meta Plugin:
		由CNI社区维护的内部插件功能模块，自身不提供任何网络实现，而是调用其他插件。
		常见的插件功能模块有以下几种:
			- flannel:
				专门为Flannel项目提供的插件。
			- tuning:
				通过sysctl调整网络设备参数的二进制文件。
			- portmap:
				通过iptables配置端口映射的二进制文件。
			- bandwidth:
				使用Token Bucket Filter(TBF)来进行限流的二进制文件。
			- firewall:
				通过iptables或者firewalld添加规则控制容器的进出流量。


	
温馨提示:
	在Kubernetes 1.24-版本之前，CNI插件也可以由Kubelet使用命令行参数"cni-bin-dir"和"network-plugin"管理。
	而在Kubernetes 1.24移除了这些命令行参数，CNI的管理不在是kubelet的工作，而变成下层容器引擎需要做的事情了，比如"cri-dockerd"服务的启动文件。

5.常见的CNI网络方案

功能对比\产品名称 Flannel Calico Canal Weave Cilium
网络模式(Network Model) 隧道模式(Encapsulated，基于vxlan) 隧道模式(Encapsulated，基于vxlan，IPIP)
非隧道模式(Unencapsulated)		 隧道模式(Encapsulated，基于vxlan) 隧道模式(Encapsulated) 隧道模式(Encapsulated，基于vxlan)
路由分发
(Route Distribution)		 No Yes No Yes Yes
网络策略
(Network Policies)		 No Policy management and ACLs Policy management and ACLs Network rules Network rules through HTTP filters
BGP点对点通信模式 No Yes No Yes Yes
数据存储(External Database) K8S API OR etcd K8S API OR etcd K8S API OR etcd None K8S API OR etcd
数据加密(Encryption) IPsec WireGuard IPsec IPsec WireGuard or IPsec
入/出站网络策略(Ingress/Egress Policies) No YES YES YES YES
路由协议(Routing Protocols) IP-in-IP，BGP，VXLAN VXLAN VXLAN VXLAN VXLAN，BGP
优势(superiority) 简单轻量级，支持IPsec 高性能，支持网络策略 高性能，支持网络策略 基于内核支持，有企业版 支持跨集群，支持多CNI插件。
劣势(disadvantage) 不支持策略 不支持多播 不支持多播 仅Linux系统支持，网络性能较低 复杂，需要额外部署BGP插件，单独安装cilimu功能并不完整。 
- Flannel: 
	Flannel是coreOS开发的项目，是一个可以用于 Kubernetes 的 overlay 网络提供者。
	提供叠加网络，基于Linux TUN/TAP，使用UDP封装IP报文来创建叠加网络，并借助etcd维护网络分配情况。
		
- Calico:
	基于BGP的三层网络，支持网络策略实现网络的访问控制。
		
- Canal:
	Canal试图将Flannel提供的网络功能与Calico的网络策略功能集成在一起。
	只不过在研发的时候，发现Flannel和Calico这两个项目的标准化和灵活性都相当标准，那集成就没不要了，所以目前这个项目"烂尾"了。
	由于Canal的思路很好，业界习惯性地将Flannel和Calico的功能组合实施称为"Cannel"。
	对于喜欢Flannel提供的网络模型，同时喜欢Calico的网络策略功能的人来说，Canal是一个不错的选择。

		
- Weave:
	Weave是由Weaveworks提供的一种Kubernetes CNI网络选项，它在集群中的每个节点上都部署路由组件，从而实现主机之间创建更加灵活的网络overlay网络，借助于内核级别的Oepn vSwitch配置，从而实现具有一定程度的智能路由功能。除此之外，weave还具有网络策略，网络加密传输等功能。
	对于哪些寻求功能丰富的网络，同时希望不要增加大量复杂性或管理难度的人来说，Weave是一个很好的选择。
	比较遗憾的是，Weaveworks早在2024年上旬就宣布破产，尽管社区依旧存在，但公司已经不在了，后期的活跃度估计也会"人走茶凉"。
		
- Cilium:  
	是一种网络、可观察性和安全解决方案，具有基于eBPF的数据平面，效率更高。
    
    
推荐阅读:
	https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/addons/
	https://github.com/containernetworking/cni/blob/main/SPEC.md1

6.如何选择网络插件

通常来说，选择网络插件时应该通过"底层系统环境限制"，"容器网络的功能需求"和"容器网络性能需求"三个重要指标来衡量。

底层系统环境限制:
	- 1.公有云环境多有专有的实现，例如Google GCE，Azure CNI，AWS VPC CNI以及Aliyun Terway等;
	- 2.虚拟化环境限制较多，除叠加网络模型别无选择，可用有Flannel vxlan，Calico IPIP，Weave和Antrea等;
	- 3.物理机环境几乎支持任何类型的网络插件，此时一般应该选择性能较好的Calico BGP，Flannel host-gw或者DAMM IPVLAN等;
	
容器网络的功能需求:
	- 1.支持网络策略(NetworkPolicy)的解决方案以Calico，WeaveNet和Cilium为代表，而且后两个支持节点到节点间的通信加密;
	- 2.而大量Pod需要与集群外部资源互联互通时应该选择承载网络模型依赖的解决方案;

容器网络性能需求:
	- 1.Overlay网络中的协议报文有隧道开销，性能略差，而Underlay网络则几乎不存在这方面的问题;
	- 2.但Overlay或Underlay路由模型的网络插件支持较快的Pod创建速度，而Underlay模型中IPVLAN或MACVLAN模式中较慢;

7.CNI网段配置

	1.查看controller manager的配置
[root@master231 ~]# cat  /etc/kubernetes/manifests/kube-controller-manager.yaml 
...
spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
    ...
    - --cluster-cidr=10.100.0.0/16
    ...
    - --service-cluster-ip-range=10.200.0.0/16


相关参数说明:
	--allocate-node-cidrs:
		表示每新增一个节点，都从-cluster-cidr子网中切分一个新的子网网段分配给对应节点。
		这些相关的网络状态熟悉信息，会经过kube-apiserver存储到etcd中。
		
	--cluster-cidr:
		Pod的网段。
		
	--service-cluster-ip-range：
		svc网段。



温馨提示:
	使用CNI插件编排网络，Pod初始化或删除时，kubelet会调用默认CNI插件，创建虚拟设备接口附加到相关的底层网络，设置IP，路由并映射到Pod对象网络名称空间。
	kubectl在“/etc/cni/net.d/”目录查找cni josn配置文件，基于type属性到"/opt/cni/bin/"中查找相关插件的二进制文件，然后调用相应插件设置网络。
	
	
	
	2.查看flannel的配置
[root@master231 ~] cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.100.0.0/16
FLANNEL_SUBNET=10.100.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true


	3.网段分配原理
- 1.集群的kube-controller-manager负责控制每个节点的网段分配；
- 2.集群的etcd负责存储所有节点的网络配置存储;
- 3.集群的flannel负责各个节点的路由表定制机其数据包的拆分和封装;


综上所述，所有flannel各个节点是平等的，仅负责数据平面的操作，网络功能相对来说比较简单。另外一种calico插件，相对flannel来说，多了一个控制节点，来管控所有哦的网络节点的服务进程。

二.Flannel原理验证

1.Flannel概述

Flannel有CoreOS公司研发，兼容CNI插件API，支持Kubernetes，Docker，OpenShift，Cloud Foundry，Mesos，Amazon ECS，Singularity和OpenSVC等平台。

使用"虚拟网桥和veth设备"的方式为Pod创建虚拟网络接口，通过可配置的"后端"定义Pod间的通信网络，支持基于VXLAN的UDP的Overlay网络，以及基于三层路由的Underlay网络。

在IP地址分配方面，它将预留的一个专用网络(默认为"10.244.0.0/16")切分成多个子网后作为每个节点的PodCIDR，而后由节点以IPAM插件host-local进行地址分配，并将子网分配信息保存于"etcd"中。

其中虚拟网桥统称为"cni0"设备，而隧道接口通常为"flannel.1"设备。

2.Flannel工作模型

udp:
	由于新能较低，官方已经弃用，可以忽略。
	如果使用这种模式，flanneld程序将监听8285/UDP端口发送封装的报文。


vxlan模型:
	使用Linux内核中vxlan模块封装隧道报文，以Overlay模型支持跨节点的Pod间互联互通，这是默认采用的方式。
	vxlan后端模式中，flanneld监听于8472/UDP发送封装的数据包。


host-gw模型:
	Pod和Pod不经隧道封装而直接通信，此模式性能最高，但要求宿主机worker节点要在同一个网段中，即不支持跨网段。
	

vxlan directrouting模型:
	它是vxlan和host-gw自由组合的一种模型。
	位于同一个二层网络上的，但不同节点的上的Pod通信，无须隧道封装，但非同一个二层网络上的节点上的Pod间通信就是用vxlan模型。

3.vxlan模型验证

3.1 flannel的配置及路由信息

	1.查看cm的网络配置
[root@master231 ~]# kubectl get cm -n kube-flannel  kube-flannel-cfg  -o yaml
apiVersion: v1
data:
  cni-conf.json: |    # CNI插件的功能配置
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",   # 基于flannel实现网络通信，配置容器的网络。
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",  # 来实现端口映射的功能，底层基于iptables实现端口映射。
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |  # flannel的地网络分配
    {
      "Network": "10.100.0.0/16",  # Pod网段
      "EnableNFTables": false,
      "Backend": {
        "Type": "vxlan"  # worker工作节点基于vxlan从network中获取子网
      }
    }
kind: ConfigMap
...



	2.查看路由表信息
[root@master231 ~]# ifconfig flannel.1
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.100.0.0  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::d463:4bff:fe8b:137c  prefixlen 64  scopeid 0x20<link>
        ether d6:63:4b:8b:13:7c  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 39 overruns 0  carrier 0  collisions 0

[root@master231 ~]# 
[root@master231 ~]# ip route | grep flannel
10.100.1.0/24 via 10.100.1.0 dev flannel.1 onlink 
10.100.2.0/24 via 10.100.2.0 dev flannel.1 onlink 
[root@master231 ~]# 


温馨提示:
	- 1.如果是和当前主机同网段则通过"cni0"网络传输数据。
	- 2.如果是和当前主机不在同网段则通过"flannel.1"进行数据传输;
	
	
	
	3.数据包转发解析
		3.1.查看IP对应的目标MAC地址
[root@master231 ~]# ip neigh | grep flannel
10.100.1.0 dev flannel.1 lladdr d6:49:d4:7f:6c:6f PERMANENT
10.100.2.0 dev flannel.1 lladdr 7e:05:32:ed:ce:c8 PERMANENT
[root@master231 ~]# 

		3.2.转发给指定主机（fdb用于查看相邻的网卡及mac地址信息）
[root@master231 ~]# bridge fdb show flannel.1 | grep flannel.1
7e:05:32:ed:ce:c8 dev flannel.1 dst 10.0.0.233 self permanent
d6:49:d4:7:6c:6f dev flannel.1 dst 10.0.0.232 self permanent
[root@master231 ~]#

3.2 测试flannel的vxlan模型

	1.创建Pod在不同的节点
[root@master231 ~]# cat yinzhengjie-network-cni-test.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: xiuxian-v1
spec:
  nodeName: worker232
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v1 
    name: xiuxian

---

apiVersion: v1
kind: Pod
metadata:
  name: xiuxian-v2
spec:
  nodeName: worker233
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/yinzhengjie-k8s/apps:v2
    name: xiuxian
[root@master231 ~]# 
[root@master231 ~]# kubectl apply -f yinzhengjie-network-cni-test.yaml
pod/xiuxian-v1 created
pod/xiuxian-v2 created
[root@master231 ~]# 
[root@master231 ~]# kubectl get pods -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
xiuxian-v1   1/1     Running   0          5s    10.100.1.9   worker232   <none>           <none>
xiuxian-v2   1/1     Running   0          5s    10.100.2.3   worker233   <none>           <none>
[root@master231 ~]# 



	2.链接worker232节点的Pod去ping对端节点worker233的Pod
[root@master231 ~]# kubectl exec -it xiuxian-v1 -- sh
/ # ping 10.100.2.3 -c 1
PING 10.100.2.3 (10.100.2.3): 56 data bytes
64 bytes from 10.100.2.3: seq=0 ttl=62 time=0.486 ms

--- 10.100.2.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.486/0.486/0.486 ms
/ # 


	3.在worker233节点抓包【-en表示不进行反向解析主机名，只抓取IP地址信息】
[root@worker233 ~]# tcpdump -i eth0 -en host 10.0.0.232 and udp port 8472
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:52:30.980622 00:0c:29:6b:de:91 > 00:0c:29:c8:bf:fe, ethertype IPv4 (0x0800), length 148: 10.0.0.232.56710 > 10.0.0.233.8472: OTV, flags [I] (0x08), overlay 0, instance 1
d6:49:d4:7f:6c:6f > 7e:05:32:ed:ce:c8, ethertype IPv4 (0x0800), length 98: 10.100.1.9 > 10.100.2.3: ICMP echo request, id 12032, seq 0, length 64
16:52:30.980715 00:0c:29:c8:bf:fe > 00:0c:29:6b:de:91, ethertype IPv4 (0x0800), length 148: 10.0.0.233.36636 > 10.0.0.232.8472: OTV, flags [I] (0x08), overlay 0, instance 1
7e:05:32:ed:ce:c8 > d6:49:d4:7f:6c:6f, ethertype IPv4 (0x0800), length 98: 10.100.2.3 > 10.100.1.9: ICMP echo reply, id 12032, seq 0, length 64

4.hostgw模型验证

4.1 修改flannel的工作模式为host-gw

	1.修改前查看本地路由信息
[root@worker233 ~]# route -n | grep 10.100
10.100.0.0      10.100.0.0      255.255.255.0   UG    0      0        0 flannel.1
10.100.1.0      10.100.1.0      255.255.255.0   UG    0      0        0 flannel.1
10.100.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
[root@worker233 ~]# 


	2.修改cm资源
[root@master231 ~]# kubectl -n kube-flannel edit cm kube-flannel-cfg 
 ...
  6 data:
 ...	
 27   net-conf.json: |
 28     {
 29       "Network": "10.100.0.0/16",
 30       "EnableNFTables": false,
 31       "Backend": {
 32         "Type": "host-gw"                                                                                                                                               
 33       }
 34     }
 35 kind: ConfigMap
...


	3.删除旧的Pod
[root@master231 ~]# kubectl -n kube-flannel get pods -n kube-flannel -o wide
NAME                    READY   STATUS    RESTARTS      AGE   IP           NODE        NOMINATED NODE   READINESS GATES
kube-flannel-ds-65spm   1/1     Running   2 (31h ago)   46h   10.0.0.232   worker232   <none>           <none>
kube-flannel-ds-h829h   1/1     Running   2 (31h ago)   46h   10.0.0.231   master231   <none>           <none>
kube-flannel-ds-jjswj   1/1     Running   2 (31h ago)   46h   10.0.0.233   worker233   <none>           <none>
[root@master231 ~]# 
[root@master231 ~]# kubectl -n kube-flannel delete pods --all
pod "kube-flannel-ds-65spm" deleted
pod "kube-flannel-ds-h829h" deleted
pod "kube-flannel-ds-jjswj" deleted
[root@master231 ~]# 
[root@master231 ~]# kubectl -n kube-flannel get pods -n kube-flannel -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
kube-flannel-ds-6g8gs   1/1     Running   0          10s   10.0.0.232   worker232   <none>           <none>
kube-flannel-ds-927cv   1/1     Running   0          10s   10.0.0.231   master231   <none>           <none>
kube-flannel-ds-zvcwz   1/1     Running   0          10s   10.0.0.233   worker233   <none>           <none>
[root@master231 ~]# 


	4.再次查看本地路由
[root@worker233 ~]# route -n | grep 10.100
10.100.0.0      10.0.0.231      255.255.255.0   UG    0      0        0 eth0
10.100.1.0      10.0.0.232      255.255.255.0   UG    0      0        0 eth0
10.100.2.0      0.0.0.0         255.255.255.0   U     0      0        0 cni0
[root@worker233 ~]#

4.2 访问测试验证并抓包

	1.Pod发起http请求
[root@master231 ~]# kubectl get pods -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
xiuxian-v1   1/1     Running   0          23h   10.100.1.9   worker232   <none>           <none>
xiuxian-v2   1/1     Running   0          23h   10.100.2.3   worker233   <none>           <none>
[root@master231 ~]# 
[root@master231 ~]# kubectl exec -it xiuxian-v1 -- sh
/ # 
/ # curl 10.100.2.3 
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8"/>
    <title>yinzhengjie apps v2</title>
    <style>
       div img {
          width: 900px;
          height: 600px;
          margin: 0;
       }
    </style>
  </head>

  <body>
    <h1 style="color: red">凡人修仙传 v2 </h1>
    <div>
      <img src="2.jpg">
    <div>
  </body>

</html>
/ # 


	2.抓包验证【如上图所示】
[root@worker233 ~]# tcpdump -i eth0 -nn host 10.100.1.9 and tcp port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:01:41.399872 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [S], seq 585432471, win 64860, options [mss 1410,sackOK,TS val 1708893394 ecr 0,nop,wscale 7], length 0
16:01:41.399995 IP 10.100.2.3.80 > 10.100.1.9.50230: Flags [S.], seq 1822456778, ack 585432472, win 64308, options [mss 1410,sackOK,TS val 1769041391 ecr 1708893394,nop,wscale 7], length 0
16:01:41.400226 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [.], ack 1, win 507, options [nop,nop,TS val 1708893395 ecr 1769041391], length 0
16:01:41.400272 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [P.], seq 1:75, ack 1, win 507, options [nop,nop,TS val 1708893395 ecr 1769041391], length 74: HTTP: GET / HTTP/1.1
16:01:41.400289 IP 10.100.2.3.80 > 10.100.1.9.50230: Flags [.], ack 75, win 502, options [nop,nop,TS val 1769041391 ecr 1708893395], length 0
16:01:41.401278 IP 10.100.2.3.80 > 10.100.1.9.50230: Flags [P.], seq 1:239, ack 75, win 502, options [nop,nop,TS val 1769041392 ecr 1708893395], length 238: HTTP: HTTP/1.1 200 OK
16:01:41.401377 IP 10.100.2.3.80 > 10.100.1.9.50230: Flags [P.], seq 239:594, ack 75, win 502, options [nop,nop,TS val 1769041392 ecr 1708893395], length 355: HTTP
16:01:41.401587 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [.], ack 239, win 506, options [nop,nop,TS val 1708893396 ecr 1769041392], length 0
16:01:41.401587 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [.], ack 594, win 504, options [nop,nop,TS val 1708893396 ecr 1769041392], length 0
16:01:41.401861 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [F.], seq 75, ack 594, win 504, options [nop,nop,TS val 1708893396 ecr 1769041392], length 0
16:01:41.401921 IP 10.100.2.3.80 > 10.100.1.9.50230: Flags [F.], seq 594, ack 76, win 502, options [nop,nop,TS val 1769041393 ecr 1708893396], length 0
16:01:41.402244 IP 10.100.1.9.50230 > 10.100.2.3.80: Flags [.], ack 595, win 504, options [nop,nop,TS val 1708893397 ecr 1769041393], length 0
...

5.宿主机验证虚拟网卡网络名称空间

	1.查看宿主机和容器网课设备对对应关系
ip a  # 查找对应设备对的"cni-xxx"的网络名称空间ID

	2.查看当前宿主机的网络名称空间
ip netns

	3.连接到指定的网络名称空间并查看网卡信息
ip netns exec cni-XXX ip a

6.Flannel的vxlan底层通信原理

如上图所示，对于同一个节点不同pod数据通信，只需要通过cni0即可。

而基于vxlan跨节点Pod通信，则需要借助于cni0和flannel.1设备传输数据。
posted @   尹正杰  阅读(21)  评论(0)  编辑  收藏  举报
相关博文：
· CentOS 7.9二进制部署K8S 1.28.3+集群实战
· kubernetes简史及单master架构实战
· 41、K8S-网络机制之Flannel
· 三十二、kubernetes集群的网络实现
· k8s-flannel
阅读排行：
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！
· 没有Manus邀请码？试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单，K8s 太复杂？w7panel 让容器管理更轻松！
历史上的今天：
2023-02-24 docker swarm快速入门篇
2020-02-24 分区管理工具-fdisk命令实战案例
2019-02-24 MySQL复制相关参数详解
2019-02-24 MySQL5.7基于binary log的主从复制
2018-02-24 JavaScript基础知识-关系运算符
点击右上角即可分享
微信分享提示