Service 与集群内 DNS

Pod 的 IP 靠不住#

上一章的 Deployment 让 Pod 一直有 2 个副本，但你现在还没法稳定地访问它们，因为 Pod 的 IP 有两个特性：

• 会变：Pod 重建后 IP 一定不同，你不可能把它写进配置文件或代码里。
• 有多个：2 个副本就是 2 个 IP，调用方得自己选一个、自己处理某个副本挂掉的情况。

Service 就是解决这件事的：它给一组 Pod 提供一个固定的虚拟 IP 和一个固定的 DNS 名字，调用方只认这个入口，后面的 Pod 换了几轮都不影响。

Service 不转发流量到「某个 Pod」，而是转发到「一组符合标签的 Pod」——这组 Pod 随时可以变。

Service 如何选中 Pod：selector 与 EndpointSlice#

Service 选 Pod 的方式和 Deployment 一样：靠标签，也就是 spec.selector 里写的 app: web。

凡是带 app: web 标签、且与 Service 在同一个命名空间的 Pod，都会被自动加入这个 Service 的后端列表。这个列表由 Kubernetes 自动维护，Pod 一起一灭，列表立刻跟着变。

后端列表本身是一个独立资源，历史上叫 Endpoints，现在叫 EndpointSlice（Endpoints 已被弃用，由 EndpointSlice 取代；kube-proxy 实际消费的是 EndpointSlice）。你可以直接查看它：

kubectl get endpointslices -n demo

一条链路串起来看：

Service（固定 IP + DNS 名，selector: app=web）
   │  自动收集
   ▼
EndpointSlice（当前就绪的 Pod IP 列表）
   │  转发到
   ▼
Pod web-xxx / web-yyy

EndpointSlice 里的每个地址都带一个 ready 条件，kube-proxy 默认只把 ready 的地址作为转发目标。这是滚动更新不中断服务的关键：新 Pod 没通过就绪探针前，不会接到任何流量。

三种类型：ClusterIP、NodePort、LoadBalancer#

Service 有三种常用类型，差别只在「谁能访问到它」：

入门阶段的建议很简单：默认用 ClusterIP，需要临时从本机看效果就用 `port-forward`。NodePort 主要用于本地集群做验证，LoadBalancer 在 kind 上不会真的分配外部 IP（会一直显示 EXTERNAL-IP <pending>），本地实验不要指望它。

动手：创建 web 的 ClusterIP Service#

先确认上一章的 web Deployment 还在：

kubectl get deploy web -n demo

保存下面这份清单为 web-service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP

三个端口的含义必须分清：

应用并验证：

kubectl apply -f web-service.yaml
kubectl get svc -n demo
kubectl get svc web -n demo -o wide
kubectl get endpointslices -n demo

kubectl get svc 里 web 的 TYPE 是 ClusterIP，PORT(S) 是 80/TCP，CLUSTER-IP 是一个集群内部地址（具体网段取决于你的集群）。kubectl get svc web -o wide 的 SELECTOR 列应显示 app=web。kubectl get endpointslices 的 ENDPOINTS 列应列出两个 Pod IP；如果这一列是 <unset>，说明一个 Pod 都没选中，先去查标签。

在集群内验证 DNS 与访问#

ClusterIP 只在集群内可达，所以要起一个临时 Pod 进去试。--rm 表示退出后自动删除：

kubectl run tmp --rm -it --image=busybox:1.36 -n demo -- sh

进入容器后依次执行：

nslookup web
wget -qO- http://web
nslookup web.demo.svc.cluster.local
exit

nslookup web 会返回 web 对应的 ClusterIP；wget -qO- http://web 应该打印出 nginx 的欢迎页 HTML。看到这两样，说明 Service 的 DNS 和转发都通了。

Service 的完整 DNS 名规则是：

<service>.<namespace>.svc.cluster.local

也就是 web.demo.svc.cluster.local。之所以能只写 web 就解析成功，是因为 Pod 的 /etc/resolv.conf 里带了搜索域：

search demo.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10

• 同一个命名空间内：写 web 就够；
• 跨命名空间：写 web.demo；
• 最保险、最不依赖配置的写法：写完整 FQDN。

跨命名空间访问时，本章的 web 就是 web.demo.svc.cluster.local，第 8 章 Ingress 里配置后端地址时也是这个思路。

NodePort 与 port-forward#

想把服务临时暴露到集群外，有两种常见做法。

做法一：NodePort。 在 Service 上把 type 改成 NodePort 并指定一个端口：

apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
  namespace: demo
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30080
      protocol: TCP

kubectl apply -f web-nodeport.yaml
kubectl get svc web-nodeport -n demo

PORT(S) 会显示 80:30080/TCP。nodePort 必须在 30000-32767 范围内（不写则自动分配）。但 kind 集群的节点本身跑在 Docker 容器里，宿主机访问不到容器内的 30080，所以需要在创建集群时做端口映射：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30080
        hostPort: 30080
        protocol: TCP

映射之后 curl http://localhost:30080 就能看到 nginx 页面。如果集群已经建好了，重新建集群太麻烦，就直接用下面的做法。

做法二：port-forward。 它通过 API Server 建一条隧道，把本机端口转发到 Service，不管 Service 是什么类型都能用：

kubectl port-forward svc/web 8080:80 -n demo

另开一个终端：

curl http://localhost:8080

8080:80 的含义是「本机 8080 → Service 的 80」。这条命令适合调试，不要当成生产暴露方式：它绑定在你本机、随进程退出而结束，也没有负载均衡与健康检查。

headless Service 是什么#

把 spec.clusterIP 设为 None，就是一个 headless Service：它不再分配虚拟 IP，DNS 查询会直接返回所有后端 Pod 的 IP，让客户端自己挑。典型用途是给有状态应用（如 redis、数据库）做点对点连接，或配合 StatefulSet 的稳定网络标识。入门阶段知道「有这种东西、clusterIP: None 就是它」即可。

常见坑与排错#

kubectl get pods -n demo --show-labels
kubectl get svc web -n demo -o wide

kubectl get svc web -n demo -o yaml
kubectl get deploy web -n demo -o jsonpath='{.spec.template.spec.containers[0].ports}'

Service 不通的排查顺序#

访问不通时不要从浏览器或 curl 的报错猜，按这条链路一层层验证，每一步都能独立得出结论：

1. 先看 EndpointSlice：kubectl get endpointslices -n demo。ENDPOINTS 是 <unset>，问题就在标签或命名空间，跟网络无关，跳到第 4 步。
2. 再确认端口：kubectl get svc web -n demo -o yaml 看 port 与 targetPort，和 kubectl get deploy web -n demo -o jsonpath='{.spec.template.spec.containers[0].ports}' 对比。targetPort 必须等于容器真正监听的端口。
3. 进容器验证后端本身：kubectl run tmp --rm -it --image=busybox:1.36 -n demo -- sh，然后 wget -qO- http://web。通了说明 Service 与后端都正常，问题在调用方（比如在别的命名空间用了短名）。
4. 对比标签：kubectl get pods -n demo --show-labels 与 kubectl get svc web -n demo -o wide 的 SELECTOR 列，键和值必须完全一致。
5. 最后看 DNS：容器里 nslookup web 有没有结果。解析失败通常是命名空间写错，或 Pod 的 dnsPolicy / resolv.conf 被改过。

小结#

• Pod IP 会变、副本会增减，Service 提供固定的虚拟 IP 与 DNS 名，让调用方只认入口。
• Service 用标签（selector）在同一命名空间内选中 Pod，后端列表由 EndpointSlice 维护，kube-proxy 只转发到 ready 的地址。
• ClusterIP 只能集群内访问；NodePort 通过节点端口暴露；LoadBalancer 依赖云厂商或 MetalLB，本地 kind 上通常不可用。
• Service 的 DNS 名规则是 <service>.<namespace>.svc.cluster.local，同命名空间内可以直接用短名。
• port-forward 适合调试，不适合生产；nodePort 在 kind 里需要 extraPortMappings。

练习#

1. 把 web Service 的 targetPort 改成 8080，用 wget -qO- http://web 观察报错，再改回 80。
2. 建一个 NodePort 类型的 Service，用 kubectl get svc -n demo 找到端口，再写一份带 extraPortMappings 的 kind 配置，说明为什么直接 curl localhost:端口 会失败。
3. 想一想：如果后端是 redis 这种有状态服务，为什么有时候会需要 headless Service，而不是 ClusterIP？

现在集群内部能互相访问了，但外部用户还是进不来，而且 Service 只有四层转发能力，无法按域名和路径分流。下一章我们用 第 8 章 Ingress 把流量从集群外引进来。

相关章节：这组 Pod 是怎么来的，见第 6 章 Deployment；标签与 selector 的基础写法见第 5 章 用 YAML 描述 Pod。