Kubernetes

K8s 完整网络体系详解

·11 分钟阅读·4360 字
K8s原理高阶简答题
📋 目录

K8s 完整网络体系详解

核心概念 K8s 网络四大强制模型定义了 CNI 必须满足的基础规范，整个网络体系从 Pod 内部到集群外部共 7 层。

1. K8s 网络四大强制模型（CNI 必须满足的基础规范）

K8s 官方定义统一网络标准，任何 CNI（Calico/Flannel/Cilium）都必须实现四条规则：

  1. 所有 Pod 之间无需 NAT 直接通信，不管是否同节点、同 Namespace；
  2. 所有 Node 可以直接和所有 Pod 互通（宿主机 ↔ Pod 直连）；
  3. Pod 访问 Service、Service 访问后端 Pod 标准四层转发；
  4. Pod 访问外部集群网络、外部访问 NodePort/LoadBalancer 走标准化转发。

整个网络体系分层：

  1. Pod 内部网络（容器间通信）
  2. 节点内 Pod 互通
  3. 跨节点 Pod 互通（CNI 核心能力）
  4. Service 四层负载均衡（kube-proxy / CNI eBPF）
  5. 七层网关 Ingress
  6. 网络访问控制 NetworkPolicy
  7. 集群外部流量进出（NodePort / LoadBalancer / Ingress）

2. 第一层：Pod 内部网络（同一 Pod 多容器 / Sidecar）

2.1. 网络模型：一个 Pod = 一个独立 Network Namespace

  • 一个 Pod 下所有容器共享同一个网络栈：共用网卡、IP、端口、路由、DNS；
  • 同一 Pod 内多容器（主业务 + Sidecar）直接通过 localhost 互相访问，无需走集群网络；
  • 容器间端口不能冲突，同一 Pod 端口全局唯一。

2.2. 实现原理

  1. pause 基础容器：先创建网络命名空间，创建 veth pair 连宿主机；
  2. 业务容器、sidecar 加入 pause 的 netns，共用网络；
  3. 通信方式：127.0.0.1 本地直连，无任何网络开销。

3. 第二层：同一 Node 内不同 Pod 互通（CNI 基础能力）

3.1. 核心设备：veth pair 虚拟网线

每创建一个 Pod，CNI 生成一对 veth：

  • 一端：caliXXXX / vethXXXX 留在宿主机内核；
  • 一端：Pod 内部 eth0；
    相当于一根虚拟网线连接宿主机和 Pod。

3.2. 同节点通信流程

PodA IP 10.244.1.10 → 宿主机 cali-A 网卡 → 宿主机内核路由转发 → cali-B 网卡 → PodB eth0
全程宿主机内核转发，无跨主机封装，性能极高。

4. 第三层：跨 Node Pod 互通（CNI 核心，分两大技术路线）

4.1. 路线1：Overlay 隧道网络（Flannel VXLAN / Calico IPIP）

适用：云厂商二层隔离，宿主机之间不能三层直连。
原理：

  1. 每个节点创建隧道网卡 vxlan0 / tunl0；
  2. 跨节点 Pod 数据包封装在宿主机IP报文内部传输；
  3. 对端节点隧道设备解封装，转发到目标 Pod；
    缺点：封装解封装带来额外CPU开销。

4.2. 路线2：BGP 三层路由网络（Calico 标准方案）

适用：自建机房、底层网络支持BGP三层互通。
原理（核心）：

  1. 每个节点运行BIRD进程，作为小型路由器；
  2. 每个节点分配独立Pod子网，BGP全网广播子网路由；
  3. 宿主机内核自动生成路由表：目标Pod网段 → 下一跳=对端宿主机物理IP；
  4. 无隧道、无封装，裸三层转发，性能最优；
    云环境底层二层隔离时可叠加IPIP隧道，兼顾互通与性能。

5. 第四层：Service 四层负载均衡（kube-proxy / eBPF CNI）

解决问题：Pod 弹性扩缩容、IP 动态变化，提供固定访问入口 ClusterIP。

5.1. Service 四种访问类型

  1. ClusterIP：集群内部访问，默认；
  2. NodePort：宿主机开放端口，外部可通过 节点IP:端口 访问；
  3. LoadBalancer：对接云厂商LB，统一公网入口；
  4. ExternalName：映射外部第三方服务地址。

5.2. 三种转发实现模式

5.2.1. （1）iptables 模式（老旧低并发集群）

kube-proxy 批量生成海量 iptables 规则，流量链式匹配；
缺点：上万后端时规则爆炸，匹配延迟高。

5.2.2. （2）ipvs 模式（传统集群主流）

内核四层虚拟服务器，哈希表存储后端列表，匹配速度远高于iptables；
kube-proxy 独立DaemonSet运行，和CNI职责分离。

5.2.3. （3）eBPF 模式（Cilium / Calico 新一代）

废弃独立 kube-proxy，由CNI在tc/cgroup内核钩子加载eBPF程序统一处理：

  • Pod互通、NetworkPolicy、Service负载均衡一套内核程序完成；
  • eBPF Map动态更新后端Pod，毫秒级生效；
  • 支持本地优先拓扑路由、会话保持、权重，性能最优。

5.3. Service 完整访问流程

  1. Pod 请求 svc-name.ns.svc.cluster.local，CoreDNS 解析出固定 ClusterIP；
  2. 数据包到宿主机内核 iptables/ipvs/eBPF；
  3. 内核随机/轮询转发到后端任意健康Pod；
  4. 回程流量做源NAT，保证响应正常返回。

6. 第五层：集群DNS CoreDNS（服务发现底层支撑）

6.1. 部署形态

DaemonSet/Deployment，多副本高可用，监听集群DNS端口53。

6.2. 域名解析层级

  1. 同命名空间简写：service-name
  2. 跨命名空间：service-name.ns
  3. 完整域名：service-name.ns.svc.cluster.local
  4. StatefulSet 固定Pod域名：pod-name.svc-name.ns.svc.cluster.local

6.3. 工作机制

  1. CoreDNS 持续Watch apiserver Service/Endpoint资源；
  2. 自动维护域名 → ClusterIP 映射；
  3. Pod /etc/resolv.conf 自动注入集群DNS地址，所有域名请求转发CoreDNS。

7. 第六层：七层流量网关 Ingress（HTTP/HTTPS 专用入口）

7.1. 两个核心概念区分

  1. Ingress 资源对象：仅声明路由规则（域名、路径、后端Service、TLS证书），不处理流量；
  2. Ingress Controller：真实反向代理程序（Nginx-Ingress / Traefik / Istio Gateway），DaemonSet/Deployment部署，持续同步Ingress规则并动态更新配置。

7.2. 层级关系

外部公网LB → Ingress NodePort/LoadBalancer → Ingress Controller Pod → 后端业务Service → Pod
能力：域名路由、SSL卸载、限流、重写、灰度、证书统一管理，弥补Service只能四层转发的短板。

8. 第七层：网络访问控制 NetworkPolicy（Pod 防火墙）

8.1. 基础说明

原生K8s NetworkPolicy是CNI依赖型资源，仅支持Calico/Cilium等高级CNI，Flannel无实现。
作用：精细化控制Pod入站、出站流量，实现微服务隔离，默认全通，匹配规则才放行。

8.2. 匹配维度

源/目标Pod标签、Namespace、IP网段、端口、TCP/UDP协议。

8.3. 底层实现两种方式

  1. iptables：Felix生成大量过滤链，流量逐层匹配；
  2. eBPF：内核tc钩子直接拦截丢弃，无链式损耗，大规模策略性能更强。

9. 第八层：进出集群外部流量模型

9.1. 集群内部 → 外网

Pod 访问互联网，宿主机SNAT转换源IP为节点物理网卡IP。

9.2. 外网 → 集群内部 三种路径

  1. NodePort：宿主机开放30000~32767端口，公网直接访问节点IP+端口；
  2. LoadBalancer：云厂商分配独立公网IP，流量转发到集群NodePort；
  3. Ingress + LB：公网域名统一接入七层网关，业务标准方案。

10. 两大主流CNI架构完整对比

10.1. 架构A：传统分离架构（Calico iptables / Flannel）

  • CNI：负责Pod IP分配、跨节点互通、NetworkPolicy；
  • kube-proxy：独立组件，iptables/ipvs实现Service转发；
    两套独立内核规则，维护两套组件。

10.2. 架构B：eBPF 一体化架构（Cilium / Calico eBPF）

  • 仅一套CNI组件，删除kube-proxy；
  • eBPF统一承载：IPAM、三层互通、NetworkPolicy、Service四层负载均衡；
    内核一套程序处理全部网络逻辑，性能更好、组件更少。

11. 完整流量链路示例（外部域名访问业务Pod）

公网客户端 → 云LB → Nginx Ingress Controller(NodePort) → Service ClusterIP(eBPF/ipvs) → 后端业务Pod
拆解每层网络职责：

  1. LB：公网流量接入；
  2. Ingress Controller：七层域名路由、SSL解密；
  3. Service四层负载均衡：分发到后端Pod；
  4. CNI：跨节点路由、Pod网络互通；
  5. NetworkPolicy：校验流量是否允许访问Pod。

12. 面试分层速记总结

  1. Pod内网络：共享netns，localhost互通，pause容器创建网络栈；
  2. 同节点Pod：veth pair虚拟网卡，宿主机内核转发；
  3. 跨节点Pod：Overlay隧道(VXLAN/IPIP) / Calico BGP三层路由；
  4. 服务发现：CoreDNS解析Service固定ClusterIP；
  5. 四层负载：kube-proxy(iptables/ipvs) 或 eBPF一体化CNI；
  6. 七层网关：Ingress资源定义规则，Ingress Controller真实代理；
  7. 访问隔离：NetworkPolicy由CNI转为iptables/eBPF过滤规则；
  8. 外部流量：NodePort/LoadBalancer/Ingress三种接入方式。

关联文档

返回首页订阅更新