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

Kubernetes一网络组件概述

backend 2025/9/2 8:00:04

前言：

Kubernetes 的核心设计理念是“一切皆容器”，其调度和管理的基本单位是 Pod。然而，要让成千上万个动态创建、销毁并漂移的 Pod 能够可靠、高效地相互通信，并最终对外提供服务，一个强大、灵活且稳定的网络基础设施是至关重要的基石。Kubernetes 自身并未实现具体的网络功能，而是通过一套严谨的网络模型（如每个 Pod 都拥有独立 IP、所有 Pod 无需 NAT 即可互通等）来定义目标状态，将实现交付给了多样化的网络插件（CNI）。

从 Flannel 简便的 Overlay 封装到 Calico 高性能的 BGP 路由，从简单的服务发现到复杂的网络策略，Kubernetes 网络生态提供了多种解决方案以适应不同规模和环境的需求。理解这些网络组件的工作原理、通信流程以及排障方法，是掌握 Kubernetes 集群部署、运维和优化的关键环节。本概述将引导您系统性地探索 Kubernetes 的网络世界，从基础模型到实战演练，为您构建起坚实的企业级网络知识体系。

1. Kubernetes网络基础模型

1.1 核心原则

1.2 网络解决方案规范

2. 覆盖网络技术

2.1 基本概念

2.2 工作流程

2.3 VXLAN技术详解

2.3.1 产生背景

2.3.2 技术原理

2.3.3 核心组件

3. Flannel网络解决方案

3.1 架构设计

3.2 跨节点通信示例

3.3 优缺点分析

4. Calico网络解决方案

4.1 核心原理

4.2 BGP路由示例

4.3 关键特性

4.4 通信模式对比

5. Calico核心组件

5.1 Felix功能

5.2 etcd数据库

5.3 协调器插件

5.4 BGP客户端（Bird进程）

5.5 路由反射器（RR模式）

6. Calico与Flannel网络对比

6.1 Flannel核心特点

6.2 Flannel局限性

6.3 Calico优势

7. Kubernetes网络实战

7.1 端口号配置

7.2 Pod通信原理

7.2.1 同节点通信

7.2.2 跨节点通信

7.3 网络排障技巧

8. 核心网络实验

8.1 VLAN配置实验

8.1.1 关键命令

8.2 OSPF动态路由实验

8.2.1 实验拓扑

8.2.2 配置要点

8.2.3 路径选择验证

9. BGP协议核心概念

9.1 关键术语定义

9.2 iBGP与eBGP区别

9.3 通信机制

10. 网络故障排查方法

10.1 排查优先级顺序

10.2 抓包分析流程

10.3 路由追踪

11. 大型网络优化策略

11.1 全互联模式问题

11.2 路由反射器解决方案

12. CoreDNS工作机制

12.1 服务发现机制

12.2 DNS策略类型

12.3 域名解析规则

12.4 自定义主机名

12.5 外部域名解析

13. 重点解析

13.1 必考组件

13.2 调度器策略

13.3 网络方案选型

14. 附录：关键概念速查

14.1 术语对照表

14.2 命令速查

14.3 网络组件核心

K8S 涉及的端口号 (Master & Node)

Master 和 Node 安装时用的端口号

14.4 K8S 网络模型与核心概念

网络概述 & 虚拟网络

覆盖网络（Overlay Network）与 VXLAN

Calico (BGP & 三层路由)

14.5. Pod 通信流程（基于 Calico/BGP）

同一 Node 内 Pod 通信

不同 Node 间 Pod 通信 (纯路由模式)

总结对比

总结：

1. Kubernetes网络基础模型

1.1 核心原则

Kubernetes网络模型遵循以下基本原则：

Pod间直接通信：所有Pod必须能够在无需NAT的情况下直接通信
节点与Pod通信：所有节点必须能与所有Pod直接通信
IP地址持久性：Pod重新调度时应尽可能保持相同IP地址（实际实现需间接完成）

1.2 网络解决方案规范

Kubernetes网络解决方案遵循CNI（Container Network Interface）规范，提供标准化插件接口支持多种网络技术。常用解决方案对比：

解决方案	通信原理	适用场景	性能特点	策略支持
Calico	三层IP路由(BGP)	中大型集群	高性能，低延迟	支持
Flannel	覆盖网络(VXLAN)	中小型集群	中等，有封装开销	不支持
Host-GW	主机网关路由	同子网环境	较高，无封装开销	有限
IPIP	IP隧道封装	跨子网环境	中等，有封装开销	有限

2. 覆盖网络技术

2.1 基本概念

覆盖网络（Overlay Network）是在现有物理网络上构建的虚拟网络层，核心特性包括：

屏蔽底层网络差异
使分布式设备如同在同一物理网络
支持跨物理网络通信

2.2 工作流程

覆盖网络数据传输过程分三个阶段：

2.3 VXLAN技术详解

2.3.1 产生背景

传统VLAN技术的局限性：

VLAN ID数量限制（仅4096个）
物理网络架构依赖生成树协议（STP）
虚拟机迁移范围受限（需同二层域）

2.3.2 技术原理

VXLAN通过以下创新解决上述问题：

扩展标识空间：
- 使用24位VNI（VXLAN Network Identifier）
- 支持224=16,777,216个隔离网段

数据封装方式：

 +-------------------------+| 原始以太网帧（含IP数据） |+-------------------------+| VXLAN头部（含VNI）       |+-------------------------+| UDP头部（源/目的端口）   |+-------------------------+| 外层IP头部               |+-------------------------+| 外层MAC头部              |+-------------------------+

2.3.3 核心组件

组件	功能描述	部署位置
VTEP	负责封装/解封装VXLAN数据	虚拟机监控器或物理交换机
VNI	24位网络标识符	逻辑划分
底层IP网络	承载封装后的UDP数据包传输	物理基础设施

3. Flannel网络解决方案

3.1 架构设计

Flannel工作流程包含三个关键阶段：

网络分配：从etcd获取全局网络配置（如Pod CIDR）
子网分配：为每个节点分配唯一子网避免IP冲突
数据封装：使用VXLAN等技术封装原始数据包

3.2 跨节点通信示例

不同节点Pod间通信数据流：

 Pod A（Node1） → 封装（源：Node1 IP，目的：Node2 IP） → 物理网络 → Node2解封装 → 转发至Pod B

3.3 优缺点分析

优势：

部署配置简单
支持多种后端（VXLAN, host-gw, AWS VPC）
对新手友好

劣势：

性能低于纯路由方案
覆盖网络增加延迟
不支持网络策略

4. Calico网络解决方案

4.1 核心原理

Calico采用纯三层路由模型：

每个Pod分配唯一IP地址
通过Linux路由表直接转发流量
使用BGP协议广播路由信息

4.2 BGP路由示例

节点间路由学习过程：

4.3 关键特性

特性	实现方式	优势
高性能通信	纯IP路由无封装	降低CPU开销，提升吞吐量
网络策略	NetworkPolicy资源	精细控制Pod间流量
跨平台支持	兼容K8s/Docker Swarm/裸机	灵活部署
IP地址管理（IPAM）	支持静态分配和动态分配	避免IP冲突

4.4 通信模式对比

通信类型	数据路径	Calico实现方式
同节点Pod通信	cni0网桥直接转发	通过路由表直连（无封装）
跨节点Pod通信	经物理网卡路由	BGP学习路由或IPIP隧道封装

5. Calico核心组件

5.1 Felix功能

Felix负责接口管理、路由规则生成、ACL规则配置及状态报告。作为Calico的核心组件，Felix直接控制Pod网络接口的创建和路由条目的生成，并处理所有网络策略的写入。例如，当Pod需要连接到其他集群组件时，Felix提供客户端连接管理能力。

5.2 etcd数据库

etcd用于存储Calico的核心路由信息和网络配置数据，确保数据一致性。它作为Kubernetes的组件，直接利用Kubernetes的数据库机制存储关键网络元数据，如Pod IP分配和路由表。

5.3 协调器插件

协调器插件负责与云原生平台（如Kubernetes或OpenStack）集成，提供管理接口。通过该插件，用户可以直接使用kubectl命令管理Calico网络配置，简化了集群操作流程。

5.4 BGP客户端（Bird进程）

Bird进程是BGP协议的客户端实现，在每个节点上部署。其核心作用包括：

将Felix生成的路由信息读取到内核
通过BGP协议在集群内分发路由信息
学习其他节点的Pod网络信息并广播到全集群

Bird进程异常会导致整个BGP网络失效，常见于系统资源不足时被强制终止。例如，负载过高可能导致Bird进程被杀，进而中断集群通信。

5.5 路由反射器（RR模式）

路由反射器解决大规模集群的全互联模式负担问题：

原理：在大型网络中，指定少数节点作为反射器集中接收路由信息，再分发到其他节点，避免每个节点直接互联。
比喻：类似微信群架构——部门领导（反射器）负责跨部门沟通，员工只需与领导交互，减少直接连接复杂度。

6. Calico与Flannel网络对比

6.1 Flannel核心特点

IP分配：为每个Pod分配全集群唯一的虚拟IP地址
覆盖网络：基于Overlay封装数据包（如VXLAN或UDP），在基础网络上创建虚拟链路(37:24)
数据传递：原封不动传递数据包至目标容器，解封后交付
组件：依赖flanneld守护进程监控etcd变化，实时调整路由

6.2 Flannel局限性

存储瓶颈：etcd需存储全网IP配置，节点过多时（如数万个Pod）扫描效率骤降
无安全策略：不支持网络策略（NetworkPolicy），无法实现Pod间访问控制
适用场景：仅推荐用于小型开发集群，不适用于高安全要求或大规模生产环境

6.3 Calico优势

支持细粒度网络策略（如Ingress/Egress规则）
通过BGP实现高效路由分发，避免Overlay封装开销
更适合中大型集群及安全敏感场景

7. Kubernetes网络实战

7.1 端口号配置

关键组件默认端口号配置：

API Server：6443
etcd：2379/2380
Kubelet：10250
Scheduler：10259
Controller Manager：10257
NodePort服务：30000-32767

注：端口可通过修改镜像和配置文件调整，但需同步修改所有关联配置(09:38)

7.2 Pod通信原理

7.2.1 同节点通信

数据路径：

 Pod1 eth0 ←→ veth pair ←→ cni0网桥 ←→ Pod2 eth0

7.2.2 跨节点通信

Calico方案路由表示例：

 10.24.1.0/24 via 192.168.0.101 dev eth0 10.24.2.0/24 via 192.168.0.102 dev eth0

7.3 网络排障技巧

路由检查：ip route show 查看路由表
端口验证：netstat -tuln 确认端口监听状态
抓包分析：tcpdump -i eth0 在Pod虚拟网卡抓包

8. 核心网络实验

8.1 VLAN配置实验

实验拓扑：

 PC1（VLAN10）←→ Switch ←→ PC2（VLAN10）  PC3（VLAN20）←→ Switch ←→ PC4（VLAN20）

8.1.1 关键命令

 # 创建VLANvlan databasevlan 10vlan 20# 端口分配interface f0/2switchport mode accessswitchport access vlan 10# Trunk配置interface f0/1switchport mode trunk

8.2 OSPF动态路由实验

8.2.1 实验拓扑

四台路由器全互联架构：

 Router0 ↔ Router1  Router0 ↔ Router2  Router0 ↔ Router3

8.2.2 配置要点

Lookback地址：

 interface Loopback0ip address 1.1.1.1 255.255.255.0

OSPF宣告：

 router ospf 1network 10.0.0.0 0.0.0.3 area 0network 1.1.1.0 0.0.0.255 area 0

8.2.3 路径选择验证

修改链路带宽影响路由选择：

 interface f1/0speed 10   # 将带宽从100Mbps降至10Mbps

9. BGP协议核心概念

9.1 关键术语定义

Any Port：接入Calico网络的网卡，每个Pod均创建该接口。
自治系统（AS）：运行BGP协议的逻辑区域，一个节点集群视为一个AS。
BGP Speaker：负责在AS内部或外部交换路由信息的话语者组件。
Workload Endpoint：容器使用的网络接入点；Host Endpoint：主机使用的网络接入点。

9.2 iBGP与eBGP区别

类型	运行范围	通信对象
iBGP	同一AS内部	AS内的节点间路由交换
eBGP	不同AS之间	跨AS的边界路由器通信

当集群划分为多个区域（如AS1和AS2）时，跨区域通信使用eBGP协议。

9.3 通信机制

Calico通过BGP协议自动维护集群路由表：

每个节点生成唯一的Pod网段路由条目
BGP客户端将路由信息分发至所有节点
跨节点通信时，数据包直接通过路由表转发，无需额外封装

10. 网络故障排查方法

10.1 排查优先级顺序

上层排查：检查Pod IP分配是否正确，域名解析是否正常（如DNS故障）
底层排查：确认底层网络（如Calico配置）是否异常，需抓包分析

10.2 抓包分析流程

步骤1：在目的地抓包，检测是否收到客户端数据。若未收到，检查网络策略或路由。
步骤2：在客户端使用
```
 tcpdump -i any
```
抓包，捕获进出数据包：
- 若有IN无OUT：表明服务内部处理故障（如未生成响应包）
- 双向缺失：路由或策略拦截问题
工具命令：
- 抓取指定接口：tcpdump -i ens160（示例）
- 排除端口：tcpdump not port 22
- 保存数据：tcpdump -w packet.pcap

10.3 路由追踪

使用traceroute命令诊断路径：

作用：显示数据包经过的网关和节点地址
限制：公网节点可能屏蔽探测，仅内网可见完整路径
示例：在Pod内执行traceroute www.baidu.com可验证跨节点通信是否经过正确网关

11. 大型网络优化策略

11.1 全互联模式问题

当集群规模扩大时，每个节点需维护全量路由表，导致：

网络带宽消耗剧增
节点负载过高，可能杀死关键进程（如Bird）

11.2 路由反射器解决方案

分区：将大型集群拆分为多个子区域（如区域1、2、3）
选反射器：每个子区域选举一个边界节点作为路由反射器
信息聚合：反射器收集本区域路由，仅与其他反射器交换数据
反射分发：反射器将外部路由信息回传至本区域节点

12. CoreDNS工作机制

12.1 服务发现机制

CoreDNS提供基于域名的服务发现：

域名格式：<service-name>.<namespace>.svc.cluster.local（标准域名结构）
默认地址：CoreDNS Service IP为网段.10地址（如10.96.0.10）
解析依赖：Service创建后自动注册域名，供集群内解析

12.2 DNS策略类型

策略名称	行为	适用场景
ClusterFirst	优先使用集群DNS	默认策略，解析内部服务域名
Default	继承宿主机DNS配置	需访问外部DNS的场景
None	忽略集群配置，自定义DNS	特殊网络需求

策略定义在Pod配置的dnsPolicy字段。

12.3 域名解析规则

CoreDNS按搜索域层级逐层解析：

优先级：从最小范围域开始（如pod-ip.namespace.pod.cluster.local）
扩展：未匹配时向更大范围域递进（如.svc.cluster.local）
配置位置：Pod内/etc/resolv.conf文件定义搜索域顺序

12.4 自定义主机名

通过subdomain字段为Pod设置专属域名：

实现方式：
1. 创建Service并指定subdomain（如subdomain-test）
2. 在Pod配置中定义相同子域
效果：Pod可通过<hostname>.<subdomain>.<namespace>.svc.cluster.local被解析

12.5 外部域名解析

添加外部解析需修改CoreDNS配置：

在Corefile的hosts插件段添加记录
格式：<IP> <域名>（如10.10.10.10 helloword.example.com）
位置：与kubernetes插件同级，确保非嵌套
生效：更新ConfigMap后重启CoreDNS Pod加载新配置

13. 重点解析

13.1 必考组件

K8s核心组件及功能：

组件	核心职责
API Server	集群操作入口，资源操作唯一入口
Controller Manager	维护集群状态（副本、服务账户、资源限制等）
Scheduler	Pod调度（预选策略+优选策略）
etcd	分布式键值存储，保存集群状态

13.2 调度器策略

预选策略：过滤不符合条件的节点（如资源不足）
优选策略：对通过预选的节点评分（如资源空闲率）
策略查看：需查阅K8s源码中的调度算法实现

13.3 网络方案选型

架构设计考量维度：

集群规模大小
性能需求（延迟/吞吐量）
网络策略需求
环境兼容性
运维复杂度

注：实际方案选择由架构师决定，运维需理解方案原理

14. 附录：关键概念速查

14.1 术语对照表

术语	解释
CNI	容器网络接口标准
Overlay Network	在物理网络上构建的虚拟网络层
VXLAN	虚拟可扩展LAN，采用MAC-in-UDP封装
BGP	边界网关协议，用于自治系统间路由交换
IPIP	IP隧道封装模式
VTEP	VXLAN隧道端点，负责封装/解封装

14.2 命令速查

 # 查看路由表ip route show# 检查端口监听netstat -tuln | grep 6443# 查看节点分配子网kubectl get nodes -o custom-columns='NAME:.metadata.name,SUBNET:.spec.podCIDR'

14.3 网络组件核心

K8S 涉及的端口号 (Master & Node)

组件	端口号	协议	说明
API Server	6443	TCP	所有客户端（kubectl）、节点和控制平面组件通信的默认端口。最重要
etcd	2379, 2380	TCP	2379 用于客户端通信，2380 用于 etcd 节点间通信
Controller Manager	10257	TCP	默认安全端口 (HTTPS)
Scheduler	10259	TCP	默认安全端口 (HTTPS)
kubelet	10250	TCP	Node 上 kubelet API 端口，API Server 通过此端口与 kubelet 通信
kubelet	10255	TCP	已弃用的 kubelet 只读 HTTP 端口
kube-proxy	随机的		会开放端口用于 `NodePort`类型的 Service（默认范围：30000-32767）

Master 和 Node 安装时用的端口号

安装时（如使用 kubeadm）通常不涉及额外开放端口，但需确保上述核心组件的端口在防火墙中是开放的。此外，还需要开放：

Node 与 Master 通信：6443 (API Server)
网络插件：例如 Calico 默认使用 179 (BGP协议端口)，Flannel VXLAN 使用 8472 (UDP)。
Pod 网络：确保节点间的 Pod CIDR 网段能够互通（通常是所有端口）。

14.4 K8S 网络模型与核心概念

网络概述 & 虚拟网络

K8S 的核心思想是每个 Pod 都拥有一个独立的 IP 地址（IP-per-Pod），并且所有 Pod 无论在哪台节点上，都可以直接通过这个 IP 进行通信，无需 NAT。这需要一个强大的容器网络接口（CNI） 插件来实现。

虚拟网络/软件定义网络（SDN）：Pod 网络是一个巨大的虚拟网络，它覆盖在物理节点网络之上。物理网络（Underlay Network）负责节点间通信，虚拟网络（Overlay Network）负责 Pod 间通信。
创建 Pod 时生成的网卡：
1. 每个 Pod 都有一个独立的网络命名空间（Net Namespace）。
2. 在 Pod 的命名空间内，会创建一张虚拟网卡（如 eth0）。
3. 在宿主机的根命名空间里，会创建一张对应的虚拟以太网设备（veth pair），另一端“插”在网桥（如 cni0） 或直接由 CNI 插件（如 Calico） 管理。
保持相同 IP：IP 地址是由 CNI 插件分配的。当 Pod 被重新调度时，CNI 插件会释放原来的 IP，并在新节点上重新分配一个。Pod IP 在生命周期内是固定的，但重建后会改变。要维持固定地址，通常使用 Service。

覆盖网络（Overlay Network）与 VXLAN

目的：解决大规模云环境中虚拟网络数量（VLAN ID 只有4096个）不足和跨三层网络大二层互通的问题。
原理：在原有的三层网络（Underlay Network）上，再构建一个虚拟的二层网络。
- 封装：将原始的二层以太网帧（Pod 之间的通信数据）完整地封装到一个 UDP 数据包中。
- 隧道：这个 UDP 包通过物理网络进行传输，就像在物理网络里打了一条“隧道”。
- 解封装：到达目标节点后，拆开 UDP 包，取出原始的以太网帧，交给目标 Pod。
代表：Flannel 的 VXLAN 模式、Calico 的 IPIP 模式（是一种简单的 IP-in-IP 封装）。
VXLAN 组件：
- VTEP：虚拟隧道端点，负责封装和解封装。通常是宿主机上的一个虚拟网卡。
- VNI：VXLAN 网络标识符，24bit，支持 1600 多万个隔离的网络段。

Calico (BGP & 三层路由)

Calico 主要采用纯三层路由的方案，无需封装或仅在必要时封装（IPIP模式）。

原理：每个节点都像一个路由器，学习其他节点上 Pod 网段的路由信息，并直接通过路由进行转发。
BGP：
- 是一个标准的互联网动态路由协议，用于在自治系统（AS）之间交换路由信息。
- Calico 使用 BGP 在每个节点（BGP Peer）之间分发路由信息。每个节点都会告诉其他节点：“我这里有网段 10.244.1.0/24，要访问这个网段的包请发给我。”
- 这样，每个节点的路由表里都有整个集群所有 Pod 网段的路由条目，实现了全路由。
优势：
- 性能高：避免封装和解封装的性能开销（纯BGP模式）。
- 网络策略：提供强大的 NetworkPolicy能力，实现 Pod 间的网络隔离。
IPIP 模式：当节点间的网络无法直接路由（例如不在同一个二层网络）时，Calico 会使用 IPIP 封装，将原始 IP 包再套一个 IP 头，通过隧道传输。

14.5. Pod 通信流程（基于 Calico/BGP）

同一 Node 内 Pod 通信

Pod A (10.244.1.2) 要访问 Pod B (10.244.1.3)。
数据包从 Pod A 的 eth0发出，通过 veth pair 到达宿主机。
宿主机内核根据路由表判断目标 10.244.1.3就在本机（直连路由）。
数据包通过网桥或直接通过 veth pair 转发到 Pod B 的 eth0。

不同 Node 间 Pod 通信 (纯路由模式)

路由学习：Node 1 和 Node 2 通过 BGP 协议交换路由信息。Node 1 告诉 Node 2：“10.244.1.0/24在我这里”。Node 2 告诉 Node 1：“10.244.2.0/24在我这里”。
发起请求：Pod A (10.244.1.2on Node1) 要访问 Pod C (10.244.2.2on Node2)。
查路由表：数据包从 Pod A 到达 Node1，Node1 的路由表显示：10.244.2.0/24 via <Node2的IP> dev eth0。这意味着目标网段下一跳是 Node2 的物理网卡 IP。
直接转发：数据包通过 Node1 的物理网卡 eth0直接发出，经由底层物理网络路由到 Node2 的物理 IP。
交付 Pod：Node2 收到数据包，发现目标 IP 10.244.2.2属于自己上面的 Pod C，通过路由表或网桥将包转发给 Pod C。

如果网络不支持直接路由，上述第4步会变为 IPIP 封装，将原始包封装后发给 Node2，Node2 再解封装。

总结对比

特性	Flannel (VXLAN)	Calico (BGP)
工作原理	Overlay (覆盖网络)，二层帧封装在UDP中	Underlay (底层路由)，三层路由转发
数据封装	有 (VXLAN/UDP)	通常无 (纯路由)，必要时有 (IPIP)
性能	有封装开销，性能稍低	无封装开销，性能更高
规模	适合中大型集群	适合超大规模集群
功能	提供基本网络连通性	提供网络连通性 + 强大的网络策略
要求	对底层网络要求低	对底层网络有一定要求（需支持BGP或允许IPIP）

总结：

总而言之，Kubernetes 网络是一个层次化、插件化的复杂系统，其成功部署依赖于对底层网络原理和上层抽象模型的深刻理解。Flannel 以其“简单易用”的特性成为快速搭建环境的常见选择，而 Calico 则凭借其“高性能、高可控性”的 BGP 路由和强大的网络策略能力，更适合对性能、安全有严苛要求的生产环境。

无论采用何种方案，其最终目的都是透明地满足 Kubernetes 的网络模型要求，实现 Pod 间、服务间的无缝通信。掌握 Pod 通信流程（同节点 veth pair + bridge，跨节点路由）、核心组件（如 Calico 的 Felix、BIRD）的功能，以及熟练运用网络排障工具（如 ping, traceroute, tcpdump）和理解 DNS 解析机制（CoreDNS），是保障整个集群网络健康稳定运行的必备技能。选择合适的网络解决方案并深入理解其运作机制，是构建和运维一个高效、可靠 Kubernetes 集群的核心所在。

查看全文

http://www.xdnf.cn/news/19482.html