K8s 组网方案 - 技术栈

从 "kubectl 补全的实操细节" 切入，我们先理清了命名空间 "隔离资源、简化管理" 的实际价值，接着拆解了 K8s 组网绕不开的三类通信场景（Pod 内容器互通、集群内 Pod 跨节点通信、集群内外的请求转发），再从入门级的 Flannel 方案讲起（它的部署逻辑、适配场景），最终深入到生产环境常用的 Calico 方案 ------ 从架构图的通俗解读，到组件原理、通信模式的对比，全程避开晦涩的术语堆砌，只聚焦 "实际怎么用""不同场景怎么选" 的实用问题。希望这些内容，能帮你把 K8s 网络从 "模糊的概念"，变成能落地的操作认知

一，内部三种通信方式

1.1 Pod 内部容器之间的通信

一个 Pod 可以包含多个容器（比如业务容器 + 日志收集容器），这些容器共享同一个网络命名空间（包括 Pod 的 IP、端口、网卡等），因此通信非常简单：

直接通过 localhost + 目标容器端口 通信（比如容器 A 监听 8080 端口，容器 B 可以用localhost:8080访问）。
举例：Pod 内的 Nginx 容器（80 端口）和 PHP 容器，PHP 容器可通过localhost:80调用 Nginx 服务。

1.2. 集群内 Pod 之间的通信

指不同 Pod（可能在同一节点，也可能跨节点）之间的互通，这是 K8s 组网的核心场景，依赖CNI（容器网络接口）插件实现（比如 Flannel、Calico、Weave 等）：

原理：CNI 插件会给每个 Pod 分配唯一的 "集群内虚拟 IP"，并通过路由、隧道（如 VxLAN）等方式，实现跨节点 Pod 的 IP 互通。
通信方式：直接用目标 Pod 的虚拟 IP + 容器端口 通信（比如 Pod1 的 IP 是 10.244.1.3，监听 8080 端口，Pod2 可以用10.244.1.3:8080访问）。

1.3. 集群外部与内部服务的通信

指集群外的请求（比如用户浏览器、其他系统）访问集群内的 Pod/Service，需要通过Service + 暴露方式实现：

常用暴露方式：
1. NodePort：Service 绑定集群节点的某个端口，外部通过节点IP:NodePort访问；
2. LoadBalancer：借助云厂商负载均衡器，外部通过负载均衡器 IP 访问；
3. Ingress：七层代理（基于 HTTP/HTTPS），统一管理多个 Service 的外部访问（通过域名 + 路径转发）。
举例：外部用户通过http://集群节点IP:30080（NodePort）访问集群内的 Nginx Service。

二，Flannel 方案

2.1Flannel 的核心定位与工作原理

Flannel 的核心目标是给集群内每个 Pod 分配唯一的集群内虚拟 IP，并打通跨节点 Pod 之间的网络通路，它的工作逻辑可以拆解为 3 步：

2.1.1. 核心组件

flanneld：运行在每个 K8s 节点上的守护进程（DaemonSet），负责网段分配和数据包转发；
Etcd：存储 Flannel 的核心配置（比如全局 Pod 网段）和各节点的网段分配信息（哪个节点对应哪个子网段）。

2.1.2. 网段分配逻辑

首先在 Etcd 中配置一个「全局 Pod 网段」（默认是10.244.0.0/16）；
Flannel 会给集群内每个节点分配一个「节点专属子网段」（比如 node1 分配10.244.1.0/24，node2 分配10.244.2.0/24）；
节点上的所有 Pod，IP 都从该节点的子网段中分配（比如 node1 的 Pod IP 是10.244.1.2、10.244.1.3）。

2.1.3. 通信流程（两种核心场景）

通信场景	实现方式
同节点 Pod 通信	直接通过节点本机的`cni0`网桥转发，无需 flanneld 干预，效率最高；
跨节点 Pod 通信	Flannel 通过「隧道封装」把 Pod 的数据包封装后，通过节点宿主机的网卡转发到目标节点，再解封装转发给目标 Pod。

2.2、Flannel 的核心通信模式（后端）

Flannel 支持多种通信后端，不同后端适配不同网络环境，最常用的是以下两种：

后端模式	特点	适用场景
VxLAN（默认）	基于隧道封装数据包，无需底层网络做路由配置，兼容性最好；但有轻微性能损耗（封装 / 解封装）	跨网段节点、云环境（通用）
Host-gw	直接在节点间配置静态路由，数据包无需封装，性能接近原生；但要求所有节点在同一二层网络（比如同一交换机 / 子网）	物理机集群、同网段节点集群

解决的核心问题Pod 拥有集群内的专属虚拟 IP，但该 IP 在集群外的真实网络中无法被直接识别、路由，导致跨节点的 Pod 无法直接通信。
Overlay 网络的实现逻辑Flannel 会将 Pod 的数据包 "封装" 在真实网络的数据包中（相当于给 Pod 数据包套一层 "外层包装"），借助真实网络的传输能力将其送到目标节点；到达后再拆除外层封装，将数据包转发给对应的 Pod。
Overlay 网络的本质在已有的真实物理 / 网络环境之上，额外构建一层仅服务于集群内 Pod 的虚拟网络，让 Pod 之间能像处于同一网络中一样直接通信，无需依赖真实网络对 Pod 虚拟 IP 的支持。

Flannel 中最常用的 Overlay 实现是 VxLAN 模式，通过在节点间建立 VxLAN 隧道完成数据包的封装与转发，这也是它能快速适配多数网络环境的关键原因之一。

2.3、Flannel 的优缺点（适用场景）

优点

部署极简：一键式 yaml 部署，几乎无需额外配置，新手友好；
轻量低耗：组件少、资源占用低，对节点性能影响小；
兼容性好：适配绝大多数 K8s 版本和底层网络环境（物理机、虚拟机、云服务器）。

缺点

功能单一：仅解决 Pod 互通，不支持 K8s「网络策略（NetworkPolicy）」（无法限制 Pod 间访问）；
性能有限：默认 VxLAN 模式有封装损耗，Host-gw 模式依赖二层网络；
无高级特性：不支持网络加密、负载均衡、带宽限制等，不适合复杂生产集群。

三， Calico 方案

3.1、 Calico 核心定位

Calico 是一款生产级、高性能、灵活的 K8s CNI 插件 ，核心目标是解决集群内的 Pod 网络连通性 + 细粒度网络访问控制 两大问题。

与 Flannel（仅解决连通性，功能单一）相比，Calico 是更适合生产环境的企业级方案。
核心设计理念：基于三层网络（IP 路由）实现 Pod 通信，无隧道封装（默认模式），最大化网络性能；基于 eBPF/iptables 实现网络策略，提供精准的访问控制。

3.2、 Calico 核心工作原理

1. Pod 网络地址分配

Calico 采用 每 Pod 一个独立 /32 路由 的设计，与 Flannel 的「节点子网段分配」完全不同：

集群全局配置一个 Pod 网段 （如 192.168.0.0/16）。
当一个 Pod 在节点上创建时，Felix 会为其分配一个 唯一的 /32 地址 （如 192.168.32.5/32），并创建一对 veth 设备：一端在 Pod 内部（名为 eth0），另一端在节点宿主机（名为 cali-xxx）。
Felix 会在节点上添加一条路由规则：目标 Pod IP → cali-xxx 网卡，确保节点内的流量能正确转发到 Pod。

通俗来讲Calico 相当于在每台服务器里装了个 "网络管家"，每个容器都得通过这个 "管家" 连网；服务器之间用自己的物理网卡互相连通，这样不管容器在哪个服务器上，都能通过 "自己服务器的管家→物理网卡→目标服务器的管家→目标容器" 的路径，互相发消息。

每个服务器的eth0：是这台服务器的 "物理网卡"，相当于服务器的 "对外网线接口"，node1 的网卡 IP 是 10.100.1.2，node2 的是 10.100.1.3------ 这俩服务器就是通过这个物理网卡连起来的。
服务器里的routers：可以理解成 "服务器内部的网络调度器"，是 Calico 装在这台服务器里的 "网络管家"，负责管这台服务器里所有容器的网络。
服务器里的container1/container2：就是跑在服务器上的应用容器（比如你的 Nginx、MySQL 这些应用），每个容器都有自己的eth0（容器的 "网卡"）。
像cali93a8a7991e1这种长名字的东西：是 Calico 给容器拉的 "专用网络连接线"，把容器的网卡和服务器里的 "网络调度器（routers）" 连起来 ------ 相当于容器的网络 "必须经过这个调度器才能对外通信"。

结语

从 kubectl 的基础配置，到命名空间的隔离逻辑，再到 K8s 组网的三类核心场景，以及 Flannel（轻量入门）、Calico（生产级高性能）两种主流网络方案的拆解，我们覆盖了 K8s 网络最核心的 "基础概念 + 实操逻辑 + 选型标准"。

你不必再纠结 "Pod 为什么能跨节点通信"，也能根据自己的集群场景（测试 / 生产、小规模 / 大规模）快速选对网络插件 ------ 这正是这些内容的价值：不止是 "懂 K8s 网络"，更是 "能用 K8s 网络解决实际问题"。