云原生网络：CNI 容器网络、Overlay/Underlay 与 Service Mesh 数据面

Docker 单机网络（早期）：
  bridge（默认）：容器连到 docker0 网桥，NAT 出网
  host：容器直接用宿主机网络栈
  none：无网络

K8s 的核心要求（CNI 模型）：
  - 每个 Pod 一个独立 IP（Pod 内容器共享该 IP）
  - 任意节点上的 Pod 都能直接互通（扁平网络）
  - 不通过 NAT 做 Pod 间通信（与 Docker 不同）
  → 这要求"跨节点的网络打通"由 CNI 解决

CNI（Container Network Interface）是一套标准接口：
  add / del / check
  由容器运行时（containerd/cri-o）在创建 Pod 时调用

CNI 职责：
  1. 为 Pod 创建 veth 对（一头进 Pod netns，一头连宿主）
  2. 分配 IP（IPAM 插件）
  3. 配置路由（本机 + 跨节点）
  4. 可选：下发网络策略

一次 Pod 创建的网络流程：
  runtime → CNI add → 分配 IP → 建 veth → 配置路由 → Pod 可通信

Flannel 特点：
  - 最常用、最简单，适合中小集群
  - 默认 VXLAN 隧道：每节点一个网段，跨节点走隧道
  - 只有连通性，没有 NetworkPolicy 能力（早期）

局限：
  - 性能一般（隧道封装开销）
  - 无内置网络策略
  - 大规模集群扩展性有限

Calico 特点：
  - 基于三层路由（BGP 交换路由），不走隧道 → 性能好
  - 原生支持 NetworkPolicy（K8s 标准网络策略）
  - 也支持 IPIP/VXLAN 隧道模式（跨云环境）
  - 适合：生产集群、需要网络策略、混合云

两种模式：
  - BGP 模式（纯三成）：跨节点直连，性能最优
  - IPIP/VXLAN 模式：封装跨云，配置简单

Cilium 特点：
  - 基于 eBPF 在内核态实现转发，性能极佳
  - 深度集成 K8s：Service/NetworkPolicy/可观测性
  - 支持 L7 协议感知（HTTP/gRPC/Kafka）的安全策略
  - 与 Service Mesh 数据面天然协同
  - 支持多集群、Hubble 可视化

适用：
  - 需要高性能 + 细粒度安全策略
  - 大规模生产集群
  - 需要丰富的可观测性

Underlay：依赖底层物理/虚拟网络，直接用真实 IP
  - 例：每个 Pod 拿真实 IP（vSphere/云厂商直连）
  - 优点：性能好；缺点：受底层网络限制

Overlay：在底层网络上封装一层虚拟网络（隧道）
  - 例：VXLAN/Geneve 把报文封装进 UDP
  - 优点：跨任何网络（二层隔离也能打通）、IP 规划自由
  - 缺点：封装开销、MTU 变小

隧道开销：
  VXLAN 加 50 字节头 → MTU 需减到 ~1450
  大包不调 MTU → 碎片/黑洞（回到 MTU 话题）

VXLAN：
  - 最普及的 overlay 隧道
  - 外层 UDP 4789，24bit VNI 标识虚拟网络
  - 内核原生支持，兼容性好

Geneve：
  - VXLAN 的进化，灵活可变头
  - OpenStack/K8s 新兴场景使用
  - 主要被 OVS 与较新 Cilium 采用

隧道与 MTU：
  配 overlay 时务必把 Pod/容器 MTU 调成 1450
  否则大包 DF=1 → MTU 黑洞（见网络排障专题）

# 查看本机隧道 / veth（诊断 Pod 网络）
ip link show            # 找 veth / vxlan / cilium_ 接口
ip -d link show vxlan0  # 看隧道类型与 VNI
route -n                # 看 Pod 网段路由到哪

eBPF（extended Berkeley Packet Filter）：
  - 允许在内核挂载受限的、经安全验证的程序
  - 网络路径上：转发、负载均衡、策略直接在数据面执行
  - 无需加载内核模块，性能接近原生

相比 iptables 的优势：
  - 不用每包走线性规则链（iptables 规则多时慢）
  - 更细粒度的观测（每个流、每包）
  - 策略内联到转发路径，延迟低

Cilium 利用 eBPF：
  - Service 负载均衡（替代 kube-proxy iptables）
  - NetworkPolicy 内核态执行
  - Hubble 流日志 / 指标（可观测性）

传统（iptables + Overlay）：
  Pod 流量 → 路由 → tunnel → iptables NAT → 转发
  每一跳都有内核规则链开销

Cilium/eBPF：
  Pod 流量 → 在内核 eBPF 程序直接决策（转发/负载均衡/策略）
  规则内联，减少拷贝与规则遍历 → 延迟更低、PPS 更高

典型收益：
  高并发场景 PPS 提升明显
  连接建立延迟更低（对长连接服务更友好）
  复杂策略组合不再拖慢转发

CNI 解决"Pod 到 Pod 连通"；
服务网格解决"应用到应用的流量治理"：
  - 服务发现与负载均衡
  - 重试、超时、熔断
  - 灰度（流量比例）、故障注入
  - 双向 TLS、细粒度授权
  - 全链路可观测

两种形态：
  边车（Sidecar）模式：每个 Pod 带一个 Envoy，流量都经它
  无代理（eBPF）模式：Cilium 直接把治理下放到内核

Envoy 是 Istio 的数据面（Sidecar 代理）：
  入口：进入 Pod 的流量先到 Envoy（iptables 重定向）
  出口：Pod 发出的流量也经 Envoy 出去
  → 应用无感，但所有流量可控、可观测

核心能力（由控制面下发配置，xDS）：
  - Listener/Route/Cluster 三级结构定义流量路径
  - 负载均衡、健康检查、熔断、重试
  - TLS 终止/发起、授权（RBAC）
  - 分布式追踪（请求上下文传递）

与 CNI 的关系：
  CNI 管"通不通"，Mesh 管"怎么走、走多好"
  两者叠加使用（Cilium 也能与 Mesh 整合）

# K8s 网络策略示例（Calico/Cilium 支持）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080
          protocol: TCP

NetworkPolicy 语义：
  - 选择目标 Pod（podSelector）
  - 定义 ingress / egress 规则（谁可以进 / 谁可以出）
  - 端口级、命名空间级、IP 段级控制
  - 白名单模型：默认拒绝 + 显式放行

要点：
  - 只有支持策略的 CNI（Calico/Cilium）才生效
  - Flannel 默认无策略
  - 策略冲突排查比防火墙更麻烦 → 先看 CNI 是否支持

□ 默认拒绝 + 最小放行（纵深防御）
□ 命名空间作为安全边界，跨命名空间需显式策略
□ 敏感服务（DB/内部 API）加网络白名单
□ 审计策略变更，与审计专题配合
□ 东西向流量加密（服务网格 mTLS）

□ 按集群规模选 CNI：入门 Flannel / 生产 Calico / 高性能 Cilium
□ Overlay 场景统一调小 MTU（1450），避免隧道黑洞
□ 默认拒绝 + 最小放行配置 NetworkPolicy
□ 服务调用走 Service/DNS，别依赖 Pod IP
□ 高并发关键路径考虑 eBPF 方案（Cilium）
□ 服务网格与 CNI 职责分清：CNI 管连通、Mesh 管治理
□ 用 Hubble/流量日志做网络可观测性
□ 多集群/多云场景规划好网络策略边界

云原生网络 = CNI 打通 Pod（连通） + 策略控制流量（安全）
+ Service Mesh 治理流量（质量）；性能不够时用 eBPF。