一、为什么 ClusterIP 是默认值¶
当你创建一个 Service 但没有显式指定 type 时，它默认就是 ClusterIP。这意味着：
- Kubernetes 会为它分配一个虚拟 IP
- 这个 IP 只在集群内可访问
- 客户端通过这个 IP 或 Service DNS 名称访问后端 Pod
因此 ClusterIP 特别适合内部服务互调，比如 API 调 API、前端调后端、应用调中间件。
二、先创建后端 Deployment¶
原文先用一个 nginx Deployment 作为后端：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.cn-hangzhou.aliyuncs.com/zq-demo/nginx:1.14.2
ports:
- containerPort: 80
这里有两个很关键的字段：
spec.template.metadata.labels：Pod 会带上的标签spec.selector.matchLabels：Deployment 用来识别自己 Pod 的条件
三、再定义 ClusterIP Service¶
最小可用 Service 配置如下：
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
如果容器端口起了名字，targetPort 也可以直接引用端口名：
ports:
- containerPort: 80
name: http-web-svc
---
ports:
- protocol: TCP
port: 80
targetPort: http-web-svc
这在容器端口可能变化、但服务入口要保持稳定时很实用。
四、Service 建好后，为什么 Pod IP 变了也不怕¶
原文用删除全部 Pod 再重建的方式演示了这一点：
kubectl delete pod -l app=nginx
kubectl get pod -l app=nginx -o wide
kubectl get svc
curl 10.0.35.90
你会发现：
- Pod IP 变了
- Service 的 ClusterIP 不变
- 服务访问仍然正常
这正是 Service 的核心价值：让客户端不直接依赖瞬时 Pod 地址。
五、ClusterIP 怎么在集群内被访问¶
原文给了两种非常典型的访问方式。
1.1 同命名空间访问¶
在同一命名空间里，直接访问服务名就行：
kubectl exec -it nginx-deployment-xxx -- sh
wget http://my-service
这背后依赖的是集群 DNS，会把 my-service 解析成 my-service.default.svc.cluster.local 对应的 ClusterIP。
1.2 跨命名空间访问¶
跨命名空间时，需要把命名空间补上：
wget http://metrics-server.kube-system:443
这也是很多集群组件互调时常见的写法。
六、如何在集群里验证 ClusterIP 解析¶
原文还通过 debug 工具 Pod 演示了 DNS 解析和访问：
kubectl create deploy cluster-test --image=registry.cn-hangzhou.aliyuncs.com/zq-demo/debug-tools -- sleep 3600
kubectl exec -it cluster-test-xxx -- bash
nslookup my-service
curl my-service
你会看到：
nslookup返回的是 Service 的 ClusterIPcurl命中的是后端 nginx 页面
所以可以把 ClusterIP 理解成“只在集群内部有效的稳定虚拟入口”。只要业务流量不需要直接暴露到集群外，ClusterIP 往往就是最简单也最稳妥的选择。