深入 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。

相关文章

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
阅读更多...
Java的IO模型、Netty原理解析

Java的IO模型、Netty原理解析

《Java的IO模型、Netty原理解析》Java的I/O是以流的方式进行数据输入输出的,Java的类库涉及很多领域的IO内容：标准的输入输出,文件的操作、网络上的数据传输流、字符串流、对象流等,这篇... 目录1.什么是IO2.同步与异步、阻塞与非阻塞3.三种IO模型BIO（blocking I/O）NI
阅读更多...
SpringBoot使用OkHttp完成高效网络请求详解

SpringBoot使用OkHttp完成高效网络请求详解

《SpringBoot使用OkHttp完成高效网络请求详解》OkHttp是一个高效的HTTP客户端,支持同步和异步请求,且具备自动处理cookie、缓存和连接池等高级功能,下面我们来看看SpringB... 目录一、OkHttp 简介二、在 Spring Boot 中集成 OkHttp三、封装 OkHttp
阅读更多...
Linux系统之主机网络配置方式

Linux系统之主机网络配置方式

《Linux系统之主机网络配置方式》：本文主要介绍Linux系统之主机网络配置方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、查看主机的网络参数1、查看主机名2、查看IP地址3、查看网关4、查看DNS二、配置网卡1、修改网卡配置文件2、nmcli工具【通用
阅读更多...
使用Python高效获取网络数据的操作指南

使用Python高效获取网络数据的操作指南

《使用Python高效获取网络数据的操作指南》网络爬虫是一种自动化程序,用于访问和提取网站上的数据,Python是进行网络爬虫开发的理想语言,拥有丰富的库和工具,使得编写和维护爬虫变得简单高效,本文将... 目录网络爬虫的基本概念常用库介绍安装库Requests和BeautifulSoup爬虫开发发送请求解
阅读更多...
一文带你深入了解Python中的GeneratorExit异常处理

一文带你深入了解Python中的GeneratorExit异常处理

《一文带你深入了解Python中的GeneratorExit异常处理》GeneratorExit是Python内置的异常,当生成器或协程被强制关闭时,Python解释器会向其发送这个异常,下面我们来看... 目录GeneratorExit：协程世界的死亡通知书什么是GeneratorExit实际中的问题案例
阅读更多...
JAVA封装多线程实现的方式及原理

JAVA封装多线程实现的方式及原理

《JAVA封装多线程实现的方式及原理》：本文主要介绍Java中封装多线程的原理和常见方式,通过封装可以简化多线程的使用,提高安全性,并增强代码的可维护性和可扩展性,需要的朋友可以参考下... 目录前言一、封装的目标二、常见的封装方式及原理总结前言在 Java 中，封装多线程的原理主要围绕着将多线程相关的操
阅读更多...
kotlin中的模块化结构组件及工作原理

kotlin中的模块化结构组件及工作原理

《kotlin中的模块化结构组件及工作原理》本文介绍了Kotlin中模块化结构组件,包括ViewModel、LiveData、Room和Navigation的工作原理和基础使用,本文通过实例代码给大家... 目录ViewModel 工作原理LiveData 工作原理Room 工作原理Navigation 工
阅读更多...
Java的volatile和sychronized底层实现原理解析

Java的volatile和sychronized底层实现原理解析

《Java的volatile和sychronized底层实现原理解析》文章详细介绍了Java中的synchronized和volatile关键字的底层实现原理,包括字节码层面、JVM层面的实现细节,以... 目录1. 概览2. Synchronized2.1 字节码层面2.2 JVM层面2.2.1 ente
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2