Kubernetes网络原理深度解析

1 Kubernetes网络模型

Kubernetes 网络模型是其实现容器化应用高效通信的基础框架。它致力于解决容器编排环境中复杂的网络连通性、服务发现与负载均衡等问题，追求让容器、Pod 等网络端点像传统主机网络一样简洁、可预测地通信。其核心设计目标包括：各 Pod 拥有独立且可直接访问的 IP 地址，同一 Pod 内容器共享网络命名空间，服务（Service）提供稳定网络入口并实现负载分发，助力应用在集群内便捷通信与扩展。

2 Kubernetes网络的实现机制

2.1 容器和容器之间的通信

同一 Pod 内的容器，因共享网络命名空间（包括网络协议栈、IP 地址、端口等资源），可通过 localhost 加端口的方式直接通信，就像传统单机进程间通信一样高效，无需额外网络转发开销，利用共享的网络资源快速交互数据。

2.2 Pod和Pod之间的通信

Pod 间通信需解决跨网络命名空间、跨主机的问题。Kubernetes 依赖网络插件（如 CNI 插件）构建集群网络，让每个 Pod 分配到集群内唯一 IP 。通信时，借助虚拟网络设备（如网桥、隧道）、路由规则等，封装、转发数据包。 overlay 网络方案会对 Pod 流量封装后跨主机传输，再解封装投递；基于主机路由的方案则通过配置主机路由表，指引 Pod 流量在集群主机间正确转发，保障不同主机上 Pod 能基于 IP 直接通信。

3 CNI网络模型

3.1 CNI网络模型简介

CNI（Container Network Interface ）是容器网络接口标准，为容器平台（如 Kubernetes ）与网络插件解耦提供规范。它定义了简洁的 JSON 格式接口，让容器运行时（如 containerd、runc ）能调用不同网络插件，动态为容器配置网络、分配 IP 等。借助 CNI，Kubernetes 无需关注网络实现细节，可灵活对接 Flannel、Calico 等多样网络方案，适配不同集群网络需求，推动容器网络生态发展。

3.2 CNI网络模型详解

CNI 工作流程包含“添加网络”与“删除网络”阶段。“添加网络”时，容器运行时调用 CNI 插件，传递容器网络命名空间等信息，插件创建网络设备（如 veth 对），一端接入容器命名空间，另一端连入主机网络（或 overlay 网络端点），分配 IP 并配置路由、防火墙规则等，完成容器网络接入；“删除网络”则是反向操作，释放网络资源，确保集群网络资源合理回收。同时，CNI 支持链式插件，可组合多个功能插件（如先做网络隔离，再做 IP 分配），灵活扩展网络功能。

4 开源容器网络方案

4.1 Flannel插件的原理和部署示例

原理：Flannel 是经典 CNI 插件，为集群提供 overlay 网络。它默认用 VXLAN 模式，为主机分配子网，每个主机上 Pod 从主机子网取 IP 。Pod 跨主机通信时，Flannel 守护进程（flanneld ）捕获流量，封装成 VXLAN 数据包，通过主机间 UDP 隧道传输，目标主机解封装后投递到目标 Pod 。还支持 host - gateway 模式，利用主机路由表转发 Pod 流量，减少封装开销，提升性能。
部署示例：在 Kubernetes 集群，先下载 Flannel 资源清单（kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml ），清单会创建 DaemonSet ，在各节点运行 flanneld ，配置集群网络参数（如 Pod 网段）。部署后，检查 Pod 状态（kubectl get pods -n kube-flannel ），确保正常运行，测试 Pod 跨主机通信，验证网络连通性。

4.2 Open vSwitch插件的原理和部署示例

原理：Open vSwitch（OVS ）是虚拟交换机，可灵活定义网络流表规则。在容器网络，它作为底层网络设备，构建 overlay 网络（如 GRE、VXLAN 隧道）。通过流表匹配数据包源目 IP、端口等，实现转发、隔离、QoS 等功能。配合 Kubernetes ，OVS 可作为网络插件底层支撑，为 Pod 提供网络连接，基于流表精细控制 Pod 流量，适配复杂网络策略场景。
部署示例：先在集群节点安装 OVS 软件包（如在 Ubuntu 用 apt install openvswitch-switch ）。然后部署基于 OVS 的 CNI 插件（如 Multus 配合 OVS 配置网络），或使用专门集成 OVS 的网络方案。通过配置 OVS 网桥、隧道端口，编写 CNI 配置文件指定 OVS 网桥、IP 分配等，应用配置后，创建 Pod 测试网络，利用 ovs-vsctl 命令查看流表、端口状态，验证网络功能。

4.3 直接路由的原理和部署示例

原理：直接路由（Direct Routing ）摒弃 overlay 封装，依赖主机路由表实现 Pod 跨主机通信。网络插件为每个主机分配 Pod 子网，在主机上配置静态路由，把其他主机 Pod 子网的流量发往对应主机物理网卡。借助 BGP 协议（如 Calico 的 BGP 模式），集群主机间自动交换路由信息，动态维护路由表，让 Pod 流量基于物理网络三层转发，减少封装延迟，提升网络性能，适合对网络效率要求高的场景。
部署示例：以 Calico 开启直接路由模式为例，修改 Calico 配置，启用 ipipMode: Never（关闭 IPIP 封装），配置 BGP 邻居（如集群主机间建立 BGP 连接）。部署 Calico 资源清单后，Calico 节点守护进程（calico-node ）会在主机配置路由规则，通过 BGP 协议同步路由。测试时，在不同主机 Pod 间 ping 或传输数据，查看主机路由表（ip route ），确认跨主机 Pod 路由正确，验证直接路由效果。

4.4 Calico插件的原理和部署示例

原理：Calico 是强大的 Kubernetes 网络方案，基于 BGP 协议和 Linux 路由实现网络。它为每个 Pod 分配独立 IP，利用主机路由表转发流量，无需 overlay 封装（也支持 IPIP 模式）。通过网络策略（NetworkPolicy ），基于标签精细控制 Pod 间访问，如允许或拒绝特定命名空间、标签的 Pod 通信。Calico 节点代理（calico-node ）负责维护路由、应用网络策略，控制器组件管理网络资源分配与策略同步，适配大规模集群网络需求。
部署示例：使用官方资源清单部署，kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml 。部署后，检查 calico-node Pod 状态（kubectl get pods -n calico-system ）。配置网络策略，例如创建一个策略，允许 app=web 标签的 Pod 被 app=client 标签的 Pod 访问：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-web-accessnamespace: default
spec:podSelector:matchLabels:app: webingress:- from:- podSelector:matchLabels:app: client

应用策略后，测试 Pod 间通信，验证网络策略生效情况。

5 Kubernetes网络策略

5.1 网络策略概述

Kubernetes 网络策略（NetworkPolicy ）是实现 Pod 网络访问控制的核心机制，基于标签选择器，定义 Pod ingress（入站）和 egress（出站）流量规则。它能精细管控哪些 Pod 可与其他 Pod、服务甚至外部网络通信，像设置白名单、黑名单，隔离敏感应用网络，保障集群网络安全，适配多租户、微服务权限分离等场景。

5.2 Selector功能说明

Selector（选择器）是网络策略的关键，通过标签匹配 Pod 。podSelector 用于选定受策略影响的 Pod 集合；ingress.from.podSelector 和 egress.to.podSelector 则指定流量来源或目标的 Pod 标签。例如，策略中 podSelector: {matchLabels: {role: backend}} 选中所有带 role=backend 标签的 Pod ，ingress.from.podSelector: {matchLabels: {role: frontend}} 允许前端 Pod 访问，利用标签灵活、动态地定义网络访问关系。

5.3 为命名空间配置默认的网络策略

可为命名空间配置默认网络策略，控制该命名空间下未明确配置策略的 Pod 流量。创建默认拒绝策略，拒绝所有入站和出站流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: default-denynamespace: my-namespace
spec:podSelector: {}  # 匹配命名空间下所有PodpolicyTypes:- Ingress- Egressingress: []      # 无入站规则，默认拒绝egress: []       # 无出站规则，默认拒绝

后续为该命名空间内特定 Pod 配置允许规则，可覆盖默认拒绝，实现“默认隔离，按需开放”，提升命名空间网络安全性。

5.4 网络策略应用示例

假设电商应用，有 frontend（前端）、backend（后端）、db（数据库）Pod 。创建策略允许前端访问后端，后端访问数据库，拒绝其他流量：

后端 Pod 策略（允许前端访问）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: backend-allow-frontendnamespace: default
spec:podSelector:matchLabels:app: backendingress:- from:- podSelector:matchLabels:app: frontend

数据库 Pod 策略（允许后端访问）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: db-allow-backendnamespace: default
spec:podSelector:matchLabels:app: dbingress:- from:- podSelector:matchLabels:app: backend

前端、后端、数据库的出站策略可按需配置，如限制后端只能访问数据库，通过网络策略构建清晰、安全的应用网络访问链路。

5.5 网络策略的一些特殊情况和功能限制

网络策略仅在支持的网络插件（如 Calico、Cilium ）下生效，若网络插件不支持，策略配置无效。策略匹配是“与”逻辑，多个策略叠加需注意规则冲突。对同一 Pod ，入站规则需所有策略允许才放行，存在调试复杂问题。且网络策略主要管控 Pod 间七层以下流量，对应用层协议（如 HTTP 路径）精细控制能力有限，需结合服务网格（如 Istio ）等方案补充。