ingress和service区别
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 处理请求并返回响应,响应沿着原路径(大致)返回给用户。
简单来说
Service 是集群内部的负载均衡器(四层),负责将流量分发到 Pod;Ingress 是管理外部 HTTP(S) 流量的入口网关(七层),通过规则将请求路由到后端的 Service。
超精简版:
🔹 Service:内部调度员(去哪组 Pod)
🔹 Ingress:外部路由器(去哪类 Service)
两者协同工作:外部流量 → Ingress(路由规则) → Service(负载均衡) → Pod。