Pod和Service详解，K8s核心概念解析

本文深入浅出地解析了 Kubernetes 中最核心的两个基础概念——Pod 和 Service：Pod 并非单个容器，而是共享网络、存储与生命周期的紧密协作单元，强调“共用 localhost、共用 IP、共用卷”的设计本质，纠正常见误区如混装无关服务或滥用 hostNetwork；Service 则不是传统代理，而是动态服务发现的抽象层，通过 label selector 自动关联 Pod，为易变的 Pod 提供稳定入口和 DNS 名，并详解了 ClusterIP/NodePort/ExternalName 等类型的应用边界与陷阱；更关键的是，文章直击实践痛点——强调 Service 与 Pod 在 labels 和 targetPort 上必须严丝合缝的配置对齐，以及在外部系统集成、跨命名空间访问等场景下如何合理绕过 selector 机制，帮助开发者避开高频翻车点，真正理解 K8s “声明式抽象”背后的逻辑与分寸。

Pod 是什么：别把它当“容器”，要当成“协作单元”

Pod 不是容器，而是 Kubernetes 调度的最小单位——它是一组共享网络、存储和生命周期的容器。你写 YAML 时定义的是 Pod，Kubernetes 调度的也是 Pod，docker run 那种单容器思维在这里会出问题。

关键点在于“共享”：
- 所有容器共用一个 localhost，互相调用直接 curl http://localhost:8080 就行，不用记 IP；
- 共用同一个 IP 地址（由底层 pause 容器持有），所以外部访问 Pod 时看到的是这个 IP，不是某个业务容器的；
- 挂载同一个 volume，比如一个容器写日志，另一个容器归档，靠的就是 Pod 级别的卷声明。

常见错误：
- 把多个不相关服务（如 Nginx + MySQL）硬塞进一个 Pod——违背“紧密协作”设计初衷，扩缩容、升级、故障隔离全乱套；
- 在 Pod 内用 hostNetwork: true 绕过网络抽象，结果 Service 无法代理、DNS 解析失效、跨节点通信异常；
- 忘记设置 readinessProbe，导致流量打到还没启动完的容器上，返回 502 或空响应。

Service 是什么：它不转发流量，它“代表”一组 Pod

Service 不是一个代理进程，也不是一个负载均衡器实体——它是 Kubernetes 的**服务发现抽象层**。它的核心价值，是给动态变化的 Pod 提供一个稳定的入口（ClusterIP）和 DNS 名（my-svc.default.svc.cluster.local）。

为什么不能直接用 Pod IP？因为：
- Pod 重启后 IP 一定变；
- Deployment 扩容/缩容时，Pod 数量和 IP 列表实时变动；
- 你没法在代码里写死一堆 IP，更没法让每个客户端自己轮询健康检查。

Service 靠 selector 动态绑定 Pod：
- 只要 Pod 有匹配的 label（如 app: backend），就自动加入 Service 的端点列表；
- 删除 Pod，Endpoint Controller 自动从 Endpoints 对象里摘掉它；
- 新建 Pod，只要 label 对得上，几秒内就可被 Service 流量命中。

注意：type: ClusterIP 默认只在集群内可达；想从外面访问，得选 NodePort 或 LoadBalancer，但别一上来就开 NodePort 暴露所有服务——安全边界和端口冲突风险立刻上升。

Pod 和 Service 怎么配才不翻车：label 和 port 必须对齐

最常卡住人的不是概念，是 YAML 里两处配置没对上：
- Service 的 selector 必须精确匹配 Pod 模板里的 metadata.labels；
- Service 的 targetPort 必须等于 Pod 容器实际监听的端口（不是 containerPort 的名字，是数字或已定义的端口名）。

典型错法：
- Pod 写了 labels: {tier: frontend}，Service 的 selector 却写成 {app: frontend} → Service 一直显示 Endpoints: ；
- 容器暴露的是 8080，但 Service 写 targetPort: 80 → 请求进去就超时，查日志全是 connection refused；
- 用 kubectl get endpoints my-svc 查不到 IP，第一反应不是改 Service，而是先看 kubectl get pods -l "tier=frontend" 是否真有匹配的 Pod 在 Running 状态。

什么时候不该用 Service：静态端点或外部服务

Service 的 selector 机制很强大，但不是万能的。遇到这些情况，该绕开就绕开：
- 后端是集群外的老系统（比如公司内网 MySQL），没法打 label —— 直接创建 无 selector 的 Service，再手动创建同名的 Endpoints 对象填入真实 IP+端口；
- 多个不同命名空间的 Pod 要统一接入（比如 monitoring 命名空间的 Prometheus 抓取所有 namespace 的 metrics）—— 用 ExternalName 类型 Service，映射成 CNAME，避免跨 ns 网络策略麻烦；
- 应用本身带服务发现（如 Spring Cloud Eureka），且不想依赖 Kubernetes DNS —— 可以不用 Service，但得自己处理 Pod IP 变化和健康剔除，成本远高于用原生机制。

真正容易被忽略的一点：Service 的 sessionAffinity: ClientIP 看似简单，但在云厂商 LoadBalancer 后面，实际拿到的可能是 LB 的 IP，不是真实客户端 IP——这时候得配合 externalTrafficPolicy: Local 或 X-Forwarded-For 头做二次识别，否则会误伤负载均衡效果。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~