企业官网建设流程全解析

容器网络模式：从 Bridge 到 CNI 的底层机制与选型决策

一、当网络成为容器编排的瓶颈：一个真实的跨主机通信故障

生产环境里遇到过一次诡异的网络问题。前端服务调用后端 API，延迟从正常的 5ms 飙到 200ms，且只在跨节点请求时出现。排查了两天，最终发现是 CNI 插件的 SNAT 规则和 kube-proxy 的 iptables 模式冲突，导致同 Service 下跨节点 Pod 通信走了额外的 NAT 转换。

容器网络是 K8s 里最容易踩坑的层。应用层觉得是代码问题，基础设施层觉得是网络问题，最后发现是容器网络模式的配置问题。理解容器网络的底层机制，是定位这类问题的前提。

容器网络要解决的核心问题只有三个：同主机 Pod 通信、跨主机 Pod 通信、外部流量接入。不同网络模式对这三个问题的解法差异很大，选型直接影响性能和运维复杂度。

二、容器网络模式全景：从 Docker 原生到 K8s CNI

容器网络不是单一技术，而是一套分层解决方案。从 Docker 的原生网络模式到 K8s 的 CNI 插件生态，每一层解决不同的问题。

graph TB subgraph Docker原生网络 A[bridge] --> B[容器通过 veth pair 连接 docker0 网桥] C[host] --> D[容器共享宿主机网络命名空间] E[none] --> F[无网络配置] G[overlay] --> H[跨主机 VXLAN 隧道] end subgraph K8s CNI插件 I[Flannel] --> J[VXLAN/Host-GW 模式] K[Calico] --> L[BGP 路由 + eBPF 数据面] M[Cilium] --> N[纯 eBPF 数据面] O[Weave] --> P[VXLAN + 加密] end subgraph K8s网络模型 Q[Pod 内容器共享网络命名空间] R[Pod 间通过 Service 通信] S[跨节点通过 CNI 插件路由] T[外部流量通过 Ingress/NodePort] end B --> Q H --> S L --> S N --> S

Docker 原生网络模式详解

Bridge 模式：Docker 默认模式。每个容器有独立的网络命名空间，通过 veth pair 连接到 docker0 网桥。容器间通过 IP 直接通信，跨主机需要端口映射或 overlay 网络。

Host 模式：容器直接使用宿主机网络栈，没有网络隔离。性能最好，但端口冲突风险高。适合对网络性能要求极高的场景（如网络监控 Agent）。

None 模式：不创建任何网络接口。容器只有 loopback。需要手动配置网络，适合自定义网络方案。

K8s CNI 插件对比

三、生产级容器网络配置：从 CNI 选型到性能调优

3.1 Calico BGP 模式部署

# calico-bgp-config.yaml - 生产级 Calico BGP 配置 apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: default-ipv4-ippool spec: cidr: 10.244.0.0/16 blockSize: 26 # 每个 Node 分配 64 个 IP ipipMode: Never # 禁用 IPIP 封装，使用纯 BGP 路由 vxlanMode: Never # 禁用 VXLAN natOutgoing: false # 禁用 SNAT，Pod IP 直接可达 nodeSelector: all() --- # BGP Peer 配置 - 与物理网络路由器建立 BGP 邻居 apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: tor-router-peer spec: peerIP: 10.0.0.1 # Top-of-Rack 路由器 IP asNumber: 65001 # 物理网络 AS 号 nodeSelector: rack == "rack-1" # 指定机架的节点 --- # BGP 配置全局参数 apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: asNumber: 64512 # 集群 AS 号（私有 AS 范围） logSeverityScreen: Info nodeToNodeMeshEnabled: true # 节点间全互联 BGP mesh

3.2 Cilium eBPF 模式部署

# cilium-values.yaml - Helm 生产配置 tunnel: disabled # 禁用隧道，使用直接路由 autoDirectNodeRoutes: true ipv4: enabled: true hubble: enabled: true # 开启 Hubble 可观测性 relay: enabled: true ui: enabled: true kubeProxyReplacement: "strict" # 完全替代 kube-proxy loadBalancer: algorithm: maglev # 一致性哈希负载均衡 mode: dsr # Direct Server Return，减少 NAT hostPort: enabled: true eBPF: hostRouting: true # eBPF 主机路由，绕过 iptables masquerade: true # eBPF SNAT，替代 iptables masq resources: requests: cpu: "200m" memory: "256Mi" limits: cpu: "1" memory: "1Gi"

3.3 NetworkPolicy 精细化控制

# 微服务网络策略 - 分层隔离 # 第一层：默认拒绝所有入站 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: production spec: podSelector: {} policyTypes: - Ingress --- # 第二层：允许同 namespace 内指定标签的 Pod 通信 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-to-database namespace: production spec: podSelector: matchLabels: app: database policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api-server ports: - protocol: TCP port: 5432 --- # 第三层：允许指定 namespace 的监控流量 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring namespace: production spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: monitoring ports: - protocol: TCP port: 9090 # Prometheus metrics

3.4 网络性能调优参数

#!/bin/bash # network-tuning.sh - 容器网络性能调优脚本 # 1. 调整 conntrack 表大小（高并发场景必须） sysctl -w net.netfilter.nf_conntrack_max=1048576 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200 # 2. 优化 TCP 缓冲区 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216" sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216" # 3. 开启 TCP Fast Open sysctl -w net.ipv4.tcp_fastopen=3 # 4. 减少 TIME_WAIT 连接 sysctl -w net.ipv4.tcp_fin_timeout=15 sysctl -w net.ipv4.tcp_tw_reuse=1 # 5. 增加 SYN 队列长度 sysctl -w net.ipv4.tcp_max_syn_backlog=65535 sysctl -w net.core.somaxconn=65535 # 6. 禁用 iptables 的 conntrack（Cilium eBPF 模式下） # 注意：仅在完全使用 Cilium 替代 kube-proxy 时启用 # sysctl -w net.netfilter.nf_conntrack_helper=0 echo "网络调优参数已应用"

四、容器网络选型的 Trade-offs：性能、复杂度与可观测性

VXLAN vs BGP 路由

VXLAN 封装会引入约 50 字节的额外头部开销，性能损耗 5-10%。但 VXLAN 对底层网络无要求，任何二层网络都能跑。BGP 路由零封装，性能最优，但需要底层网络支持 BGP，且 Pod IP 会泄露到物理网络。在公有云上，BGP 模式需要云厂商支持。

iptables vs eBPF 数据面

iptables 在规则数量超过 5000 条后性能急剧下降（O(n) 匹配）。eBPF 是 O(1) 查找，规则数量对性能无影响。但 eBPF 对内核版本有要求（≥ 4.19），且调试工具链不如 iptables 成熟。Cilium 的 Hubble 弥补了可观测性短板，但学习曲线陡峭。

Flannel 的简单性代价

Flannel 配置简单，5 分钟就能跑起来。但不支持 NetworkPolicy，等于网络全通。在安全要求高的生产环境，这是不可接受的。如果团队规模小、安全要求低，Flannel 是合理选择。否则必须上 Calico 或 Cilium。

Cilium 的激进替代策略

Cilium 的kubeProxyReplacement: strict模式完全替代 kube-proxy，性能提升显著。但一旦出问题，排查难度远高于 iptables。建议先从disabled模式开始，逐步迁移到partial，最后才考虑strict。

跨云混合组网的复杂度

多云场景下，不同云的 VPC 网络不互通。需要用 Submariner 或 Skupper 做跨集群网络打通。这引入了额外的隧道和路由复杂度，延迟也会增加。除非业务必须多云部署，否则不建议引入这层复杂度。

五、总结

容器网络选型的核心逻辑：根据集群规模、安全要求和团队运维能力做决策，不要追求技术先进性。

落地路线建议：

1. 小型集群（< 50 节点）：Flannel VXLAN 快速起步，后续按需迁移到 Calico
2. 中型集群（50-500 节点）：Calico BGP 模式，开启 NetworkPolicy，配合 kube-proxy iptables
3. 大型集群（> 500 节点）：Cilium eBPF 模式，替代 kube-proxy，开启 Hubble 可观测性
4. 性能敏感场景：Host-GW 或 BGP 直接路由，禁用封装，配合内核参数调优

网络是基础设施的基石。选错了可以换，但迁移成本很高。在集群建设初期就做好网络规划，比后期补救要省力得多。