在学习 "iptables代理模式的service" 这一部分内容时，可能会看到 “kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除” 这样一句话，那么，如何理解这句话中的 “Service对象” 和 “Endpoints对象” 呢？一起来看看。

目录

1. Service 对象：声明“我要什么服务”

2. Endpoints 对象：记录“实际哪些 Pod 符合条件”

3. Service 与 Endpoints 的关系和kube-proxy 的作用

4.总结

1. Service 对象：声明“我要什么服务”

Service 是一个逻辑概念，代表一组 Pod 的访问入口。它本身不直接连接 Pod，它定义了clusterIP、端口映射和pod选择器。ClusterIP 是 K8s 为 Service 分配的一个虚拟 IP（如 10.96.0.1），通过 port（Service 端口）和 targetPort（Pod 端口）的映射以及 Pod 选择器（如 app: nginx）来将流量转发到匹配的后端 Pod。

例如，可以创建一个 Service，声明“我要一个叫 my-nginx 的服务，它监听 80 端口，背后是带 app: nginx 标签的 Pod”。这就是 Service 对象。

2. Endpoints 对象：记录“实际哪些 Pod 符合条件”

Service 本身不直接知道哪些 Pod 的 IP 是多少。K8s 有一个控制回路（Endpoints Controller），它会根据 Service 的 Pod 选择器（如 app: nginx），去找所有匹配的 Pod，然后把这些 Pod 的 IP + 端口（即 targetPort）收集起来，生成一个同名的 Endpoints 对象。

假设有 3 个 app: nginx Pod，IP 分别是 10.244.1.2、10.244.2.3、10.244.3.4，且 Pod 端口为 8080。那么 Endpoints 对象里就会记录：[{ip: 10.244.1.2, port: 8080}, ...]。

3. Service 与 Endpoints 的关系和kube-proxy 的作用

Service 和 Endpoints 通过名称关联：在同一命名空间下，Endpoints 对象的名字必须与 Service 对象完全相同。通常情况下，只要 Service 存在，Endpoints 就会自动存在（除非 Service 定义时未指定选择器）。

kube-proxy 的核心职责是将 Service 的虚拟入口（ClusterIP 和端口）转发到后端的真实 Pod 地址。为此，它会同时监视两类对象：

（1）监视 Service 对象：从中获取 ClusterIP、端口、协议（TCP/UDP）、会话保持等信息。这些信息用于建立“虚拟入口”的转发规则。

（2）监视 Endpoints 对象：从中获取当前健康 Pod 的 IP 列表和 targetPort。这些信息用于确定实际转发的后端地址列表。

 当 Pod 发生变化时（如创建、删除或标签变更），Endpoints 会自动更新。kube-proxy 会实时响应这些变化：

Service 创建时，kube-proxy 添加相应的转发规则（例如 iptables 或 IPVS 规则）。

Service 删除时，kube-proxy 移除对应的规则。

Endpoints 中增加或减少 Pod IP 时（例如 Pod 扩容或缩容），kube-proxy 立即更新规则中的后端列表，确保流量仅转发到存活的 Pod。

4.总结

Service 定义“规则”（我要访问谁），Endpoints 定义“结果”（谁能被访问）。kube-proxy 同时监视这两个对象：根据 Service 知道规则怎么配，根据 Endpoints 知道规则指向哪个具体地址。