Service: 稳定访问入口

Pod 的 IP 会变，但 Service 提供稳定的访问入口，并通过标签选择器把流量转到正确的后端。

常见类型

• ClusterIP：集群内访问
• NodePort：节点端口暴露
• LoadBalancer：云上负载均衡
• Headless：不做负载均衡

示例 Service

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

排查要点

• selector 是否匹配 Pod labels
• kubectl get endpoints api 是否为空

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

网络身份与服务发现

Kubernetes 网络强调“稳定名称”而不是“稳定 IP”。Service 提供稳定的虚拟 IP 和 DNS 名称，Endpoints 会追踪后端 Pod。Service 是在这个模型上构建网络访问与发现规则的关键环节。

Service 类型与路由选择

ClusterIP 适合内部访问，NodePort 与 LoadBalancer 用于对外暴露，Ingress 则负责 HTTP 路由与域名管理。选择何种类型取决于环境与流量路径，建议明确哪些入口是用户访问、哪些是内部调用、哪些仅用于调试。

Headless 与直连模式

Headless Service 不创建虚拟 IP，而是直接发布 Pod IP，适合需要固定地址或集群内 peer 发现的系统。此时客户端需要自行处理连接均衡与故障转移，但可以获得更直接的拓扑控制。

Port forward 的定位与限制

端口转发适合临时调试，不改变集群网络配置即可从本地访问 Pod 或 Service。它不应作为生产访问方式，也不适合长期自动化。需要常规访问时，应设计正式的 Service 或 Ingress。

DNS 命名习惯

Kubernetes DNS 支持短名称与完整名称，跨命名空间时建议使用 service.namespace 形式。稳定的命名规则可以减少配置混乱，提升团队协作效率。

外部流量路径

外部流量通常经过负载均衡、NodePort、kube-proxy 到达 Pod，每一跳都会引入超时与失败点。排障时应按路径逐段确认连接状态。

安全与策略

NetworkPolicy 可能阻断通信，即便 DNS 能解析也无法连通。若使用 mTLS 或服务网格策略，要确保策略与 Service 选择器一致，避免意外断流。

运维建议

统一命名规则便于 DNS 预测。上线时关注 endpoints 是否及时更新，尤其是在滚动更新期间。外部流量要设置健康检查与超时策略，避免负载均衡层把请求打到不可用实例。

kubectl get svc -n demo
kubectl get endpoints -n demo
kubectl get endpointslices -n demo
kubectl port-forward svc/demo-api 8080:80 -n demo

收个尾：Service 不通，优先怀疑 endpoints

服务访问不通时，最容易走偏的就是一上来怀疑网络。我的经验是反过来：

1. 先看 Service selector 有没有选到 Pod
2. 再看 endpoints/endpointslices 里有没有地址
3. 最后才去看 DNS / NetworkPolicy / Ingress

因为 selector/labels 对不上、Pod 不 Ready、或者端口配错，这是最常见、也最便宜能验证的原因。

参考链接

• Service
• 服务与网络