为什么需要 Service
在 Kubernetes 中，Pod 是会变化的。扩缩容、重建、漂移、滚动发布都会让 Pod IP 发生变化。如果客户端直接访问 Pod IP，服务调用关系会非常脆弱。Service 的作用，就是在一组 Pod 前面提供稳定入口。
Service 通过标签选择器找到后端 Pod，再通过 kube-proxy、iptables、IPVS 或 eBPF 等机制把访问请求转发过去。对应用团队来说，它是服务发现入口；对平台团队来说，它是集群网络治理的关键边界。
理解 Kubernetes Service类型，核心不是记名称，而是看三个问题：访问来源在哪里、是否需要暴露到集群外、是否依赖云厂商或外部负载均衡。
ClusterIP：默认的集群内访问方式
ClusterIP 是最常见、也是默认的 Service 类型。它会为服务分配一个集群内部虚拟 IP，只允许集群内部访问，适合微服务之间互调。
典型场景包括：
- 前端服务访问后端 API。
- 业务服务访问缓存、队列、内部管理接口。
- Ingress Controller 访问后端应用 Service。
示例配置如下：
apiVersion: v1
kind: Service
metadata:
name: order-api
spec:
type: ClusterIP
selector:
app: order-api
ports:
- port: 80
targetPort: 8080它的优势是简单、稳定、暴露面小。缺点是不能直接被集群外访问，若外部系统要调用，需要配合 Ingress、Gateway、LoadBalancer 或其他入口层。
NodePort：通过节点端口暴露服务
NodePort 会在每个节点上打开一个固定端口，外部访问任意节点的该端口，都可以转发到后端 Pod。它比 ClusterIP 多了一层节点级暴露能力。
NodePort 适合测试、临时暴露、裸金属环境入口对接等场景，但不建议把它当作大规模生产入口。原因包括：
- 暴露的是节点端口，安全边界更粗。
- 端口范围有限，管理成本较高。
- 需要额外处理外部负载均衡、健康检查和访问控制。
- 节点漂移或网络策略变化时，排查链路较长。
在生产环境里，NodePort 经常作为 LoadBalancer 或 Ingress 背后的一个中间层，而不是最终用户直接访问的入口。
LoadBalancer：对接外部负载均衡
LoadBalancer 类型通常用于云环境。创建 Service 后，云控制器会自动创建一个外部负载均衡实例，并把流量转发到集群后端。
它适合需要对外提供稳定公网或内网入口的场景，例如 API 网关、Ingress Controller、对外业务服务等。优势是接入清晰，和云平台网络能力结合较好；不足是依赖基础设施能力，也可能带来额外费用与配额限制。
如果企业处于私有云或本地数据中心环境，就需要用 MetalLB、硬件负载均衡或平台自研方案来补足这层能力。关于更完整的容器平台入口设计，可结合 Kubernetes 容器专题继续梳理。
ExternalName：把服务名映射到外部域名
ExternalName 不创建代理转发，也不选择 Pod，而是通过 DNS CNAME 把集群内服务名映射到外部域名。它适合把外部数据库、第三方接口或遗留系统以 Kubernetes Service 的形式呈现给应用。
它的边界也很明确：
- 不提供负载均衡能力。
- 不做端口转发和健康检查。
- 依赖 DNS 解析链路。
- 不适合需要强治理的核心流量入口。
因此，ExternalName 更像“命名抽象”，不是完整的访问治理方案。
四类 Service 怎么选
| Service 类型 | 访问范围 | 典型用途 | 主要注意点 |
|---|---|---|---|
| — | — | — | — |
| ClusterIP | 集群内部 | 服务间调用 | 不能直接外部访问 |
| NodePort | 节点端口 | 测试、裸金属入口 | 暴露面和端口管理 |
| LoadBalancer | 集群外部 | 生产入口、网关 | 依赖外部 LB 能力 |
| ExternalName | DNS 映射 | 外部服务命名 | 不做流量代理 |
一个简单的判断方法是：如果只是集群内服务互调，优先 ClusterIP；如果需要外部访问生产服务，优先通过 Ingress 或 LoadBalancer 统一入口；如果只是临时验证，可以用 NodePort；如果要把外部域名纳入集群服务发现，可以考虑 ExternalName。
Service 与 Ingress 的关系
很多初学者会把 Service 和 Ingress 混在一起。Service 解决的是一组 Pod 的稳定访问入口，Ingress 解决的是 HTTP/HTTPS 的七层路由入口。通常路径是：外部用户访问 Ingress，Ingress 再转发到 Service，Service 最后把流量分发到 Pod。
因此，Ingress 不是 Service 的替代品，而是更高层的入口治理组件。Service 仍然承担后端服务发现和负载分发的基础职责。
运维排查重点
当 Service 访问异常时，可以按下面顺序检查：
- Service selector 是否能匹配到 Pod。
- Endpoints 或 EndpointSlice 是否生成。
- port 与 targetPort 是否一致。
- Pod readiness 是否通过。
- kube-proxy 或网络插件转发规则是否正常。
- NetworkPolicy 是否阻断访问。
常用命令包括：
kubectl get svc,endpoints,endpointslice
kubectl describe svc <service-name>
kubectl get pod -l app=<label> -o wide如果 Endpoints 为空，问题大概率在标签、端口或 Pod 就绪状态；如果 Endpoints 正常但访问失败，再进一步看节点转发、网络策略和 CNI 插件。
总结
Kubernetes Service 类型并不复杂，但每一种都对应不同的访问边界。ClusterIP 适合集群内访问，NodePort 适合节点端口暴露，LoadBalancer 适合对接外部负载均衡，ExternalName 适合外部域名抽象。
真正的最佳实践不是“所有服务都用某一种类型”，而是把访问方式、入口治理、安全边界和运维复杂度放在一起评估。这样才能在容器平台中既保证访问稳定，又避免把服务暴露得过宽。
常见问题
ClusterIP、NodePort 和 LoadBalancer 应该怎么选？
集群内部访问优先使用 ClusterIP；需要从集群外临时访问或没有负载均衡器时可以用 NodePort；面向生产外部流量通常使用 LoadBalancer 或 Ingress。选择时要同时考虑访问来源、暴露范围、安全控制和运维成本。
Service 能解决 Pod 启停导致的 IP 变化吗？
可以。Service 通过标签选择器关联后端 Pod，并提供稳定的虚拟 IP 或 DNS 名称。调用方访问 Service，而不是直接访问 Pod IP，这样 Pod 重建、扩容或缩容时，访问入口仍保持稳定。
为什么 Service 有端点但访问仍失败？
需要检查端口映射是否正确、targetPort 是否对应容器实际监听端口、Pod readiness 是否通过、网络策略是否阻断，以及 kube-proxy 或 CNI 是否正常。Service 有 Endpoints 只说明后端被选中，不代表应用协议和网络路径一定可用。
