深入 K8s 网络原理（一）- Flannel VXLAN 模式分析

2023-12-27 09:20
文章标签 云原生 深入 原理 网络 k8s vxlan flannel 模式分析

本文主要是介绍深入 K8s 网络原理（一）- Flannel VXLAN 模式分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. 概述

这周集中聊下 K8s 的集群网络原理，我初步考虑分成3个方向：

  1. Pod-to-Pod 通信（同节点 or 跨节点），以 Flannel VXLAN 模式为例；

  1. Pod/External-to-Service 通信，以 iptables 实现为例；

  1. Ingress 原理，以 NGINX Ingress Controller 实现为例；

  1. 其他：（到时候看心情）Flannel host-gw 模式，Calico，……

今天先介绍下 Flannel 实现 Pod 跨节点通信的原理。

2. TL;DR

我知道你们着急，这样吧，先看图：

一图胜千言，下文都不知道咋展开了。哎。

此外，网络这块涉及的概念有点多，逐个细讲感觉不合适。这样，此处默认大家都熟悉 TCP/IP 协议族，下文该偷懒的地方我就偷懒。

3. Pod 间通信问题的由来

容器化以前，当需要将多个应用灵活部署到一些服务器上时，就不可避免地会遇到端口冲突问题，而协调这种冲突是很繁琐的。K8s 体系的处理方式是将每个 Pod 丢到单独的 netns 里，也就是 ip 和 port 都彼此隔离，这样就不需要考虑端口冲突了。

不过这套网络架构应该如何实现呢？整体来由需要解决下面这2个问题（结合上图的 Pod1234）：

  1. Pod1 如何和 Pod2 通信（同节点）

  1. Pod1 如何和 Pod3 通信（跨节点）

K8s 的网络模型要求每个 Pod 都有一个唯一的 IP 地址，即使这些 Pod 分布在不同的节点上。为了实现这个网络模型，CoreOS 团队发起了 CNI 项目（后来 CNI 进了 CNCF 孵化）。CNI (Container Network Interface) 定义了实现容器之间网络连通性和释放网络资源等相关操作的接口规范，这套接口进而由具体的 CNI 插件的去实现，CNI 插件负责为 Pod 分配 IP 地址，并处理跨节点的网络路由等具体的工作。

行，接下来具体跟下 CNI 的 Flannel 实现是怎么工作的。

4. 测试环境准备

我在本地通过 Minikube 启动一个3节点的 K8s 集群，3个节点的 IP 和 hostname 分别是：

  • 192.168.49.2 minikube

  • 192.168.49.3 minikube-m02

  • 192.168.49.4 minikube-m03

此外在这个集群内创建了几个 Pod，信息如下（主要留一下 Pod 的 IP 以及所在的节点）：

  • kgpoowide

NAME                                READY   STATUS    RESTARTS   AGE    IP           NODE
nginx-deployment-7fbb8f4b4c-89bds   1/1     Running   0          20h    10.244.2.4   minikube-m03
nginx-deployment-7fbb8f4b4c-d29zm   1/1     Running   0          20h    10.244.1.5   minikube-m02
nginx-deployment-7fbb8f4b4c-k5vh4   1/1     Running   0          102s   10.244.2.5   minikube-m03
nginx-deployment-7fbb8f4b4c-m4scr   1/1     Running   0          3s     10.244.1.6   minikube-m02

Pod 用的镜像是带有 ip 等命令的 NGINX，Dockerfile 如下：

FROM nginx:latestRUN apt-get update && \apt-get install -y iproute2 && \rm -rf /var/lib/apt/lists/*

相应的 Deployment YAML 如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:replicas: 4selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:test1ports:- containerPort: 80

5. 从 veth 设备聊起

不得不先提一句 veth（Virtual Ethernet Device）。veth 是一种在 Linux 中用于网络虚拟化的技术，常用于容器网络中。veth pair 可以看作是一对虚拟网络接口设备，它们像管道的两端一样相连。在一个 veth 对中，数据从一端发送出去，可以在另一端被接收到，就像它们是通过一根以太网线连接的两个独立设备一样。

在容器网络中，veth 对经常被用来连接容器和主机。具体来说，veth 对的一个端点（通常称为 veth 接口）位于容器的网络命名空间内，好像是容器的网络接口卡，而另一个端点位于主机的全局网络命名空间内，通常会连接到一个 Linux 桥接或者其他网络设备。

这种设置允许容器内的网络流量通过 veth 接口流出容器，进入主机的网络命名空间，并通过主机的网络路由和策略进行进一步的处理或转发。

如图所示，Pod 内的 eth0 和 host 上的 veth1 其实就是一个 veth pair，Pod 和 host 在2个不同的网络命名空间内，通过 veth 设备实现了2个 netns 之间的网络互通。

而 veth-n 又会桥接到 cni0 这个网桥上，进而实现流量在主机上的路由过程。接下来我们具体看下 Pod 内外的网络设备和路由规则等。

6. 网桥 cni0

接着来看网桥 cni0。

6.1 在 Pod 内看网卡信息

Pod 10.244.1.6 内的网卡信息如下：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000link/ipip 0.0.0.0 brd 0.0.0.0
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000link/tunnel6 :: brd :: permaddr 1622:c323:de90::
4: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue state UP group defaultlink/ether 4a:2c:84:bb:56:5e brd ff:ff:ff:ff:ff:ff link-netnsid 0inet 10.244.1.6/24 brd 10.244.1.255 scope global eth0valid_lft forever preferred_lft forever

可以看到 eth0@f11 设备，对应 IP 10.244.1.6/24，这里看着和一个普通的 vm 没有大差别。此外留一下这里的 if11，这个 11 对应这个 veth pair 在主机上的另外一端的序号。

6.2 在 host 上看网卡信息

节点 minikube-m02 上的网卡信息如下：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft forever
5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue state UNKNOWN group defaultlink/ether 62:07:aa:05:13:c4 brd ff:ff:ff:ff:ff:ffinet 10.244.1.0/32 scope global flannel.1valid_lft forever preferred_lft forever
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue state UP group default qlen 1000link/ether de:07:f7:20:e0:70 brd ff:ff:ff:ff:ff:ffinet 10.244.1.1/24 brd 10.244.1.255 scope global cni0valid_lft forever preferred_lft forever
7: vetha7eec1e2@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP group defaultlink/ether da:ab:17:55:be:50 brd ff:ff:ff:ff:ff:ff link-netnsid 1
10: vethc9667243@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP group defaultlink/ether ce:dd:d3:ec:5e:d3 brd ff:ff:ff:ff:ff:ff link-netnsid 2
11: vethd26e8b95@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP group defaultlink/ether b2:64:95:13:2a:de brd ff:ff:ff:ff:ff:ff link-netnsid 3
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue state UP group defaultlink/ether 02:42:c0:a8:31:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0inet 192.168.49.3/24 brd 192.168.49.255 scope global eth0valid_lft forever preferred_lft forever

前面 Pod 内看到的 eth0@if11 对应这里的11号 vethd26e8b95@if4。别管这里的 if4，如果你是在 vm 里直接跑 Pod 就看不到 ifn 了。我这里因为用了 Docker Desktop 跑 K8s，所以 K8s 所在的 nodes 本质也是容器，这里多套了一层网络嵌套而已。

先看下 cni0：

  • ip link show master cni0

7: vetha7eec1e2@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP mode DEFAULT group defaultlink/ether da:ab:17:55:be:50 brd ff:ff:ff:ff:ff:ff link-netnsid 1
10: vethc9667243@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP mode DEFAULT group defaultlink/ether ce:dd:d3:ec:5e:d3 brd ff:ff:ff:ff:ff:ff link-netnsid 2
11: vethd26e8b95@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue master cni0 state UP mode DEFAULT group defaultlink/ether b2:64:95:13:2a:de brd ff:ff:ff:ff:ff:ff link-netnsid 3

可以看到前面提到的 veth vethd26e8b95 被桥接到了 cni0 上。

继续看 host 的路由表：

default via 192.168.49.1 dev eth0
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
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
192.168.49.0/24 dev eth0 proto kernel scope link src 192.168.49.3

留意这里的 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1

cni0 的信息是：

6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65485 qdisc noqueue state UP group default qlen 1000link/ether de:07:f7:20:e0:70 brd ff:ff:ff:ff:ff:ffinet 10.244.1.1/24 brd 10.244.1.255 scope global cni0valid_lft forever preferred_lft forever

结合起来看，也就是所有发往 10.244.1.0/24 段的数据包都会通过 cni0 传输，10.244.1.0/24 也就是 Flannel 分配给当前节点的 Pod IP 段。

7. VTEP flannel.1

上述路由表中还有这样2条记录：

10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink

当前集群是3个节点，也就是目的地址是当前节点内的 pods IP 段 10.244.1.0/24，流量交给 cni0 处理；而其他节点的 pods IP 段 10.244.0.0/24 和 10.244.2.0/24 则交给 flannel.1 来处理。

flannel.1 是 VXLAN 网络的 VTEP 设备。简单介绍下 VXLAN 和 VTEP：

VXLAN (Virtual Extensible LAN) 是一种覆盖网络技术，允许在现有的物理网络基础设施之上创建大量虚拟化的局域网（LAN）。它主要用于解决传统 VLAN 技术的一些限制，如 VLAN ID 数量限制（只有4096个）。VXLAN 可以支持高达1600万个虚拟网络，极大地扩展了网络的规模和灵活性。

VXLAN 相关的一些概念与原理：

  • 封装与隧道技术：VXLAN 通过封装原始的以太网帧（Layer 2）到 UDP 数据包（Layer 3）中来工作。这意味着它可以跨越不同的网络和子网，实现跨网络边界的通信。

  • VXLAN 网络标识符 (VNI)：每个 VXLAN 网络都有一个唯一的标识符，称为 VNI（VXLAN Network Identifier），它提供了地址隔离，确保各个 VXLAN 网络之间的数据包不会互相干扰。

  • VTEP（VXLAN Tunnel Endpoint）：VTEP 是 VXLAN 架构中的端点设备，负责封装和解封装数据包。每个通过 VXLAN 通信的网络设备都有一个或多个 VTEP。当数据包从虚拟网络出发时，VTEP 会捕获这些数据包，将它们封装在 VXLAN 格式中（即加入 VNI 和 UDP 头），然后通过物理网络发送。当 VXLAN 数据包到达目的地的 VTEP 时，该 VTEP 将对数据包进行解封装，移除 VXLAN 头部，然后将原始的以太网帧转发到目标虚拟网络中。VTEP 通常部署在数据中心的交换机（物理或虚拟）上，但也可以部署在其他网络设备或服务器上。在容器化环境（如 Kubernetes 使用 Flannel 等 CNI）中，VTEP 可以作为软件组件运行，处理容器或 Pod 之间的 VXLAN 通信。

所以当数据包到达 flannel.1 的时候，就开始了 VXLAN 封包（MAC in UDP）过程，一个以太网帧被依次加上了 VXLAN 头（VNI 信息）、UDP 头、外部 IP 头和 MAC 头等。外部 IP 头里包含了 VXLAN 隧道的源地址和目的地址（VTEP 地址），外部 MAC 头则包含了以太网帧到达下一跳所需的 MAC 地址。

8. 最后看下 Flannel 的配置

在 minikube 环境中，Flannel 会被默认部署到 kube-flannel namespace 下。在这个 namespace 里有一个 ConfigMap 叫做 kube-flannel-cfg，里面包含这样2个配置文件：

  • 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","Backend": {"Type": "vxlan"}
}

如果需要修改网络模式或者 pods 网段，就可以在 net-conf.json 中灵活调整。早几年用 Flannel 的时候，我就习惯将 10.244.0.0/16 改成 10.100.0.0/16。此外 vxlan 改成 host-gw 可以提高网络传输性能，如果你的集群规模不是大几百好几千个节点，也可以考虑用 host-gw 模式。

9. 总结

从来不总结，下班。

算了，补张图吧，前文提到的 Pod1 到 Pod2/Pod3 的流量怎么走：

文章转载自：胡说云原生

原文链接：https://www.cnblogs.com/daniel-hutao/p/17914378.html

体验地址： 引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

这篇关于深入 K8s 网络原理（一）- Flannel VXLAN 模式分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/542655。

相关文章

Spring Boot循环依赖原理、解决方案与最佳实践(全解析)

Spring Boot循环依赖原理、解决方案与最佳实践(全解析)

《SpringBoot循环依赖原理、解决方案与最佳实践(全解析)》循环依赖指两个或多个Bean相互直接或间接引用,形成闭环依赖关系,：本文主要介绍SpringBoot循环依赖原理、解决方案与最... 目录一、循环依赖的本质与危害1.1 什么是循环依赖？1.2 核心危害二、Spring的三级缓存机制2.1 三
阅读更多...
C#中async await异步关键字用法和异步的底层原理全解析

C#中async await异步关键字用法和异步的底层原理全解析

《C#中asyncawait异步关键字用法和异步的底层原理全解析》：本文主要介绍C#中asyncawait异步关键字用法和异步的底层原理全解析,本文给大家介绍的非常详细,对大家的学习或工作具有一... 目录C#异步编程一、异步编程基础二、异步方法的工作原理三、代码示例四、编译后的底层实现五、总结C#异步编程
阅读更多...
深入理解Apache Kafka(分布式流处理平台)

深入理解Apache Kafka(分布式流处理平台)

《深入理解ApacheKafka(分布式流处理平台)》ApacheKafka作为现代分布式系统中的核心中间件,为构建高吞吐量、低延迟的数据管道提供了强大支持,本文将深入探讨Kafka的核心概念、架构... 目录引言一、Apache Kafka概述1.1 什么是Kafka？1.2 Kafka的核心概念二、Ka
阅读更多...
Go 语言中的select语句详解及工作原理

Go 语言中的select语句详解及工作原理

《Go语言中的select语句详解及工作原理》在Go语言中,select语句是用于处理多个通道（channel）操作的一种控制结构,它类似于switch语句,本文给大家介绍Go语言中的select语... 目录Go 语言中的 select 是做什么的基本功能语法工作原理示例示例 1：监听多个通道示例 2：带
阅读更多...
鸿蒙中@State的原理使用详解(HarmonyOS 5)

鸿蒙中@State的原理使用详解(HarmonyOS 5)

《鸿蒙中@State的原理使用详解(HarmonyOS5)》@State是HarmonyOSArkTS框架中用于管理组件状态的核心装饰器,其核心作用是实现数据驱动UI的响应式编程模式,本文给大家介绍... 目录一、@State在鸿蒙中是做什么的？二、@Spythontate的基本原理1. 依赖关系的收集2.
阅读更多...
Java编译生成多个.class文件的原理和作用

Java编译生成多个.class文件的原理和作用

《Java编译生成多个.class文件的原理和作用》作为一名经验丰富的开发者,在Java项目中执行编译后,可能会发现一个.java源文件有时会产生多个.class文件,从技术实现层面详细剖析这一现象... 目录一、内部类机制与.class文件生成成员内部类（常规内部类）局部内部类（方法内部类）匿名内部类二、
阅读更多...
Linux系统配置NAT网络模式的详细步骤(附图文)

Linux系统配置NAT网络模式的详细步骤(附图文)

《Linux系统配置NAT网络模式的详细步骤(附图文)》本文详细指导如何在VMware环境下配置NAT网络模式,包括设置主机和虚拟机的IP地址、网关,以及针对Linux和Windows系统的具体步骤,... 目录一、配置NAT网络模式二、设置虚拟机交换机网关2.1 打开虚拟机2.2 管理员授权2.3 设置子
阅读更多...
揭秘Python Socket网络编程的7种硬核用法

揭秘Python Socket网络编程的7种硬核用法

《揭秘PythonSocket网络编程的7种硬核用法》Socket不仅能做聊天室,还能干一大堆硬核操作,这篇文章就带大家看看Python网络编程的7种超实用玩法,感兴趣的小伙伴可以跟随小编一起... 目录1.端口扫描器：探测开放端口2.简易 HTTP 服务器：10 秒搭个网页3.局域网游戏：多人联机对战4.
阅读更多...
Java并发编程必备之Synchronized关键字深入解析

Java并发编程必备之Synchronized关键字深入解析

《Java并发编程必备之Synchronized关键字深入解析》本文我们深入探索了Java中的Synchronized关键字,包括其互斥性和可重入性的特性,文章详细介绍了Synchronized的三种... 目录一、前言二、Synchronized关键字2.1 Synchronized的特性1. 互斥2.
阅读更多...
Python中随机休眠技术原理与应用详解

Python中随机休眠技术原理与应用详解

《Python中随机休眠技术原理与应用详解》在编程中,让程序暂停执行特定时间是常见需求,当需要引入不确定性时,随机休眠就成为关键技巧,下面我们就来看看Python中随机休眠技术的具体实现与应用吧... 目录引言一、实现原理与基础方法1.1 核心函数解析1.2 基础实现模板1.3 整数版实现二、典型应用场景2
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2