容器编排中服务发现的核心是解决Pod IP不固定问题，Kubernetes通过Service提供稳定ClusterIP、Endpoints动态映射健康Pod、CoreDNS支持服务名解析、kube-proxy实现流量分发，全程自动完成注册、更新与查询。
容器编排中服务发现的核心，是解决 Pod IP 不固定带来的通信难题。Kubernetes 不依赖静态配置或人工维护地址列表，而是通过声明式资源和服务控制器协同，自动完成注册、更新与查询全过程。
Service 提供稳定入口
Service 是一个抽象层，为一组动态变化的 Pod 分配固定的 ClusterIP 和端口。只要 Pod 满足 Service 的标签选择器（如 app: backend），就会被自动纳入服务范围。客户端只需访问这个不变的 VIP，无需关心后端 Pod 的实际 IP 或数量变化。
- ClusterIP 默认在集群内部可达，是最常用的服务类型
- Service 的端口（port）对外暴露，targetPort 对应容器实际监听端口
- 当新 Pod 启动并打上匹配标签，几秒内就会被自动加入流量转发列表
Endpoints 动态映射真实实例
Endpoints 对象由 Endpoint Controller 自动维护，它实时反映当前健康且匹配标签的 Pod 地址列表。每次 Pod 创建、销毁或状态变更，Controller 都会扫描 API Server，筛选出符合条件的 Pod，并把它们的 IP:Port 写入 Endpoints。
- 可通过 kubectl get endpoints <service-name> 查看当前后端地址
- 如果某 Pod 崩溃或未就绪，它会从 Endpoints 中立即移除，不再接收流量
- 该机制天然支持滚动更新和扩缩容，无需额外干预
DNS 支持服务名解析
Kubernetes 内置 CoreDNS（或 kube-dns），为每个 Service 创建 DNS 记录。Pod 可直接用 <service-name>.<namespace>.svc.cluster.local 进行访问，例如 backend.default.svc.cluster.local。
- DNS 查询返回的是 Service 的 ClusterIP，不是 Pod IP，进一步屏蔽底层变动
- 同一命名空间下可简写为 backend，跨空间需补全域名
- CoreDNS 会缓存记录，但 TTL 较短（通常 30 秒），保证变更及时生效
流量分发由 kube-proxy 实现
kube-proxy 运行在每个节点上，负责将发往 ClusterIP 的请求，按策略转发到真实的 Pod。它有三种工作模式：
- iptables 模式：通过规则链实现 DNAT，成熟稳定，适合中小规模集群
- IPVS 模式：基于内核 IP Virtual Server，性能更高，支持更多负载均衡算法
- userspace 模式（已弃用）：早期实现，延迟高，不推荐使用
无论哪种模式，都确保请求被均匀、可靠地分发到当前健康的后端 Pod 上。
