Kubernetes 中的 Service 通过标签选择器绑定 Pod 集合，借助 kube-dns 和 kube-proxy 实现服务发现，并利用 iptables 或 IPVS 规则完成四层负载均衡，整个过程无需手动配置，完全由控制平面自动管理。
Kubernetes Service 服务发现与负载均衡怎么实现
关键组件：kube-dns 与 kube-proxy
Service 实现服务发现的核心是 DNS 和代理，当你创建一个 Service 时，kube-dns（或 CoreDNS）会为其分配一个内部域名，格式为 <service>.<namespace>.svc.cluster.local，任何 Pod 只要依赖该 DNS 即可解析到 Service 的 ClusterIP，无需关心后端 Pod 的 IP 变化，kube-proxy 则负责监听 API Server 上 Service 和 Endpoint 的变化，实时更新节点上的流量转发规则，确保请求被分发到实际 Pod，这套机制让 Pod 间的调用变得像调用本地服务一样简单，也是 Kubernetes 集群内部服务发现场景中最常用的方式。
两种代理模式：iptables 与 IPVS 对比
kube-proxy 支持两种主要模式，它们在性能与策略上存在差异，iptables 模式基于 Linux 内核的 Netfilter 子系统，通过随机选择实现负载均衡，规则简单但在大规模集群下更新开销较大，IPVS 模式则工作在内核态，支持轮询、最少连接、加权等多种调度算法，吞吐量更高，适合节点数超过 100 的生产环境，业内专家指出，IPVS 已成为多数企业首选，尤其在需要精细化流量治理的场景下优势明显,下表列出关键区别：
| 对比维度 | iptables 模式 | IPVS 模式 |
|---|---|---|
| 算法支持 | 仅随机 | 轮询、最少连接、加权等 |
| 规则更新延迟 | 全量刷新，大集群慢 | 增量更新，效率高 |
| 性能瓶颈 | 随规则数线性下降 | 线性扩展，万级规则稳定 |
| 适用规模 | 小型集群或测试环境 | 中大型生产集群 |
Kubernetes 多集群服务发现方案对比
ClusterIP 与 NodePort 的适用场景
ClusterIP 是默认类型，Service 只在集群内可达，适合后端服务间通信，NodePort 则将 Service 暴露到每个节点的固定端口，让集群外部能够通过 <节点IP>:<端口> 访问，两者在服务发现层面的侧重点不同：ClusterIP 解决的是“Pod 如何找到对方”，NodePort 解决的是“外部如何进入集群”，当需要跨集群互通时，NodePort 可以配合外部负载均衡器使用，但端口管理成本较高，且节点 IP 变化后需要重新绑定，稳定性不如 LoadBalancer 类型。
Ingress 与 LoadBalancer 的差异
LoadBalancer 类型会调用云服务商的 API 创建外部负载均衡器，分配一个公网 IP，适合直接暴露 HTTP/HTTPS 服务，Ingress 则是一种更灵活的七层入口，通过一个公网 IP 和规则匹配，将流量路由到不同 Service，从服务发现视角看，LoadBalancer 提供的是“一个服务一个 IP”的强绑定，Ingress 提供的是“域名+路径”的虚拟分发，不少团队在 Kubernetes 多集群服务发现方案对比中，会选择 Ingress 作为统一网关，再结合 Service Mesh 实现跨集群的服务发现，因为这样能减少公网 IP 数量，并统一 TLS 终止策略。
Kubernetes 集群内部服务发现场景
通过 DNS 名称访问服务
最常见的方式是利用 DNS 自动生成的域名，当你部署一个名为
nginx-svc 的 Service，同一命名空间下的 Pod 只需用 nginx-svc 即可访问，跨命名空间则使用 nginx-svc.default.svc.cluster.local，这种命名方式天然支持动态扩容：后端 Pod 数量变化时，DNS 记录的 A 记录会指向 ClusterIP，而 kube-proxy 负责将流量转发到实时 Pod IP，整个过程无需修改代码，是 Kubernetes 集群内部服务发现场景中最推荐的做法。
环境变量方式的局限
Kubernetes 在启动 Pod 时，会注入当前命名空间下所有 Service 的环境变量，NGINX_SVC_SERVICE_HOST 和 NGINX_SVC_SERVICE_PORT，但这种方式存在两个问题：一是环境变量只在 Pod 启动时生成，后续新增的 Service 无法被已运行的 Pod 感知；二是变量名受 Service 名称大小写影响，容易出错，行业共识认为，环境变量应仅作为兼容旧应用的过渡方案，新项目应优先使用 DNS 方式。
外部访问 Service 的常用配置路径
NodePort 配置步骤
- 在 Service YAML 中设置
type: NodePort，并指定nodePort端口（可选，范围 30000-32767）。 - 获取任意节点 IP 和该端口,即可从集群外访问。
- 若需高可用,可在节点前加一层外部负载均衡器进行健康检查。
实际生产中，NodePort 常用于暴露非 HTTP 服务（如数据库、消息队列），或作为临时调试接口，长期暴露建议配合 LoadBalancer 或 Ingress，避免节点 IP 变化带来的维护成本。
Ingress 配置示例
Ingress 需要提前部署 Ingress Controller（如 Nginx Ingress 或 Traefik）,以下是一个典型配置流程：
apiVersion:networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80
将域名解析到 Ingress Controller 的 Service 外部 IP，即可通过 app.example.com/api 访问 api-service，Ingress 还支持 TLS 证书挂载、路径重写、限流等高级功能，是暴露 HTTP 服务的主流方案。
Kubernetes 服务发现与负载均衡常见问题解答
Q：Service 的负载均衡策略是否可以自定义？
A：默认情况下，iptables 模式仅支持随机转发，IPVS 模式支持轮询、最少连接和加权调度，若需要更精细的七层负载均衡（如基于 Cookie 的会话保持），应使用 Ingress 或 Service Mesh（如 Istio）。
Q：为什么 Service 的 ClusterIP 无法 ping 通？
A：ClusterIP 是一个虚拟 IP，由 iptables/IPVS 规则模拟，不支持 ICMP 协议，测试连通性应使用 DNS 解析后通过 curl 或 wget 访问具体端口，而非 ping。
Q：跨命名空间如何实现服务发现？
A：使用完整域名 <service>.<namespace>.svc.cluster.local，确保 kube-dns 配置正确，若需要跨集群，可借助 Kubernetes 多集群服务发现方案，如 federated service 或 Submariner。
Kubernetes 的 Service 机制将服务发现与负载均衡内化为平台能力，从单集群 DNS 解析到多集群 Ingress 统一入口，每一步都有清晰的配置路径，理解这些底层逻辑，能让你在排查问题时快速定位瓶颈,也能帮助你根据业务规模选择最合适的方案。