第二章 k8s网络-1 核心基础概念
前置知识回顾
- 上一节已明确Pod是K8s集群中运行任务的最小单位，本节将讲解K8s网络，是打通集群内Pod通信、实现集群正常运行的基础，类比武侠中任督二脉贯通，是后续深入学习K8s、部署集群的核心前提。
K8s网络基本概述
-
K8s网络模型的核心假定：所有Pod处于可直接连通的扁平网络空间中，即不同节点上的Pod可通过对方IP直接发送数据，底层基于覆盖网络或非覆盖网络实现。
-
该网络模型在GCE（谷歌云平台计算引擎）中是默认支持的，无需额外配置；但国内项目多部署在阿里云、百度云、华为云或自建机房，需要自行实现扁平网络假设，先打通不同节点上容器的访问能力，K8s才能正常运行。
扁平网络的3个硬性要求
要实现K8s要求的扁平网络，必须满足以下3个条件，且均不允许使用NAT（网络地址转换）：
-
集群内任意Pod可与任意其他Pod通信，包含跨节点通信场景
-
集群上运行的程序可与同一节点上的任意Pod通信
-
每个Pod拥有独立、唯一的IP地址，其他Pod可通过该地址直接访问
CNI（容器网络接口）核心概念
CNI是K8s官方提供的容器网络实现规范标准，核心作用是解决容器与容器之间的网络通信问题，不解决其他类型网络问题。
CNI核心特性
-
采用插件化设计，可通过集成各类CNI插件实现集群内部网络互通
-
本质是一组可执行程序的调用规范，并非HTTP、gRPC等Web/网络接口，只要实现CNI定义的接口（ADD：将容器添加到网络、DEL：从网络删除容器、CHECK：检查网络是否满足预设标准）即可接入K8s集群，符合“接口符合定义即可接入”的设计原则
CNI调用流程
-
容器运行时（CRI，如containerd、CRI-O）通过JSON格式配置文件描述网络插件的配置与使用规则
-
CRI通过标准输入将配置传递给CNI可执行程序，再通过标准输出接收插件的执行结果，完成容器网络配置
CNI插件5大分类
| 分类 | 核心作用 | 典型插件 |
| — | — | — |
| Main插件 | 负责创建具体网络设备 | bridge（创建网桥，连接容器与主机网络）、ipvlan（为容器增加ipvlan网卡）、loopback（配置容器回环接口）、macvlan（为容器提供Mac地址）、ptp（创建一对veth虚拟以太网设备对，一端放入容器网络命名空间，是容器网络通信的基础组件）、vlan（分配一个vlan设备）、host-device（将主机已存在的设备移动到容器内部） |
| IPAM插件 | 负责Pod的IP地址分配与回收 | dhcp（向容器DHCP发起请求分配/回收IP）、host-local（基于预先配置的IP段进行本地分配）、static（手动分配静态IPv4/IPv6地址，仅用于特殊测试场景） |
| 元数据（Meta）插件 | 功能补充类插件，无法归入前两类 | tuning（通过sysctl调整网络设备参数）、portmap（通过iptables配置端口映射）、bandwidth（通过TBF令牌桶过滤算法实现流量限流）、sbr（设置基于源地址的路由）、firewall（通过iptables配置容器进出流量限制规则） |
| Windows插件 | 适配Windows节点的K8s网络实现 | win-bridge（创建Windows网桥）、win-overlay（实现Windows环境下的扁平化网络）
注：当前K8s生态仍以Linux系统为主，Windows插件使用场景较少 |
| 第三方网络插件 | 非官方开发、基于CNI标准实现的可执行程序，是解决扁平网络的核心组件，无统一标准但功能丰富 | Flannel（弗兰）、Calico、Cilium、Weave、OVN等 |
主流第三方CNI插件对比与选型
注：以下对比数据为2023年11月20日从GitHub截取，Flannel是早期主流方案，Calico当前在点赞数、fork数、贡献者数等指标上处于领先地位，Cilium作为下一代项目数据增长迅速。
网络模型分类
-
非封装网络（未封装）：数据报文直接通过物理网络传输，无额外封装，类似直接寄送未包装的物品，依赖底层路由可达，是数据中心场景的基础网络形态，Calico支持该模式
-
封装网络：在物理网络之上构建逻辑虚拟网络，数据报文传输时会额外封装一层头部（常用VXLAN、IPIP、GRE、NVGRE等隧道技术），类似给物品加快递盒，会额外消耗少量性能但灵活性更高，Flannel、Weave、Cilium采用该模式
核心特性对比
-
路由分发：支持通过BGP协议将Pod的地址信息生成路由表，实现跨节点通信，Calico、Weave、Cilium均支持
-
网络策略：支持自定义Pod访问规则（如允许A Pod访问B Pod、拒绝B Pod访问A Pod），实现网络隔离与安全控制，默认所有Pod之间互通，网络策略是集群安全的核心配置；Flannel不支持该特性，也是其逐渐被淘汰的重要原因之一，Calico、Cilium、Weave均支持
-
集群网格：支持跨K8s集群的Service通信，适用于大规模多集群架构场景
行业选型建议
-
当前主流生产方案：Calico，功能全面、稳定性高，经过大规模生产验证，满足绝大多数场景需求
-
下一代主流趋势：Cilium，基于eBPF（可扩展伯克利数据包过滤器）实现，可在内核层直接执行程序，性能更高，且提供强大的可观测性能力（可视化Pod间流量、资源利用率等），但目前稳定性仍在逐步验证中
运维场景优先选择经过生产验证的稳定方案，不盲目追新，避免大规模集群故障
Pod网络创建组件调用流程
-
K8s调度器通过API Server监听未绑定的Pod，完成Pod到节点的调度绑定
-
节点上的kubelet监听API Server，发现本节点有Pod待创建，调用CRI（容器运行时）启动Pod创建流程
-
CRI创建Pod的cgroup与网络命名空间，完成网络环境初始化
-
kubelet的plugin机制调用CNI可执行程序，以Flannel为例：先调用bridge插件创建网桥并关联，再调用IPAM插件完成IP地址分配
-
IP分配结果返回后，完成Pod容器的网络配置，kubelet通过CRI拉取Pod所需容器镜像，启动容器并加入Pod的网络命名空间，完成整套Pod启动流程
AI 总结
本节是K8s网络的核心基础篇，首先明确了K8s扁平网络的3个硬性要求，引出CNI容器网络接口规范：CNI是K8s实现容器网络能力的插件化标准，分为主插件、IPAM、元数据、Windows、第三方5大类，其中第三方插件是解决扁平网络的核心。当前生产环境主流选择是Calico，下一代趋势是基于eBPF的Cilium，运维场景优先选择稳定性优先的方案。同时梳理了Pod创建过程中CNI的完整调用链路，为后续学习具体网络插件实现打下基础。