Pod、Service、Ingress：Kubernetes 三个容易混淆的概念

一、Pod 是应用的运行载体
Pod 是 Kubernetes 中最小的调度单元，一个 Pod 内可以运行一个或多个紧密关联的容器，它们共享网络和存储。可以把 Pod 理解为一台逻辑主机，容器是主机上的进程。

Pod 的关键特征是易逝。扩缩容、滚动升级、节点故障都会让 Pod 被销毁重建，重建后 IP 地址会变化。这意味着任何依赖固定 Pod IP 的访问方式都不可靠，需要更高层的抽象来提供稳定入口，这就是 Service 存在的意义。

二、Service 是内部稳定访问入口
Service 为一组 Pod 提供固定的虚拟 IP 和域名，通过标签选择器关联后端 Pod。访问 Service 的地址，流量会被转发到其后端任一健康 Pod。Pod 重建、扩缩容对调用方完全透明。

Service 有几种常见类型。ClusterIP 只在集群内部可达，用于服务间调用。NodePort 在每个节点上开放端口，可以从集群外访问，通常用于测试。LoadBalancer 对接云厂商的负载均衡器，为服务分配外部入口。

Service 解决的是四层流量分发，即基于 IP 和端口的转发。它不解析 HTTP 协议，无法根据域名、路径做路由，七层能力需要 Ingress 补充。

三、Ingress 是外部流量的七层入口
Ingress 是集群对外提供 HTTP 和 HTTPS 服务的统一入口规则集合。它定义域名、路径与后端 Service 的映射关系，由 Ingress Controller 负责实现。外部请求到达 Controller 后，按规则匹配并转发到对应 Service。

Ingress 带来的价值是入口收敛。没有 Ingress 时，每个对外服务都需要独立的负载均衡器，成本高且管理分散。有了 Ingress，所有域名共用一个入口，证书配置、限流、认证等能力也可以集中在 Controller 层实现。

四、一次请求的完整路径
外部用户访问一个 Kubernetes 应用，流量路径通常是：域名解析到 Ingress Controller 的入口地址，Controller 按 Ingress 规则匹配域名和路径，转发到对应 Service，Service 再把流量分发到后端健康的 Pod。

这条路径清晰地对应三个概念的分工：Ingress 管七层路由，Service 管四层负载，Pod 管业务执行。理解了这条路径，大多数访问不通的问题都能快速定位到具体层次：域名不通查 Ingress，服务名不通查 Service 和选择器，接口异常查 Pod 日志。

五、常见混淆点
把 Service 当成对外的网关，试图用它做域名路由。给不需要对外的服务配置 LoadBalancer，浪费资源且扩大暴露面。Pod 内应用监听 localhost 之外的错误地址，导致 Service 无法转发。标签选择器与 Pod 标签不匹配，Service 后端为空，排查时容易忽略。

六、总结
Pod 是会消亡的运行单元，Service 是稳定的内部入口，Ingress 是统一的七层入口。三者从下到上构成 Kubernetes 的流量分层模型。掌握这个模型的价值不在于记住定义，而在于遇到网络问题时能迅速判断故障发生在哪一层，把排查范围从整个集群缩小到具体资源。