Service是Kubernetes中为Pod提供稳定访问的核心机制，通过固定虚拟IP和DNS将流量负载均衡至后端健康Pod；Ingress则在Service之上实现HTTP层七层路由，二者协同完成从外部请求到具体Pod的解耦式转发。

Service：让Pod可被稳定访问的核心机制

Pod是Kubernetes中最小的调度单元，但它的IP地址会随着重建、扩缩容而频繁变化。直接依赖Pod IP通信不可靠。Service就是为解决这个问题而生——它提供一个固定的虚拟IP（ClusterIP）和DNS名称，将流量负载均衡到后端一组健康Pod上。

常见Service类型有：

• ClusterIP：默认类型，仅在集群内部可达，适合服务间调用
• NodePort：在每个节点的固定端口暴露服务，外部可通过:访问，适合测试或小规模部署
• LoadBalancer：云厂商自动创建外部负载均衡器，映射到Service，适合生产环境对外暴露
• ExternalName：通过CNAME将Service映射到外部域名，不代理流量，仅做DNS别名

定义一个简单的ClusterIP Service示例：

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

注意selector必须与后端Pod的label严格匹配，否则Endpoint不会生成，kubectl get endpoints nginx-svc会显示。

Ingress：统一入口，按HTTP规则路由流量

Service只能基于IP+端口转发，无法识别URL路径、Host头等HTTP层信息。Ingress作为API对象，配合Ingress Controller（如Nginx Ingress、Traefik），实现七层路由能力，是Web类应用对外暴露的标准方式。

它不替代Service，而是“站在Service前面”——Ingress规则最终把请求转发给某个Service。

一个基础Ingress示例（需确保Ingress Controller已部署）：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-svc
            port:
              number: 80

关键点：

• pathType推荐用Prefix或Exact，避免模糊匹配引发意外路由
• Ingress本身不处理TLS；需通过tls字段声明证书，并挂载Secret，Controller才会启用HTTPS
• 单个Ingress资源可定义多Host、多路径，但实际路由能力取决于所用Controller的功能支持

Service与Ingress协作的典型流程

用户访问https://app.example.com/orders，实际经过三层转发：

• DNS解析到Ingress Controller所在节点（或云LB VIP）
• Ingress Controller根据Host和Path匹配规则，将请求转发给对应Service（如orders-svc）
• Service通过iptables或IPVS，将请求负载均衡到后端带app: orders标签的Pod

这个链路里每一环都可独立管理：Pod扩缩不影响Service，Service变更不影响Ingress规则，Ingress升级也不影响后端服务。这种解耦正是Kubernetes服务发现设计的精髓。

排错与验证建议

服务不通？按顺序检查：

• 确认Pod运行正常：kubectl get pods -l app=xxx，状态为Running且Ready为1/1
• 确认Endpoints已就绪：kubectl get endpoints xxx-svc，应列出Pod IP和端口
• 确认Service能被集群内解析：kubectl run test --image=busybox:1.35 --rm -it -- nslookup xxx-svc
• 对Ingress，先查Ingress资源是否生效：kubectl get ingress看ADDRESS列是否有IP；再查Ingress Controller日志，确认规则是否加载成功
• 用kubectl describe ingress xxx查看Events，常有配置错误提示（如Service不存在、端口不匹配）

不复杂但容易忽略。