重温 K8s 基础概念知识系列八（ K8S 高级网络）

文章目录

• • [一、K8s 网络模型回顾](#一、K8s 网络模型回顾)
  • [二、CNI 插件与优化](#二、CNI 插件与优化)
  • [三、K8s 负载均衡](#三、K8s 负载均衡)
  • [四、Ingress 最佳实践](#四、Ingress 最佳实践)
  • 五、进阶优化建议
  • [六、 总结一句话](#六、 总结一句话)

Kubernetes 网络是集群运行的核心，高级网络实践通过优化 CNI、Service 网格、负载均衡和多集群网络应对复杂场景。本章笔记聚焦网络性能优化、服务网格集成、多集群网络和安全策略，提炼核心技术、工具使用和最佳实践。

一、K8s 网络模型回顾

K8s 网络设计的四中方式：

1. Pod 网络：Pod-to-Pod 可通信（跨节点、跨主机），每个 Pod 拥有唯一 IP，不依赖 NAT；容器共享网络栈。
2. Service 网络：Pod-to-Service 可通信，Service 提供稳定访问入口，内部通过 kube-proxy 或 eBPF 实现负载均衡；ClusterIP、NodePort、LoadBalancer 提供服务发现。
3. Ingress：HTTP/HTTPS 路由，优化外部访问。
4. CNI：Container Network Interface（如 Flannel、Calico、Cilium）实现网络连接。

✅ 核心理念：

• Pod 间通信默认"平等、直接"

• 每个 Pod 都有一个独立的 IP（类似房子门牌号）。

• Pod 和 Pod 之间 不用 NAT（就像打电话，不需要中间转接台）。

• 所有 Pod 能直接通信，不管在哪个 Node 上。

• Service 提供一个"固定的门牌号"（ClusterIP），避免 Pod IP 变化导致找不到服务。

✅ 类比

Pod 就像宿舍房间 → 每个房间都有房号（IP）。

Service 就像宿舍门口的大牌子（ClusterIP），别人找你不用记住房号，只要看牌子。

二、CNI 插件与优化

CNI = Container Network Interface，负责 Pod 网络分配 + 路由管理。

1. 常见 CNI 对比：

• Flannel：轻量，适合中小规模集群，但功能简单。

• Calico：支持 BGP、网络策略，适合大规模场景。

• Cilium：基于 eBPF，性能极高，支持细粒度安全策略。

• Weave：自动发现，部署简单，但在大规模下性能有限。

2. 优化方向：

• 跨节点延迟优化：启用 IP-in-IP 或 VXLAN 隧道，减少三层网络复杂性。

• eBPF 加速（Cilium/Calico eBPF 模式）：取代 iptables，提高大规模集群下的转发性能。

• BGP 模式（Calico）：与物理网络路由打通，减少 NAT。

• 多网络支持（Multus CNI）：Pod 可同时使用多网卡，适合高带宽/隔离需求。

✅ CNI 是给 Pod 铺网线的人

• 常见 CNI：Flannel（简单）、Calico（高性能、支持网络策略）、Cilium（eBPF，超高性能）。

• 选择合适 CNI：小规模 → Flannel，安全隔离强 → Calico，追求极致性能 → Cilium。

• 开启 IPIP / VXLAN / BGP 等模式，根据网络规模灵活选。

• eBPF 技术（Cilium）：更快、更节能，适合大规模集群。

✅ 类比

CNI 就像校园里的网络施工队，不同的队伍（Flannel、Calico、Cilium）有不同的施工方式，效果也不同。

三、K8s 负载均衡

K8s 提供多层级负载均衡：

1. ClusterIP（默认）

   集群内部虚拟 IP，kube-proxy 实现。

2. NodePort

   节点对外暴露固定端口，外部通过 nodeIP:nodePort 访问。

3. LoadBalancer（云原生常用）

   调用云厂商的 LB（AWS ELB、阿里云 SLB 等）。

   裸机集群可用 MetalLB。

4. Ingress + Controller

   提供 HTTP/HTTPS 七层负载均衡。

   常见控制器：Nginx Ingress Controller、HAProxy、Traefik、Istio Gateway。

✅ 核心：让流量均匀分布到多个 Pod

• ClusterIP：只在集群内部用，类似"内部座机号码"。

• NodePort：把服务暴露到集群外，每个节点一个端口（不灵活，像宿舍外每个门口都贴个电话机）。

• LoadBalancer：云上常用，自动分配公网 IP（像学校总机号码，自动转接给不同宿舍）。

• Ingress：统一流量入口（像学校大门门卫，帮你指路）。

✅ 最佳实践

• 内部服务：ClusterIP

• 小规模测试：NodePort

• 生产/云环境：LoadBalancer + Ingress

四、Ingress 最佳实践

1. 设计原则：

• 按域名 / 路径路由：一个 Ingress 控制器可以管理多个服务，减少 LB 依赖。

• 证书自动化：结合 cert-manager 自动签发/续期 TLS 证书（Let's Encrypt）。

• 灰度 & 金丝雀发布：使用 Ingress annotation 配置流量分流（如 Nginx 支持基于 Header、权重转发）。

• 高可用：Ingress Controller 部署 多副本 + HPA，前置 LB（MetalLB/云厂商LB）转发流量。

• 安全：

  • 配置 HTTPS 强制跳转，关闭弱加密套件。

  • 配合 WAF/限流插件 提升防护能力。

2. 实践方案：

• 中小型集群：Nginx Ingress + cert-manager，简单易用。

• 大规模流量：HAProxy / Envoy / Traefik，性能更佳。

• 微服务治理：Ingress + Istio Gateway，实现全链路流量控制。

✅ 核心

👉 Ingress = 集群的"网关"

• 能按 域名、路径 分流（/api → A 服务，/img → B 服务）。

• 常用 Ingress Controller：NGINX、Traefik、HAProxy、Istio Gateway。

• 最佳实践：

  • 使用 证书管理（Let's Encrypt + cert-manager） → 自动 HTTPS。

  • 开启 限流、防火墙、安全策略。

  • 配合 HPA（自动扩容） → 避免高并发时挂掉。

  • 大型应用推荐用 Ingress + Service Mesh（Istio、Linkerd）。

✅ 类比

Ingress 就像校门的保安大叔，学生（请求）进门时，他会告诉他们该去哪栋楼（Pod）。

配置示例Nginx Ingress：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

五、进阶优化建议

• 替换 kube-proxy iptables → eBPF 模式（Cilium/Calico）

• Service Mesh（Istio/Linkerd）：增强流量管理与可观测性

• MetalLB + BGP：裸机环境实现负载均衡

• 网络策略：用 NetworkPolicy 隔离流量，提升安全性

  • 默认 Pod 都能互相通信 → 但生产环境必须加限制！

  • NetworkPolicy = 校园的"宿舍门禁卡系统"。

• 可以规定：

  • 哪些 Pod 能访问哪些 Pod（白名单机制）。

  • 限制流量方向（入口/出口）。

  • 避免被恶意 Pod 横向渗透。

✅ 最佳实践

• 采用 最小权限（只开放必要的通信）。

• 配合 CNI（如 Calico） 执行网络策略。

• 云环境结合 安全组 双保险。

六、 总结一句话

• K8s 网络就像一个校园：

• Pod 是学生宿舍 → 每个都有门牌号。

• Service 是宿舍门牌 → 永远固定。

• CNI 是校园网施工队 → 决定网速和安全。

• Ingress 是大门门卫 → 负责指路和分流。

• NetworkPolicy 是门禁系统 → 保证安全。

---

"人的一生会经历很多痛苦，但回头想想，都是传奇"。

---