k8s 之流量链路（Ingress、Service、endpoint、kube-proxy、pod）

一、流量走向链路

ingress是控制器实现七层（HTTP）路由，将外部请求导向 Service，可选，且有多种ingress

Service 是核心抽象层，提供稳定ip，负载均衡到 Pod，必须存在

kube-proxy是svc的底层实现，kube-proxy实现 Service 的流量转发（通过 iptables/IPVS）

cilium是网络组件，功能强大，可替代 kube-proxy + 网络策略，网路组件必须存在，cilium可选

1、kube-proxy 版本（iptables/ipvs 实现）

外部请求 http://myapp.example.com
         │
         ▼
[1] 进入 Node（80/443 → HostNetwork: Traefik Pod 或 NodePort Service）
         │
         ▼
[2] Traefik Pod 收到流量，根据 Ingress 规则 → ClusterIP: myapp-svc:80
         │
         ▼
[3] kube-proxy 在节点安装的 iptables/ipvs 规则拦截访问 Service: myapp-svc
         │
         ▼
[4] kube-proxy 查询 Endpoints 对象，找到 Pod 列表（比如 10.0.0.11:8080、10.0.0.12:8080）
         │
         ▼
[5] kube-proxy 选择一个 Pod（如 10.0.0.11:8080），DNAT 修改报文目的 IP/Port
         │
         ▼
[6] Linux 内核转发数据包 → 目标 Pod IP（跨节点时需要 CNI 网络插件，比如 Flannel、Calico）
         │
         ▼
[7] Pod 收到流量 → 应用容器处理并返回响应

2、Cilium eBPF 版本（替代 kube-proxy）

外部请求 http://myapp.example.com
         │
         ▼
[1] 进入 Node（80/443 → HostNetwork: Traefik Pod 或 NodePort Service）
         │
         ▼
[2] Traefik Pod 收到流量，根据 Ingress 规则 → ClusterIP: myapp-svc:80
         │
         ▼
[3] Cilium 的 eBPF 程序挂载在内核网络钩子（tc/xdp/bpf_lxc），拦截对 myapp-svc 的访问
         │
         ▼
[4] Cilium 查询内核中的 eBPF map（存有 Service → Endpoint 映射）
         │
         ▼
[5] 从 Endpoints 列表中直接选择一个 Pod（如 10.0.0.11:8080）
         │
         ▼
[6] 内核 eBPF 程序直接修改数据包目的地址，零拷贝转发到 Pod（可以同节点直达，也可以用 Cilium overlay / Cilium native routing 跨节点）
         │
         ▼
[7] Pod 收到流量 → 应用容器处理并返回响应

3、补充与建议

小结补充：

1 Service：“谁提供服务”（逻辑入口）

2 kube-proxy / Cilium：“怎么把流量转给真正的 Pod”（底层转发）

3 Traefik Ingress：“根据域名和路径，决定把请求交给哪个 Service”（七层路由）

4 Cilium：可以同时干 kube-proxy + Ingress + NetworkPolicy 的活（一体化网络方案）

5 谁更新 Endpoint？

　　Endpoint Controller（端点控制器）

　　它是 Kubernetes 控制管理器（kube-controller-manager）中的一个组件，负责：

  • 监听 Service 和 Pod 的变化；
  • 根据 Service 的 selector 匹配符合条件的 Pod；
  • 自动创建或更新同名的 Endpoints 对象，填入这些 Pod 的 IP 和端口；
  • 当 Pod 崩溃、重启或被替换时，自动更新 Endpoints 列表。

6 什么是ep？

　　Endpoint 是 Kubernetes 的核心资源对象之一，由控制平面中的 Endpoint Controller 持续维护。它根据 Service 的 selector 规则，
　　自动收集并更新后端处于就绪状态的 Pod 的 IP 地址和端口号。底层网络组件（如 kube-proxy 或 Cilium）通过查询 Endpoint 对象，实现服务流量的负载均衡。 

image

建议：

如果你追求高性能、可观测性，推荐使用 Cilium，并启用 kube-proxy-replacement。

如果你已经有 Traefik，可以继续使用，或迁移到 Cilium Ingress（基于 Gateway API）。

不要同时运行 kube-proxy 和完整功能的 Cilium，会造成冲突。

二、pod服务暴露

Service 是 四层负载均衡的基础

Ingress 是 七层路由的入口

kube-proxy 或 Cilium 是实际转发引擎

Cilium + eBPF 是未来高性能方向

四层 LB
Service+kube-proxy
iptables / IPVS
✅ 默认
四层 LB
Service+Cilium
eBPF
❌ 需安装
七层 LB
Ingress+ Controller
Nginx/Traefik/Cilium
❌ 需安装
下一代
Gateway API
标准化路由
✅ 逐步成为主流

1、Kubernetes 服务暴露的设计目标

解耦服务发现与网络实现

　　应用无需关心后端 Pod 的 IP 变化，通过 Service 获得稳定入口。

支持多种访问场景

　　集群内部访问（Pod → Pod）

　　外部访问（用户 → 服务）

　　负载均衡与高可用

　　基于域名和路径的路由（七层）

可插拔架构

网络组件（如 CNI、Ingress Controller）可替换，适应不同环境（云、裸机、边缘）。

前三种都是 services 的四层实现，ip+port 访问

Ingress 是七层http、https 域名访问方式

1. Services ClusterIP（默认）

  • 类型：ClusterIP
  • 用途：仅在集群内部访问
  • 特点：
    • 分配一个集群内虚拟 IP
    • 只能从其他 Pod 或节点内部访问

2. Services NodePort

  • 类型：NodePort
  • 用途：通过节点 IP + 固定端口暴露服务
  • 特点：
    • 每个节点都开放一个端口（如 30080）
    • 外部用户访问 http://<node-ip>:30080
    • 依赖 kube-proxy 或 Cilium 做转发

3. Services LoadBalancer

  • 类型：LoadBalancer
  • 用途：在云平台上自动创建外部负载均衡器（如 AWS ELB、GCP CLB）
  • 特点：
    • 云厂商提供公网 IP
    • 自动将流量转发到 NodePort 或 Pod
    • 成本较高，每个服务一个 LB

4. Ingress（推荐用于 HTTP/HTTPS）

  • 类型：Ingress 资源 + Ingress Controller
  • 用途：统一入口，基于域名和路径路由
  • 特点：
    • 单个公网 IP 支持多个服务（多租户）
    • 支持 TLS/SSL、重写、限流等高级功能
    • 需要部署 Ingress Controller（如 Nginx、Traefik、Cilium）

5、现代趋势与增强方案

1. 使用 Gateway API（替代 Ingress）

  • 更强大、结构化、支持 TCP/UDP、gRPC 等
  • 由 SIG-Network 维护，未来将成为标准
  • Cilium、Istio、Envoy Gateway 已支持

2. Cilium 替代 kube-proxy

  • 使用 eBPF 实现更高效的 Service 转发
  • 支持原生 SNI 路由、无 Sidecar Ingress
  • 可作为一体化网络方案（CNI + LB + Ingress）

3. Service Mesh 集成

  • 如 Istio、Linkerd，提供更细粒度的流量控制（金丝雀、熔断）
  • 通常与 Ingress 协同工作

三、负载均衡

1、四层负载均衡（Layer 4）：基于 IP 和端口

1、负载均衡实现方式（谁来做转发？）

✅ 方式一：kube-proxy（传统方式）

kube-proxy 运行在每个节点上，负责实现 Service 的负载均衡。

iptables（默认）
使用 iptables 规则随机转发
简单但规则多时性能下降
IPVS
使用 Linux IP Virtual Server，类似 LVS
高性能，支持轮询、最少连接等算法
  • 监听 Service 和 Endpoints 变化
  • 生成 iptables/IPVS 规则
  • 将访问 Service IP:Port 的流量负载均衡到后端 Pod IP

查看 IPVS 负载均衡表

ipvsadm -ln
# 输出：
TCP 10.96.0.10:53 rr
-> 10.1.0.10:53 Masq 1 0 0
-> 10.1.0.11:53 Masq 1 0 0

✅ 方式二：Cilium eBPF （现代高性能方案）

Cilium 使用 eBPF 技术，完全替代 kube-proxy，实现更高效、更灵活的负载均衡。

特点：
  • 不依赖 iptables 或 IPVS
  • 使用 eBPF 程序直接在内核层面转发流量
  • 支持：
    • 原生 ClusterIP、NodePort、LoadBalancer
    • 直接服务器返回（DSR）
    • 更低延迟、更高吞吐
  • 可通过 cilium service list 查看服务状态

✅  负载均衡算法

kube-proxy (iptables)
随机（pseudo-random）
kube-proxy (IPVS)
RR、LC、DH、SH 等 8 种
Cilium (eBPF)
一致性哈希、轮询等

2、七层负载均衡（Layer 7）：基于 HTTP 内容

1、Ingress 资源 + Ingress Controller

用于 Web 服务，根据 域名、路径、Header 等进行路由。 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: app1.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: app1-svc
            port: 
              number: 80
  - host: app2.example.com
    http:
      paths:
      - path: /
        backend:
          service:
            name: app2-svc
            port: 
              number: 80

2、常见ingress 方案

Nginx Ingress
最流行，基于 Nginx，功能丰富
Traefik
自动发现，支持 Let's Encrypt
Cilium Ingress
基于 eBPF，无需额外代理，高性能
Istio/Gateway API
服务网格集成，精细控制

 

 

Auto Copied
posted @ 2020-04-13 15:44  凡人半睁眼  阅读(5167)  评论(0)    收藏  举报