Kubernetes Service 与 Endpoints 关联机制笔记
对应视频：【k8s教程】薪享宏福Kubernetes v1.29 |2024最新版！B站最强！百万播放汪洋授课，轻松拿捏k8s p39 第六章.k8s Service-Endpoints
核心概念
Endpoints 是 Kubernetes 中 Service 与后端服务之间的中间关联层资源对象，Service 要建立和后端服务的实际运行关联、实现流量转发，必须依赖 Endpoints 存储后端服务的访问端点（IP+端口）。
Endpoints 的核心规则：
- 默认情况下 Endpoints 与关联的 Service 同名、同 Namespace
- 核心存储内容为后端服务的 IP 地址和端口信息
Endpoints 两种关联体系
自动关联体系（Service 配置 Selector）
适用场景
Service 资源中定义了 selector 字段，用于匹配后端 Pod 的标签
核心逻辑
- 自动创建：Service 创建成功后，控制器会自动创建同名的 Endpoints 对象，无需人工干预
- 匹配规则：仅匹配当前 Namespace 下、标签符合 selector 要求、且状态为
Ready（就绪）的 Pod - 动态同步：Endpoints 会自动维护最新的符合要求的 Pod 端点列表，当 Pod 的就绪状态、标签发生变化时，Endpoints 会自动更新
- 底层同步：各节点的 kubelet 会持续同步 Endpoints 中的端点信息到所在节点的 IPVS 规则中，最终实现 Service 的负载均衡流量转发，调度支持轮询（RR）、加权轮询等多种 IPVS 算法
流量转发流程
集群内应用 → Service ClusterIP:Port → IPVS 负载均衡 → 后端就绪 Pod
手动关联体系（Service 未配置 Selector）
适用场景
Service 资源中未定义 selector 字段，需要自定义后端服务
核心逻辑
- 不会自动创建 Endpoints：Service 创建后不会自动生成同名 Endpoints 对象
- 需人工创建：需要管理员手动创建与 Service 同名、同 Namespace 的 Endpoints 资源，自定义填写后端端点信息
- 匹配规则无限制：Endpoints 中存储的端点可以是任意 Service 可触达的地址，不局限于当前 Namespace 的 Pod，也可以是集群内其他服务、集群外服务的地址，不受 Pod 标签、就绪状态限制
灵活性体现
可以适配自定义后端、集群外服务接入、非 Pod 类型的服务（如虚拟机部署的服务）等场景，突破自动关联体系的规则限制
流量转发流程
集群内应用 → Service ClusterIP:Port → IPVS 负载均衡 → 管理员自定义的后端端点
实验验证
自动关联体系实验
- 环境清理：先清理集群内已有的 Deployment 和多余 Service，执行命令：
清理后执行kubectl delete deployment --all kubectl delete svc <多余Service名称>kubectl get svc、kubectl get endpoints确认资源已清空，仅保留 kube-system 命名空间的默认资源 - 创建应用 Deployment：编写包含就绪探测的 Deployment 资源清单（如 myapp v1.0 版本），执行
kubectl create -f <deployment.yaml>创建，初始时所有 Pod 因未通过就绪探测处于未就绪状态 - 触发 Pod 就绪：进入目标 Pod 执行命令，向
/usr/local/nginx/html/index1.html写入时间信息，使 Pod 通过就绪探测：
退出后执行kubectl exec -it <Pod名称> -- /bin/sh echo "$(date)" >> /usr/local/nginx/html/index1.htmlkubectl get pod确认 Pod 状态为Ready - 创建带 Selector 的 Service：编写匹配该 Deployment 的 Service 资源清单（配置 selector 字段），执行
kubectl create -f <svc.yaml>创建 - 验证 Endpoints 自动生成：执行
kubectl get endpoints，可以看到与 Service 同名的 Endpoints 对象已自动生成，内部已记录就绪 Pod 的 IP 和端口（如10.244.85.200:80） - 验证 Endpoints 动态更新：让第二个 Pod 也通过就绪探测，再次执行
kubectl get endpoints，可以看到端点列表自动新增了第二个 Pod 的 IP+端口，证明 Endpoints 会动态同步符合要求的就绪 Pod 信息 - 验证流量转发：访问 Service 的 ClusterIP+端口，可以正常转发到后端 Pod，返回写入的时间内容
手动关联体系实验
- 创建不带 Selector 的 Service：编写 Service 资源清单，不配置 selector 字段，配置集群端口为 6666，映射后端端口 80，Service 命名为
linux-no-selector，执行kubectl create -f <svc-no-selector.yaml>创建 - 验证无自动 Endpoints：执行
kubectl get endpoints，看不到与该 Service 同名的 Endpoints 对象；执行ipvsadm -Ln查看 IPVS 规则，可以看到该 Service 的集群 IP:6666 没有绑定任何真实服务器，访问会被拒绝 - 手动创建 Endpoints：编写与 Service 同名、同 Namespace 的 Endpoints 资源清单，自定义后端端点为
192.168.66.12:80，执行kubectl create -f <endpoints.yaml>创建 - 验证 Endpoints 生效：再次执行
ipvsadm -Ln，可以看到该 Service 的集群 IP:6666 已经绑定了192.168.66.12:80作为真实服务器 - 准备后端服务：在 192.168.66.12 节点（集群外服务器）上启动 nginx 容器，并向主页写入自定义内容：
docker run --name linux-p80 -p 80:80 -d myapp:v1.0 docker exec -it linux-p80 /bin/sh echo "薪享宏福" >> /usr/local/nginx/html/index.html - 验证访问成功：访问 Service 的 ClusterIP:6666，可以正常返回 nginx 的内容，证明手动配置的 Endpoints 生效
- 灵活性验证：该模式下可以自定义任意可触达的地址作为后端，不受 Pod 标签、就绪状态、Namespace 限制，甚至可以将集群外服务、虚拟机部署的服务接入 Service 负载均衡体系
本节小结
- Endpoints 是 Service 实现流量转发的核心关联对象，存储后端服务的 IP+端口信息，必须与关联 Service 同名、同 Namespace
- 带 Selector 的 Service 会自动创建、自动维护同名 Endpoints，仅同步当前 Namespace 下符合标签要求且就绪的 Pod，适合常规 Pod 类型后端服务
- 不带 Selector 的 Service 需要管理员手动创建同名 Endpoints，可自定义任意可触达的后端地址，灵活性更强，适合自定义后端、集群外服务等特殊场景
- 所有 Endpoints 的变更都会通过 kubelet 同步到各节点的 IPVS 规则，最终实现 Service 的负载均衡能力
AI 总结
本节详细讲解了 Kubernetes 中 Service 的底层关联对象 Endpoints 的核心作用、两种关联体系的差异及实验验证方法。明确 Endpoints 是 Service 与后端服务通信的中间层，自动关联体系依赖 Selector 自动同步就绪 Pod 的端点信息，适配常规 Pod 后端的场景；手动关联体系由管理员自定义端点，可突破标签、Namespace、就绪状态的限制，适配自定义后端、集群外服务等灵活场景，是 Kubernetes 服务发现与负载均衡机制的核心组成部分。