Kubernetes Service 四种类型选型与常见坑

Kubernetes 的 Service 选型错误，最常见的后果不是「访问不了」，而是流量分发不符合预期却难以察觉。这篇把四种类型的边界讲清楚。

一、ClusterIP：默认类型，只在集群内可达

没有指定 type 时就是这个。分配一个集群内部虚拟 IP，只能被集群内的 Pod 访问。

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 8080
    targetPort: 8080

适用场景：内部微服务互相调用。绝大多数服务都应该是这个类型，只有最外层入口才需要暴露。

二、NodePort：在每个节点上开一个端口

NodePort 会在集群所有节点上监听一个端口（默认 30000-32767），外部通过任意节点 IP + 该端口访问。

三个常见坑：

• 端口范围有限，多个服务容易冲突，建议省略 nodePort 让系统自动分配
• 安全组必须放通该端口范围，否则外部依然连不上
• 节点 IP 变化后访问地址跟着变，不适合作为长期对外入口

三、LoadBalancer：云上最省事，但要花钱

声明 type: LoadBalancer 后，CCE 会自动创建弹性负载均衡并绑定 EIP，直接给你一个公网地址。

代价是每个 Service 一个 ELB 实例，成本不低。多个服务要共享一个入口时，应该用 Ingress 而不是堆一堆 LoadBalancer。

四、ExternalName：把外部域名映射成集群内名字

spec:
  type: ExternalName
  externalName: db.example.com

它不分配 IP，也不做代理，只返回一条 CNAME 记录。适合把外部数据库包装成集群内服务名，方便后续迁移。

选型判断顺序

1. 只给集群内用 → ClusterIP
2. 需要集群外访问且不想花钱 → NodePort（配合固定节点或前置 Nginx）
3. 云上要公网入口且预算允许 → LoadBalancer
4. 多个 HTTP 服务共用一个入口 → Ingress + ClusterIP，这才是生产环境的常规做法
5. 只是要给外部域名起个别名 → ExternalName

最后一句经验：Service 只负责四层转发，七层路由、灰度、证书这些都该交给 Ingress。把两类职责混在一个对象里，后面很难维护。