LinuxKubernetes服务发现教程_Service与Ingress实践

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 不存在、端口不匹配）

不复杂但容易忽略。