前言

本文聚焦 K8s 集群网络架构与组网方案，详解 flannel、calico 两大 CNI 组件，辅以集群操作管理方法，助力初学者夯实实践基础。

一、客户端访问k8s集群架构图

一幅图带你理解k8s数据流向!!!

二、k8s组网方案

1、为什么要部署CNI网络组件

K8s 本身只定义了容器网络的标准和接口，并没有实现具体的网络功能，CNI 组件就是用来完成 Pod 网络的创建、互联、隔离等核心工作的。
常用的CNI网络组件：flannel、calico

2、flannel概述

2.1、flannel是什么

Flannel 的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。 Flannel 是 Overlay 网络的一种，也是将 TCP 源数据包封装在另一种网络包里面进行路由转发和通信。目前支持 UDP、VXLAN、Host-gw 3种数据转发方式。

2.2、flannel适用场景

适合小型网络、简单、没有大的高并发的情况下

2.3、flannel网段分配规则

flannel 会为集群的每个 Node 预分配一个固定子网段（比如 Node A 分配 10.244.1.0/24，Node B 分配 10.244.2.0/24）。因此，同一个 Node 内的所有 Pod 都属于同一个网段，这是 flannel 的默认设计（它不会给同节点 Pod 分配不同网段）。

2.4、Veth + cni0 网桥的作用

• 每个 Pod 都会创建一对 veth 虚拟网卡：一端在 Pod 的网络命名空间内（名为 eth0），另一端在 Node 的根网络命名空间内（接入 cni0 网桥）。
• cni0 是 flannel 创建的节点内网桥，相当于 Node 内所有 Pod 的 “虚拟交换机”。

2.5、K8S 中 Pod 网络通信

1）Pod 内容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口。
2）同一个 Node 内 Pod 之间的通信
每个 Pod 都有一个真实的全局 IP 地址，同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP地址进行通信，Pod1 与 Pod2 都是通过 Veth（隧道） 连接到同一个 docker0/cni0 网桥，网段相同，所以它们之间可以直接通信。
3）不同 Node 上 Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信。
Overlay Network：
叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来。通过Overlay技术（可以理解成隧道技术），在原始报文外再包一层四层协议（UDP协议），通过主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修改。目前Overlay主要采用 VXLAN。
VXLAN：
将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后在以太网上传输，到达目的地后由隧道端点解封装并将数据发送给目标地址。
Flannel UDP 模式的工作原理：
数据从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到 flannel0 接口，flanneld 服务监听在 flannel0 虚拟网卡的另外一端。

2.6、flannel的跨主机Pod通信

Flannel 通过 Etcd 服务维护了一张节点间的路由表。源主机 A 的 flanneld 服务将原本的数据内容封装到 UDP 报文中， 根据自己的路由表通过物理网卡投递给目的节点主机 B 的 flanneld 服务，数据到达以后被解包，然后直接进入目的节点的 flannel0 接口， 之后被转发到目的主机的 docker0/cni0 网桥，最后就像本机容器通信一样由 docker0/cni0 转发到目标容器。

3、flannel的三种转发数据模式

3.1、VXLAN 模式（目前常用）

前置条件

• Node A：Pod1（10.244.1.2），flannel.1（VTEP 网卡，MAC aa:01），物理 IP 192.168.1.10
• Node B：Pod2（10.244.2.3），flannel.1（VTEP 网卡，MAC aa:02），物理 IP 192.168.1.20
• flanneld 已从 Etcd 同步路由：10.244.2.0/24 → Node B 物理 IP，并配置好 ARP/MAC 映射
  步骤：
  1） Pod1 发数据包给 Pod2，因目标网段不在本地，转发到本机 cni0 网桥
  2） Node A 内核查路由表，将数据包转发到 flannel.1 网卡
  3）内核封装：给内层包加 3 层头部。 VXLAN 头（隧道标识）+ UDP 头（端口标识）+ 物理网络 IP/MAC 头（路由标识）。
  4） 封装后的数据包通过 Node A 物理网卡，经物理网络转发到 Node B 。
  5） Node B 物理网卡收到包，因 UDP 端口是 8472，转发到本机 flannel.1。
  6）内核解包：剥离外层 IP/UDP 头 + VXLAN 头，还原 Pod 原始内层包
  7） Node B 内核查路由，将原始包转发到 cni0 网桥
  8）cni0 网桥通过 MAC 地址转发数据包到 Pod2
  

3.2、UDP模式

UDP 模式的 flannel0 网卡是三层转发，使用 flannel0 时在物理网络之上构建三层网络，属于 ip in udp
前置环境
Node A：Pod1（10.244.1.2），flannel0 网卡，物理 IP 192.168.1.10
Node B：Pod2（10.244.2.3），flannel0 网卡，物理 IP 192.168.1.20
Etcd 存储：10.244.1.0/24 → 192.168.1.10、10.244.2.0/24 → 192.168.1.20
步骤如下：
1） Pod1 访问 Pod2，因目标网段不在本地，数据包发往 cni0 网桥
2） Node A 内核查路由表（flanneld 配置），将数据包转发到 flannel0 网卡
3）flanneld 进程封装（用户态处理）：给原始 IP 包套 UDP + 物理 IP 头
4） 封装后的数据包通过 Node A 物理网卡，经物理网络转发
5） Node B 物理网卡收到包，因 UDP 端口 8285，转发给本机 flanneld 进程
6）flanneld 进程解包（用户态）：剥离外层 UDP + 物理 IP 头，还原 Pod 原始 IP 包
7） flanneld 把原始包转发给 Node B 内核，内核查路由转发到 cni0 网桥
8） cni0 网桥通过 MAC 地址转发数据包到 Pod2

3.3、Host-gw模式

Flannel Host-gw 模式是纯三层路由转发的方案，不做任何数据包封装，直接通过在集群节点间配置静态路由，让跨节点 Pod 流量以三层 IP 包的形式，通过物理网络直达目标节点。 对集群物理网络有硬性要求。

• 集群节点在同一二层网络（物理 IP 互通，如 192.168.1.0/24）。
• Etcd 存储：Pod 网段 → 节点物理 IP（如 Node A: 10.244.1.0/24 → 192.168.1.10；Node B: 10.244.2.0/24 → 192.168.1.20）。
• flanneld 进程负责在各节点写入静态路由规则。

步骤如下：
以 Node A Pod1（10.244.1.2）访问 Node B Pod2（10.244.2.3）为例，流程共 5 步：
1）Pod1 发起请求，目标 IP 10.244.2.3，查本地路由表，发现目标网段不在本机，将数据包发往默认网关 cni0（10.244.1.1）。
2）Node A 内核查询本机路由表，找到 flanneld 写入的规则：10.244.2.0/24 → 网关 192.168.1.20（Node B 物理 IP）。
3）内核直接将 Pod 原生 IP 包（无任何封装）通过物理网卡发往 Node B 物理 IP 192.168.1.20。
物理网络识别 Pod 包的目的 MAC 地址（Node B 物理网卡 MAC），直接二层转发到 Node B。
4）Node B 物理网卡收到 Pod 包，内核查询路由表，发现 10.244.2.0/24 是本机 Pod 网段，将包转发到 cni0 网桥。
5）cni0 网桥通过 MAC 地址找到 Pod2，完成数据转发。

3.4、UDP 模式和 VXLAN 模式对比

1）UDP 模式：用户态处理（flanneld 进程干活）
封装 / 解包不是内核做的，而是 flanneld 进程在用户态完成。
数据要从 内核态拷贝到用户态 给 flanneld 处理，处理完再拷贝回内核态，这个过程叫 “用户态 - 内核态拷贝”，非常耗性能。
简单说：flanneld 是 “包工头”，自己动手封装解包，效率低。
2）VXLAN 模式：内核态处理（网卡自动干活）
封装 / 解包是 Linux 内核在 flannel.1 网卡（VTEP 设备）上直接完成，完全不用 flanneld 进程插手。数据全程在内核态流转，没有拷贝损耗，效率极高。
简单说：flanneld 是 “管理员”，只配置规则，不碰数据，内核来干活，效率高。
总结：UDP 模式和 VXLAN 模式表面上都是把 Pod 流量封装成 UDP 包转发，但核心的处理层面、转发逻辑、效率天差地别

3.5、VLAN和VXLAN的网络范围

VLAN：适用于同一物理网络内的分段。
VXLAN：适用于跨多个物理网络和数据中心的分段。
扩展性：
VLAN：数量有限（通常最多 4096 个 VLAN）。
VXLAN：可以支持多达 16,777,216 个虚拟网络。
实现方式：
VLAN：依赖于二层交换机。
VXLAN：利用三层 IP 网络，使用 UDP 进行封装和传输。

4、calico概述

4.1、calico介绍

Calico不使用隧道或NAT来实现转发，而是把Host当作Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略，完成跨Host转发。
采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。

4.2、calico跨主机Pod访问流程

前置条件：

路由规则：

# Node A 上的路由表 # 1. 本机 Pod 网段直连路由（发往本机 Pod 的流量，直接走 cni0 网桥） 10.244.1.0/24 dev cali0 proto kernel scope link src 10.244.1.1 # 2. 从 Node B 同步的远程 Pod 网段路由（发往 Node B Pod 的流量，下一跳是 Node B 的物理 IP） 10.244.2.0/24 via 192.168.1.20 dev eth0 proto bird metric 32 # Node B 上的路由表 # 1. 本机 Pod 网段直连路由 10.244.2.0/24 dev cali0 proto kernel scope link src 10.244.2.1 # 2. 从 Node A 同步的远程 Pod 网段路由 10.244.1.0/24 via 192.168.1.10 dev eth0 proto bird metric 32

Pod1访问Pod2流程

• Node A 的 Pod1（10.244.1.2）发起请求访问 Pod2（10.244.2.3）。
• Pod1 查本地路由，发现目标网段 10.244.2.0/24 不是本机网段，将数据包发往默认网关（cali0 的 IP 10.244.1.1）。
• Node A 内核查询路由表，匹配到规则 10.244.2.0/24 via 192.168.1.20 dev eth0。
• 内核直接将 原生 Pod IP 包（无封装）通过物理网卡 eth0 发往 Node B 物理 IP 192.168.1.20。
• Node B 物理网卡收到数据包，内核匹配路由规则 10.244.2.0/24 dev cali0，将流量转发到 cali0 网桥。
• cali0 网桥通过 MAC 地址找到 Pod2，完成通信。

4.3、calico适用场景

适合大型网路架构 复杂的架构

4.4、calico的组成

• Calico CNI 插件：负责与 Kubernetes 的 kubelet 对接，为新建 Pod 创建网络命名空间和虚拟网卡，是 Pod 接入集群网络的入口组件。
• Felix：作为 Calico 的核心组件，负责维护宿主机内核的路由规则、FIB 转发信息库，同时配置 iptables 规则实现网络通信限制。
• BIRD：运行 BGP 协议，在集群各节点间同步 Pod 网段的路由规则，让跨节点 Pod 通信的路由信息能被全集群识别。
• Confd：监听 etcd 中的 Calico 配置信息，自动生成 BIRD 和 Felix 的配置文件，保障组件配置的一致性与动态更新。

5、calico安装

kubectl apply -f https://docs.tigera.io/archive/v3.24/manifests/calico.yaml wget https://docs.tigera.io/archive/v3.25/manifests/calico.yaml #获取yaml文件 vim calico.yaml #修改文件 ...... 4601 - name: CALICO_IPV4POOL_CIDR #取消注释 4602 value: "10.244.0.0/16" #取消注释，并将ip地址修改为与初始化集群时--pod-network-cidr指定的IP地址一致 4551 - name: CALICO_IPV4POOL_CIDR 4552 value: "10.244.0.0/16" kubectl apply -f calico.yaml #如果不行需要手动导入 nerdctl -n k8s.io image load -i dashboard-v2.7.0.tar nerdctl -n k8s.io image load -i metrics-scraper-v1.0.8.tar

三、kubenetes操作管理概述

1、管理操作分为两大类陈述和声明
2、k8s 基础信息查看（命令）增删改查
3、项目生命周期创建 发布 更新 回滚删除 所有命令和过程
4、主要发布过程金丝雀发布蓝绿发布滚动发布

四、管理操作分类

Kubernetes 的管理操作分为两大类：
● 陈述式（命令式）管理方法
● 声明式（配置清单式）管理方法

五、操作管理方法

1、基本原理

1）Kubernetes 集群资源管理的唯一入口是通过调用 apiserver 的接口。
2）kubectl 是官方 CLI 命令行工具，用于与 apiserver 通信，将用户命令转化为 apiserver 能识别的请求，实现集群资源管理。
3）查看 kubectl 命令大全：

kubectl --help

中文文档参考：http://docs.kubernetes.org.cn/683.html
4）对资源的“增、删、查”操作较方便，但“改”操作相对复杂。

2、kubectl命令补全功能

yum -y install bash-completion echo "source <(kubectl completion bash)" >> /etc/profile source /etc/profile

3、基础信息查看命令

# 版本与集群信息 kubectl version # 查看版本信息 kubectl api-resources # 查看资源对象简写 kubectl cluster-info # 查看集群信息 # kubectl自动补全和日志查看 source <(kubectl completion bash) # 启用kubectl自动补全 journalctl -u kubelet -f # 查看node节点日志

4、基础资源查看命令

kubectl get <resource> [-o wide|json|yaml] [-n namespace] -n 指定命名空间 -o 指定输出格式 --all-namespaces ：显示所有命名空间 --show-labels ：显示所有标签 -l app=nginx ：筛选指定标签的资源

示例：

kubectl get componentstatuses # 查看 master 节点状态 kubectl get namespace # 查看命名空间 kubectl get all -n default # 查看default命名空间的所有资源

结果如下：

5、命名空间操作

kubectl create ns app # 创建命名空间 kubectl delete namespace app # 删除命名空间

验证：

6、创建Deployment（副本控制器）

# 创建nginx副本 kubectl create deployment nginx-wc --image=nginx -n kube-public # 创建自主式Pod(无控制器，损坏就不会重新创建) kubectl run nginx-pod --image=nginx # 静态 Pod 由节点的 kubelet 直接管理，无需通过 kubectl 命令 # 静态Pod 将 Pod 的 YAML 配置文件放在 kubelet 指定的目录下，kubelet 会自动识别并创建 Pod # 描述某个资源的详细信息 # 因为nginx-Pod是自主式Pod，所以要额外指定类型 # 如果是 受控 Pod（Deployment 创建），kubectl get all 会同时显示 deployment、replicaset 资源 kubectl describe Pod -n default deployment nginx-pod # 查询受控节点的信息 kubectl describe -n default deployment nginx-pod2 # 查看Pod信息 kubectl get pods -n kube-public kubectl get pods # 默认default命名空间

查看kube-public命名空间的Pod信息

7、登入容器与删除Pod

# 登入容器 kubectl exec -it nginx-wc-555467b5f-8wpls bash -n kube-public # 删除Pod kubectl delete pod nginx-wc-555467b5f-8wpls -n kube-public

登入容器：

删除容器：由于是受控Pod，所以会再创建一个Pod

8、扩缩容与删除

kubectl scale deployment nginx-wl --replicas=2 -n kube-public kubectl scale deployment nginx-wl --replicas=1 -n kube-public # 删除deployment控制器 kubectl delete deployment nginx-wl -n kube-public

保持两个副本：

删除depolyment控制器(删除Pod)

总结

本文系统梳理 K8s 组网核心与操作管理要点，对比主流 CNI 组件特性，提炼实用操作命令，为集群部署与运维提供清晰指引。