Kubernetes 的 Service 有哪些类型？Ingress 是做什么的？

详细解析#

Service 的类型#

ClusterIP 是一个"虚拟 IP"，没有网卡真正持有它。每个节点上的 kube-proxy 监听 Service 和 EndpointSlice 的变化，用 iptables、IPVS 等机制在节点上写好转发规则，把发往 ClusterIP 的包改写成某个后端 Pod 的 IP。有些网络插件（如基于 eBPF 的实现）会替代 kube-proxy 做这件事。

集群内 DNS#

集群里的 DNS 服务（一般是 CoreDNS）会为每个 Service 生成记录，格式是 <服务名>.<命名空间>.svc.<集群域名>，集群域名默认是 cluster.local。同一命名空间内直接用服务名访问，如 http://web；跨命名空间用 web.shop。Headless Service 下，StatefulSet 的每个 Pod 还会有自己的记录，如 mysql-0.mysql.db.svc.cluster.local。DNS 本身的原理见 DNS 解析过程。

Ingress 和 Ingress Controller#

每个对外服务都用一个 LoadBalancer，成本高，也没法按路径路由。Ingress 让多个服务共用一个入口：

• 按域名和路径路由：api.example.com 转给 api 服务，example.com/ 转给前端
• TLS 终止：证书放在 Secret 里，由 Ingress 引用
• 必须有 Controller：Ingress 对象只是规则，要部署一个 Ingress Controller（例如基于 NGINX、Traefik、Envoy 的实现或云厂商提供的实现）来监听这些规则并真正转发流量，它本质是一个运行在集群里的 反向代理。ingressClassName 指定由哪个 Controller 处理

Ingress 的标准字段能力有限，限流、重写、灰度等功能往往靠各个 Controller 自己的注解，换实现时要重写。Kubernetes 官方现在推荐用 Gateway API 替代 Ingress：它把基础设施（Gateway）和路由规则（HTTPRoute 等）分开，表达能力更强、各实现之间更一致。Ingress API 已经冻结，不再增加新功能，但仍是稳定版、没有移除计划，存量项目大量在用。

外部流量到 Pod 的路径#

客户端
  │  DNS 解析 example.com
  ▼
云负载均衡器（LoadBalancer 类型的 Service，指向 Ingress Controller）
  │
  ▼
Ingress Controller Pod（七层：按 Host 和 Path 匹配，做 TLS 终止）
  │  按规则选中 Service，通常直接转发到它的后端 Pod IP
  ▼
Service web（ClusterIP，由 EndpointSlice 记录就绪的 Pod）
  │
  ▼
Pod web-xxx :3000

代码示例#

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  ingressClassName: nginx        # 由哪个 Ingress Controller 处理，名字取决于集群里的 IngressClass
  tls:
    - hosts: [example.com]
      secretName: example-com-tls   # 类型为 kubernetes.io/tls 的 Secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix     # 必填：Prefix、Exact 或 ImplementationSpecific
            backend:
              service:
                name: api
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

面试官可能追问#

易错点#

• 创建了 Ingress 却没有部署 Ingress Controller，规则不会生效
• 以为 Service 能按 HTTP 路径路由，Service 只在四层转发
• 把 Headless Service 当成普通 Service，以为它会做负载均衡
• 长连接场景下以为 Service 能把请求均匀分到每个 Pod