一、四种 Service 类型的核心对比
| 特性 | ClusterIP（默认） | NodePort | Headless（无头服务） | LoadBalancer |
|---|---|---|---|---|
| 访问范围 | 仅集群内部（Pod 之间通信） | 集群内外均可（外部通过 节点IP:端口） |
集群内部（直接访问 Pod） | 集群内外均可（依赖云厂商负载均衡器） |
| 核心功能 | 提供集群内唯一虚拟 IP，实现 Pod 负载均衡 | 在 ClusterIP 基础上，开放节点端口供外部访问 | 无虚拟 IP，通过 DNS 直接暴露 Pod IP 列表 | 调用云厂商负载均衡器，提供外部固定 IP |
| 负载均衡 | 由 kube-proxy 实现（四层负载均衡） | 同 ClusterIP，额外通过节点端口转发 | 不提供负载均衡，需客户端自行实现 | 云厂商负载均衡器（四层）+ kube-proxy |
| 典型场景 | 集群内部服务通信（如前端调用后端 API） | 开发 / 测试环境快速暴露服务 | 有状态应用（如数据库集群、ZooKeeper） | 云环境生产服务对外暴露（如网站、API） |
| 依赖条件 | 无（K8s 原生支持） | 无（需手动管理端口范围 30000-32767） | 无（需配置 clusterIP: None） |
依赖云平台（如 AWS、GCP、阿里云） |
二、与 Ingress 的协作方式
Ingress 本质是HTTP/HTTPS 流量的入口控制器，通过域名、路径等规则转发请求，依赖后端 Service 作为流量终点。不同 Service 与 Ingress 的协作逻辑如下：
1. ClusterIP + Ingress
- 协作逻辑：Ingress 最常用的搭配。ClusterIP 提供集群内稳定访问点，Ingress 将外部 HTTP/HTTPS 请求转发到 ClusterIP Service，再由 Service 负载均衡到 Pod。
- 优势 ：ClusterIP 仅集群内可见，安全性高；Ingress 负责外部流量路由，实现域名 / 路径级别的精细控制（如
api.example.com转发到 API 服务，web.example.com转发到前端服务）。
2. NodePort + Ingress
- 协作逻辑 ：NodePort 已能通过
节点IP:端口暴露服务，但缺乏 HTTP 层路由能力。Ingress 可将外部请求先转发到 NodePort Service，再由其转发到 Pod。 - 适用场景：非云环境（如物理机集群）中，用 NodePort 作为 Ingress 的后端，结合 Ingress 实现域名 / 路径管理（避免直接暴露 NodePort 端口）。
3. Headless + Ingress
- 协作逻辑：Ingress 通常不直接与 Headless Service 协作，因为 Headless 无固定 IP，且不提供负载均衡。若需协作，需通过 Ingress 规则直接指向 Headless Service 关联的 Pod（需额外配置 DNS 解析）。
- 局限性：不符合 Ingress 依赖 "稳定后端地址" 的设计，仅在特殊场景（如需直接访问特定 Pod）中使用，不推荐常规流量。
4. LoadBalancer + Ingress
- 协作逻辑：LoadBalancer 提供外部固定 IP，将流量导入集群；Ingress 在此基础上对 HTTP/HTTPS 流量进行二次路由（如按路径分发到不同服务）。
- 典型架构：云环境中，外部流量 → 云负载均衡器（LoadBalancer）→ Ingress 控制器 → 后端 Service（ClusterIP/NodePort）→ Pod。此时 LoadBalancer 负责四层流量导入，Ingress 负责七层路由。
总结
- ClusterIP 是 Ingress 的 "最佳拍档"，适合绝大多数内部服务通过 Ingress 对外暴露的场景。
- NodePort 和 LoadBalancer 更多作为 Ingress 的 "流量入口补充"，尤其在非云环境（NodePort）或云环境（LoadBalancer）中提供外部访问通道。
- Headless 与 Ingress 协作较少，主要用于有状态应用的内部通信，而非外部流量路由。
Ingress 与各类 Service 的结合，核心是实现 "外部流量入口（Ingress）+ 内部服务发现与负载均衡（Service）" 的分层架构，满足不同场景下的流量管理需求。