当前位置：首页 > news >正文

ingress和service区别

news 2025/8/23 10:21:23

1. Service：内部负载均衡与服务发现

功能：
- 服务发现： 为动态变化的 Pod 集合（通常由 Deployment 或 StatefulSet 管理）提供一个稳定的访问端点（虚拟 IP 地址和 DNS 名称）。
- 负载均衡： 将发送到 Service 的请求（内部或外部）自动、均匀地分发到其后端健康的 Pod 上。
工作层级： TCP/IP 模型的第 4 层 (传输层)。主要处理 TCP/UDP 协议，根据 IP 地址和端口号进行转发。
类型：
- ClusterIP (默认)： 仅在集群内部可访问的虚拟 IP。用于内部服务间通信。
- NodePort： 在每个集群节点上开放一个静态端口（范围：30000-32767）。访问 : 的流量会被转发到对应的 Service，再由 Service 转发到 Pod。提供了一种从集群外部访问的方式，但通常不直接用于生产（需管理防火墙、端口冲突等）。
- LoadBalancer： 在云服务商环境中，自动创建一个外部负载均衡器（如 AWS ELB, GCP LB, Azure LB），并将外部流量直接路由到该 Service。该 Service 再将流量分发给 Pod。这是将服务直接暴露给互联网的常见方式。
- ExternalName： 将 Service 映射到一个外部 DNS 名称（如 my-database.example.com），用于代理集群外部的服务。
主要目标： 让集群内部的其他组件（或其他 Service）能够稳定、可靠地访问一组 Pod。 解决的是“如何找到并连接后端 Pod”的问题。
配置： 通过 Service 资源定义（kind: Service）。

2. Ingress：外部 HTTP(S) 访问管理

功能：
- HTTP/HTTPS 路由： 基于主机名（Host）、路径（Path）、请求头等 HTTP/HTTPS 属性，将外部流量路由到集群内部不同的 Service（不是直接到 Pod）。
- SSL/TLS 终止： 在 Ingress 层面处理 HTTPS 加密/解密（卸载），将明文的 HTTP 流量转发给后端 Service。简化后端服务证书管理。
- 虚拟主机： 在同一个 IP 地址上托管多个网站或服务（基于 Host 头）。
工作层级： TCP/IP 模型的第 7 层 (应用层)。主要处理 HTTP/HTTPS 协议，理解 URL 路径、主机名、请求头等信息。
关键依赖：Ingress Controller
- Ingress 本身只是一组规则（kind: Ingress 资源），定义了路由逻辑。
- 需要部署一个 Ingress Controller 来实际监听这些规则并执行路由功能。常见的 Ingress Controller 有：
  - Nginx Ingress Controller
  - Traefik
  - HAProxy Ingress
  - AWS ALB Ingress Controller
  - GKE Ingress Controller (基于 Google Cloud Load Balancing)
主要目标： 提供一种统一、声明式的方式来管理从集群外部（通常是互联网）访问内部 HTTP/HTTPS 服务的入口规则。 解决的是“如何根据 HTTP 请求的属性智能地将外部流量分发到不同的内部服务”的问题。
配置： 通过 Ingress 资源定义（kind: Ingress）。

核心区别总结

特性	Service	Ingress
主要目的	内部负载均衡与服务发现	管理外部 HTTP/HTTPS 访问入口
工作层级	第 4 层 (TCP/UDP)	第 7 层 (HTTP/HTTPS)
直接暴露	NodePort / LoadBalancer 类型可直接暴露服务	本身不暴露服务，需要配合 LoadBalancer Service 或 NodePort（通常由 Ingress Controller 使用）
路由能力	基于 IP 和端口	基于主机名、URL 路径、请求头等 HTTP(S) 属性
TLS/SSL	不处理应用层加密	支持 TLS/SSL 终止（在 Ingress 层面处理证书）
依赖	kube-proxy（实现 ClusterIP）	必须部署 Ingress Controller
资源类型	`Service`	`Ingress`
作用对象	直接负载均衡到 Pod (通过 Endpoints/EndpointSlice)	路由到 Service (再由 Service 负载均衡到 Pod)

流量路径示例（典型场景）

外部用户访问一个 Kubernetes 应用的典型流程：

用户 -> DNS: 用户通过浏览器访问 https://shop.example.com/checkout。
DNS -> Load Balancer: DNS 解析到 Ingress Controller 前面的 LoadBalancer Service 的外部 IP（或直接解析到 Ingress Controller 的节点 IP 如果是 NodePort）。
Load Balancer -> Ingress Controller: 流量到达 Ingress Controller 的 Pod。
Ingress Controller (应用 Ingress 规则):
- 检查请求的 Host: shop.example.com 和 Path: /checkout。
- 根据匹配的 Ingress 规则，确定应该将请求转发到哪个后端 Service（例如名为 checkout-service 的 ClusterIP Service）。
Ingress Controller -> Service: Ingress Controller 将请求发送到 checkout-service 的 ClusterIP 和端口。
Service (负载均衡) -> Pod: checkout-service 根据其负载均衡机制（如 iptables/IPVS），将请求转发到其中一个健康的 checkout Pod 上。
Pod 处理请求: checkout Pod 处理请求并返回响应，响应沿着原路径（大致）返回给用户。