一、为什么 Pod 不能直接当服务入口

Pod 创建出来后都会有自己的 IP，但这个 IP 并不稳定：

  • Pod 被删除后会重建
  • 重建后的 IP 很可能变化
  • 上游如果直接写死 Pod IP，连接关系就会失效

也正因为这个问题，Kubernetes 才引入了 Service。它本质上不是某个具体进程，而是一组 Pod 的稳定访问入口。

二、Service 到底是什么

可以把 Service 理解成“面向一组 Pod 的统一访问策略”。客户端不用关心后端到底是哪几个 Pod、Pod 有没有替换、IP 有没有变，只需要访问同一个 Service 名称或同一个虚拟 IP。

Service 的几个核心能力非常明确：

  • 提供稳定入口，例如 DNS 名称或 ClusterIP
  • 把流量分发给一组后端 Pod
  • 屏蔽 Pod 生命周期变化带来的地址漂移

这也是 Service 能成为集群内东西向流量基础设施的原因。

三、Endpoints 是 Service 真正指向后端的依据

Service 能找到后端 Pod，不是靠“猜”，而是靠 Endpoints。你可以把 Endpoints 理解成 Service 的后端地址清单，用来记录具体该把流量转发到哪些 IP 和端口。

一个典型的 Endpoints 资源长这样：

apiVersion: v1
kind: Endpoints
metadata:
  name: external-service
  namespace: default
subsets:
- addresses:
  - ip: 192.168.1.100
  - ip: 192.168.1.101
  ports:
  - port: 8080
    protocol: TCP
    name: http

这里有一个很重要的规则：Service 与 Endpoints 自动关联时，名称、命名空间和端口定义都要对得上。

四、Service 为什么会成为服务治理的最小基础单元

原文把服务访问大致分成了三类：

  • 用户访问业务服务
  • 服务与服务之间互调
  • 业务服务访问数据库、缓存、消息队列等基础组件

这三类流量虽然场景不同，但本质都需要一个稳定入口。而 Service 正好承担了这个角色。

从服务发布角度看，也可以把架构分成两种：

1.1 传统架构中的服务发布

传统架构里，请求一般会先进入域名和代理层，再被转发到应用服务器。服务之间的调用，可能依赖：

  • 代理层转发
  • 固定 IP 加端口
  • 注册中心返回实例列表

1.2 Kubernetes 架构中的服务发布

到了 Kubernetes 里，这层职责会被重新拆分：

  • 北向入口通常由 Ingress Controller 承担
  • 集群内稳定入口通常由 Service 承担
  • 后端实例则由 Deployment、StatefulSet 等工作负载创建出来

换句话说，在 K8s 里，“入口”和“实例”不再是一个东西。

五、Service 类型为什么要先有全局认识

原文在后面展开了几种常见 Service 类型，先建立整体印象会更容易：

  • ClusterIP：只在集群内可访问
  • NodePort：通过节点 IP 和端口从集群外访问
  • LoadBalancer：借助云厂商负载均衡对外暴露
  • ExternalName：通过 DNS CNAME 映射外部地址

它们不是互斥概念，而是针对不同暴露场景的不同入口形态。

六、先记住 Service 的底层逻辑

如果只记一句话，可以记这个：

Service 负责提供稳定入口，Endpoints 负责记录真实后端，而 Pod 本身只是可替换的服务实例。

一旦这三层关系理顺，后面再看 ClusterIP、NodePort、Headless Service、服务发现和 kube-proxy，就会顺很多。