【AI 总结】Kubernetes 服务、负载均衡和联网

服务、负载均衡和联网 | AI 总结

Kubernetes 网络模型

  1. Pod 网络特性
    • 每个 Pod 拥有独一无二的集群范围 IP 地址，且 Pod 内所有容器共享私有网络命名空间，同一 Pod 内不同容器进程可通过 localhost 通信。
    • Pod 网络（集群网络） 保障 Pod 间通信，默认情况下所有 Pod 无论在同一节点还是不同节点，均可直接通信，无需代理或地址转换（NAT），但 Windows 系统的主机网络 Pod 不遵循此规则；同时节点上的代理（如系统守护进程、kubelet）能与该节点上所有 Pod 通信。
  2. 关键 API 及功能
    • Service API：为一个或多个后端 Pod 实现的服务提供稳定 IP 地址或主机名，即便组成服务的 Pod 动态变化也不受影响，Kubernetes 会自动管理 EndpointSlice 对象，记录当前提供 Service 的 Pod 信息，服务代理通过操作系统或云平台 API 拦截、重写数据包，结合 Service 和 EndpointSlice 对象将流量路由到后端。
    • Gateway API 与 Ingress：Gateway API（及其前身 Ingress）帮助集群外部客户端访问 Service；若使用支持的云提供商，通过 Service API 的 type: LoadBalancer 可实现更简单但配置性较低的集群 Ingress 机制。
    • NetworkPolicy：作为内置 Kubernetes API，用于控制 Pod 间及 Pod 与外部世界的流量，但需集群使用支持该功能的网络插件，否则 API 存在但无实际效果。
  3. 功能实现依赖
    • Pod 网络命名空间设置由实现容器运行时接口（CRI）的系统软件处理。
    • Pod 网络本身由 Pod 网络实现（Linux 系统多为 CNI 插件）管理。
    • Kubernetes 提供默认服务代理 kube-proxy，部分 Pod 网络实现会使用自身服务代理以更好集成。
    • Gateway API 有多种实现，部分针对特定云环境，部分适用于 “裸金属” 环境或通用场景。

1. “独一无二” 指的是 “在生命周期内” 且 “全集群可见”

这句话的核心在于描述 Kubernetes 的网络原则 (Network Model) ，即：

  • 非 NAT 网络：在集群内部，任何两个 Pod 之间都可以直接通过对方的 IP 地址通信，不需要经过 NAT（网络地址转换）。
  • 全局唯一性：在同一个时刻，集群中不会有两个 Pod 拥有相同的 IP。
  • 可见性：Pod 看到的自己的 IP，和别的 Pod 访问它时用的 IP 是一致的。

2. 与 “生命周期导致 IP 变化” 并不冲突

你提到的 “IP 会随生命周期变化” 是 Pod 的临时性 (Ephemeral) 特征，而这句话描述的是 Pod 的网络架构特征。

  • Pod 是消耗品：Pod 被销毁重新创建后（比如 Deployment 触发了滚动更新），它实际上是一个全新的实体，分配到一个新的独一无二的 IP 是完全合理的。
  • 不冲突的原因：Kubernetes 并没有承诺 “某个服务” 的 IP 不变，它承诺的是 “只要这个 Pod 还在运行，它就拥有一个在全集群范围内可直接访问的唯一 IP”。

3. 如何解决 “动态 IP” 带来的问题？

正因为 Pod 的 IP 是动态变化的，Kubernetes 才引入了 Service 资源：

  • Service IP (ClusterIP) ：是稳定的、虚拟的 VIP。
  • 服务发现：客户端访问 Service IP，由 Kubernetes (kube-proxy) 负责负载均衡到后端那组不断变化的 Pod IP 上。

4. 关于 “共享私有网络命名空间”

这句话的后半部分解释了 Pod 内部的通信逻辑：

  • 容器间的关系：Pod 里的多个容器（比如应用容器和 Sidecar 容器）就像运行在同一台 “逻辑主机” 上。
  • localhost 通信：因为共享 Namespace，它们共享同一个回环网卡（lo）。容器 A 监听 8080 端口，容器 B 直接访问 127.0.0.1:8080 就能通。这也意味着同一个 Pod 内的容器不能占用相同的端口。

总结，你可以这样理解：

“每个 Pod 都有唯一 IP” 描述的是 Pod 活着的时后的通信能力（像身份证号，每个自然人都有唯一的身份证号）。

“生命周期导致 IP 变化” 描述的是 Pod 的存在本质（像临时员工，旧人走了新人来，新人的工号 / IP 自然和旧人不同）。

Service 则是 “岗位”，无论谁在岗，外部只需联系这个固定的 “岗位电话” 即可。

简单来说，它是对 Kubernetes 如何实现服务发现和负载均衡的总结。我们可以从以下几个核心点来理解这段话：

1. 为什么需要它？（解决 Pod 的动态性）

在 Kubernetes 中，Pod 是有生命周期的（会被销毁、重建）。每当 Pod 重建时，它的 IP 地址都会发生变化。

  • Service API 的作用：它提供了一个稳定的虚拟 IP (ClusterIP) 或主机名。无论后端的 Pod 如何漂移、重启，客户端只需要访问这个固定的 Service 地址即可，不需要关心具体 Pod IP 的变化。

2. 它包含哪些关键组件？

这段话提到了两个重要的幕后组件：

  • EndpointSlice：这是 Kubernetes 用于跟踪后端 Pod 状态的对象。当 Pod 启动或停止时，Kubernetes 会自动更新 EndpointSlice，记录哪些 Pod 是健康的、可以接收流量的。
  • 服务代理 (Service Proxy/kube-proxy) ：这是运行在每个节点上的组件。它负责 “拦截和重写数据包”，将发送到 Service 稳定 IP 的流量，按照规则转发到具体的某个后端 Pod 上。

3. 它的工作流程

  1. 定义 Service：你定义一个 Service 并关联一组 Pod。
  2. 维护名单：Kubernetes 自动管理 EndpointSlice，确保名单里都是活着的 Pod。
  3. 流量路由：当流量到达时，服务代理根据 EndpointSlice 的信息，将请求路由到正确的 Pod。

总结：Service 是 Kubernetes 实现微服务通信的核心桥梁，它通过一个 “永不改变” 的入口（Service API），结合 “动态更新” 的名单（EndpointSlice）和 “流量分发” 的代理，解决了容器频繁变动导致的通信难题。

如果你正在学习 K8s 概念，这部分是理解 “集群内服务如何互相访问” 的关键。

没错，你的理解非常准确。如果用大白话来说，EndpointSlice 就是一份 “实时更新的健康 Pod 通讯录”。具体可以从这三个层面来理解：

1. 它记录了什么？（通讯录的内容）

对于每一个 Service，Kubernetes 都会生成对应的 EndpointSlice。它记录了：

  • IP 地址：Pod 当前在哪。
  • 端口：Pod 监听哪个端口。
  • 状态：这个 Pod 现在是不是 “Ready（准备好了）” 可以接客。

2. 它的作用是什么？（通讯录的用途）

当流量发给 Service 的稳定 IP 时，底层的 kube-proxy（网络代理）会去查这份 “通讯录”，看看现在有哪些 Pod 是健康的，然后把流量转过去。

3. 为什么叫 “Slice” (分片)？（它的进化）

在 K8s 早期，只有 Endpoints 对象。但当一个 Service 下面有几千个 Pod 时，只要一个 Pod 变动，整个巨大的 Endpoints 列表都要同步给所有节点，非常吃性能。

EndpointSlice 的聪明之处在于：

  • 它把这一长串名单切成了几份（Slices）。
  • 如果一个 Pod 变了，只需要更新其中一个小分片，不用刷新整张表。
  • 结论：它是为了支持大规模集群而设计的优化版 “Pod 状态记录”。

总结一下：Service 是 “店招”（招牌，永远不变），EndpointSlice 就是 “值班表”（记录谁在上班、谁的工位在哪），有了它，系统才知道要把客人（流量）带到哪个具体的工位（Pod）上去。

在 Kubernetes (K8s) 中，Ingress 和 Gateway API 都是用于 管理集群外部流量进入集群内部服务的资源对象。简单来说，它们决定了外部请求如何路由到集群内的 Service。

以下是它们的详细介绍及其关系：

1. 什么是 Ingress？

Ingress 是 K8s 中较早期的流量入口方案（目前仍被广泛使用）。它像是一个 “路由表”，定义了基于主机名（Host）或路径（Path）的 HTTP/HTTPS 路由规则。

  • 特点：
    • 简单易用：适合简单的 HTTP/HTTPS 路由需求。
    • 功能局限：原生 Ingress 仅支持 7 层（HTTP/HTTPS）负载均衡，不支持 4 层（TCP/UDP）。
    • 配置受限：许多高级功能（如重写、灰度发布、超时控制）需要通过不同 Ingress Controller（如 Nginx, Traefik）的 annotations 来实现，导致跨平台迁移困难。

2. 什么是 Gateway API？

Gateway API 是 Ingress 的后续演进方案，是一个更强大、更灵活且面向角色的 API 集合。它不仅仅是一个资源，而是由 GatewayClass、Gateway 和 HTTPRoute 等多个组件组成的系统。

  • 特点：
    • 多层支持：不仅支持 7 层（HTTP/HTTPS），还原生支持 4 层（TCP/UDP/TLS）。
    • 面向角色：将配置拆分为基础设施层（GatewayClass）、运维层（Gateway）和开发层（Route），不同角色管理不同资源，符合企业内部的权责划分。
    • 强扩展性：提供了更好的标准化方法来扩展功能，不再依赖凌乱的 annotations。

3. 它们之间的关系

你可以将 Gateway API 理解为 Ingress 的 “下一代” 或 “进阶版”。

  • 继承与演进：Ingress 的设计过于简单，难以满足复杂业务需求。Gateway API 旨在解决 Ingress 的局限性，提供更标准、更具表现力的流量控制模型。
  • 兼容性：两者目前在 K8s 中并存。虽然 Ingress 不会被立即废弃，但 K8s 社区已经将未来的重心放在了 Gateway API 上。
  • 角色演变：
    • Ingress：一个大杂烩文件，所有的规则都在一个对象里。
    • Gateway API：分而治之。比如，管理员创建一个 Gateway（决定流量怎么进，用什么证书），而开发者只需创建一个 HTTPRoute（决定流量到了之后去哪个 Service），两者解耦。

总结

  • Ingress 是传统的、简单的流量入口定义工具。
  • Gateway API 是现代的、功能丰富的入口标准，支持更多协议且更适合团队协作。
  • 关系：Gateway API 是 Ingress 的功能升级和架构重构。如果你正在构建新的系统，社区通常推荐优先考虑 Gateway API。

这三者共同构成了 Kubernetes 网络模型的核心，分别承担服务发现与负载均衡、外部流量接入以及网络安全隔离的角色。

它们之间的关系可以从以下几个维度来理解：

1. 功能分工：路由、暴露与安全

  • Service (服务发现与基础路由) ：它是 Kubernetes 网络的 基石。主要解决集群内部 “如何找到 Pod” 的问题。它为一组 Pod 提供一个稳定的虚拟 IP（ClusterIP），无论 Pod 如何销毁和重建，Service 的 IP 不变。它负责在集群内部进行简单的四层（TCP/UDP）负载均衡。
  • Gateway API / Ingress (高级暴露与七层路由) ：它们建立在 Service 之上。如果说 Service 负责把流量领进门，那么 Gateway API/Ingress 就负责流量的精细管理。它们通常处理七层（HTTP/HTTPS）流量，支持基于域名、路径的转发，以及 SSL 卸载等高级功能。
    • 关系：Gateway API 或 Ingress 的规则最终会将流量导向某个 Service。
  • NetworkPolicy (访问控制与安全) ：它是网络的防火墙。Service 和 Ingress 负责让流量 “通”，而 NetworkPolicy 负责让不该通的流量 “断”。它定义了 Pod 之间、或者 Pod 与外部之间哪些流量是被允许的。
    • 关系：即使 Service 或 Ingress 已经把流量导向了 Pod，如果 NetworkPolicy 规则不允许该来源的访问，流量依然会被拦截。

2. 协作流程 (流量视角)

当你从外部访问一个应用时，流量的流向通常如下：

  1. 外部请求到达 Gateway/Ingress 控制器。
  2. Gateway/Ingress 根据配置的规则（如域名 example.com/api），决定将流量转发给哪个 Service。
  3. Service 通过内部负载均衡机制，选择后端的一个具体 Pod。
  4. 在流量真正进入 Pod 之前，内核 / 网络插件会检查是否存在 NetworkPolicy。
    • 如果有，且该流量符合白名单，则允许进入。
    • 如果不符合或没有被允许，则丢弃。

3. 依赖关系总结

  • Gateway/Ingress 依赖 Service：没有 Service，Gateway/Ingress 找不到流量的落脚点。
  • Service 独立存在：Service 可以在没有 Gateway 或 NetworkPolicy 的情况下工作（默认全通）。
  • NetworkPolicy 作用于 Pod：虽然它配置在 Pod 上，但它会影响 Service 的可达性。如果你配置了 Service 但没配对应的 NetworkPolicy 允许规则，Service 也会处于 “断网” 状态。

简单比喻：

  • Service 就像是公司里的固定分机号，无论员工（Pod）怎么换座，打这个号就能找到这个岗。
  • Gateway/Ingress 就像是前台 / 前台调度，负责接待外宾并根据其需求（域名 / 路径）指引去哪个部门（Service）。
  • NetworkPolicy 就像是门禁卡系统，决定了谁有权进入哪个房间（Pod），哪怕前台把你带到了门口，没门禁也进不去。

核心概念与功能模块

  1. 服务（Service）：可将集群中运行的应用通过统一外界端点暴露，即便工作负载分散在多个后端也能正常使用。
  2. Ingress：借助感知协议配置的机制，解析 URI、主机名、路径等 Web 概念，让 HTTP（或 HTTPS）网络服务可被访问，支持通过 Kubernetes API 定义规则映射流量到不同后端。
  3. Ingress 控制器：要使 Ingress 在集群中生效，必须部署至少一个 Ingress 控制器，文档列出了常见可部署的 Ingress 控制器。
  4. EndpointSlice：作为 Kubernetes 扩缩 Service 以处理大量后端的机制，能让集群高效更新健康后端列表。
  5. Service 与 Pod 的 DNS：说明工作负载如何通过 DNS 发现集群内 Service 的原理。
  6. IPv4/IPv6 双协议栈：介绍 Kubernetes 配置单协议栈（IPv4 或 IPv6）及双协议栈网络的具体方法。
  7. 拓扑感知路由：提供机制使网络流量尽量保持在发起区域内，优先让集群中 Pod 间使用相同区域流量，以提升可靠性、性能，降低成本。
  8. Windows 网络：针对 Windows 系统相关的网络内容（文档中未展开详细说明，仅提及该模块）。
  9. Service ClusterIP 分配：涉及 Service 的 ClusterIP 分配相关内容（文档中未展开详细说明，仅提及该模块）。
  10. 服务内部流量策略：当集群中同一节点上的两个 Pod 通信时，可限制网络流量在该节点内，避免流量往返以提升可靠性、性能，降低成本。
K8s
#K8s #网络 #服务
【AI 总结】Kubernetes 服务、负载均衡和联网
https://blog.lllllan.cn/k8s/concepts/services-networking/
作者
lllllan
发布于
2026年1月9日
许可协议