Cilium Endpoint 和 Kubernetes 的 Endpoint

最新推荐文章于 2025-07-30 18:01:42 发布

喝醉酒的小白

最新推荐文章于 2025-07-30 18:01:42 发布

阅读量688

点赞数 8

CC 4.0 BY-SA版权

分类专栏： K8s 网络文章标签： kubernetes 容器

本文链接：https://blog.youkuaiyun.com/hezuijiudexiaobai/article/details/149770984

K8s 同时被 2 个专栏收录

447 篇文章

订阅专栏

网络

54 篇文章

订阅专栏

目录标题

实现透明 L3/L4/L7 网络策略为什么没有其他几层呢

Cilium Endpoint 和 Kubernetes 的 Endpoint 虽然名称相似，但 本质、作用和关联性都不同，理解它们的差异和联系对于掌握 Kubernetes 网络与 Cilium 网络插件的原理非常关键。

🧩 一、Cilium Endpoint 是什么？

🔹定义：

Cilium Endpoint（简称 CEP） 是 Cilium 网络插件（基于 eBPF）为 Kubernetes 中的每个 Pod 创建的一个独立对象，表示该 Pod 的网络身份和策略状态。

🔹作用：

记录该 Pod 的 IP、MAC、所属 namespace、所属 Identity（安全标识符）、所应用的网络策略（如 CiliumPolicy）等。
是实现 透明 L3/L4/L7 网络策略控制、流量可视化、安全审计 的基础。
每个 CEP 对应一个 Pod 的网络接口，配合 eBPF 程序注入 datapath。

🔹示例：

kubectl get ciliumeps -n default

输出类似：

NAME              ENDPOINT ID   IDENTITY ID   STATE     IPV4           POD NAME
nginx-7c57c65d5d   12345         10078         ready     10.0.0.23      nginx

🧩 二、Kubernetes Endpoint 是什么？

🔹定义：

Kubernetes 的 Endpoint（或 EndpointSlice） 是 kube-apiserver 中的资源对象，用于记录某个 Service 关联的 Pod IP 地址列表（即后端实例）。

🔹作用：

支撑 kube-proxy 或 Cilium 进行 Service 负载均衡（ClusterIP / NodePort / LoadBalancer）。
映射 Service -> Pod 的真实网络地址，供客户端访问。

🔹示例：

kubectl get endpoints nginx

输出类似：

Name: nginx
Subsets:
  Addresses: 10.0.0.23, 10.0.0.24
  Ports: 80/TCP

🔗 三、两者的区别与联系

对比项	Cilium Endpoint（CEP）	Kubernetes Endpoint
所属组件	Cilium CNI 网络插件	Kubernetes 核心 API
对象粒度	Pod 网络身份（每个 Pod 一个 CEP）	Service 后端 Pod 列表（多个 Pod 可共享）
数据内容	IP、MAC、身份、策略状态等	IP:Port 列表，供 Service 使用
作用范围	eBPF 数据面、策略决策、身份审计	Service 负载均衡、DNS 解析
创建机制	Cilium 自动为每个 Pod 创建 CEP 对象	kube-controller-manager 生成或同步
是否 Service 相关	无直接关系，作用于 Pod 网络层	与 Service 直接关联

🔗 关联：

Cilium Endpoint 记录 Pod 的网络信息，而 Kubernetes Endpoint 可能引用这些 Pod 的 IP 地址。
在使用 Cilium 时，Service 的负载均衡也可能绕过传统 kube-proxy，直接由 Cilium 的 eBPF 实现 L4 代理逻辑，这时会从 EndpointSlice 读取后端 IP，匹配 Cilium Endpoint 来做智能路由与策略决策。

🎯 四、实际应用场景理解

你想控制 nginx Pod 的入站访问？
- ➤ 配置 CiliumNetworkPolicy，作用对象是 Cilium Endpoint（如 nginx-abc123）。
你想让前端访问 nginx Service？
- ➤ Kubernetes Endpoint 提供了 nginx Pod 的 IP 地址，Cilium 使用它们实现负载均衡。
你需要进行网络审计与监控？
- ➤ Cilium Endpoint 提供了详细的指标和连接跟踪能力（结合 Hubble）。

📌 总结一句话

Cilium Endpoint 是 Pod 的网络身份与策略状态载体，K8s Endpoint 是 Service 的后端 Pod 地址列表，两者共同构成了 Cilium 网络模型中的控制面与数据面的核心。

如果你需要进一步理解 Cilium 如何将 EndpointSlice 与 CEP 结合用于负载均衡与策略应用，我可以帮你画一张流量流程图，是否需要？

实现透明 L3/L4/L7 网络策略为什么没有其他几层呢

这是一个非常好的问题 —— 为什么 Cilium 网络策略支持 L3/L4/L7（网络层、传输层、应用层），但似乎没有提到其他 OSI 模型中的层（如 L2 数据链路层，L5-会话层，L6-表示层）？

🔍 一、Cilium 为什么强调 L3/L4/L7 策略？

因为这三层是最直接影响“网络流量行为和访问控制”的关键层级：

层级	名称	Cilium 中的应用场景
L3	网络层（IP）	控制谁（哪个 IP/Pod）能访问我
L4	传输层（TCP/UDP）	控制哪个端口/协议可以访问我
L7	应用层（HTTP等）	控制 HTTP 方法、路径、主机等

示例：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
spec:
  endpointSelector:
    matchLabels:
      app: nginx
  ingress:
  - toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/status"

这个策略就跨越了 L3（选择 Pod）、L4（端口 80）、L7（HTTP GET + 路径）。

🤔 二、那其他层（L2、L5、L6）为什么不常用于策略控制？

层级	名称	在网络策略中的作用（或为什么不被常用）
L2	数据链路层（MAC）	Cilium 是 IP 层网络插件，Pod 间通信靠 IP，不依赖 MAC；L2 一般用于裸机/局域网，不利于跨主机策略控制。
L5	会话层（状态管理）	OSI 模型理论层，实际应用很少独立控制；TCP 本身已具备会话管理。
L6	表示层（加密/编码）	这是应用协议层内部的事情（如 TLS、JSON），策略控制无法有效解析或干预。
L1	物理层	网络插件无法感知物理层（如光纤、电信号），与 Pod 无关。