在k8s之服务Service章节,我们详细的介绍了Service的组成以及相关的原理。Service可以将自身的服务暴露出去,给集群内部服务或者给外部服务去使用,或者将外部服务分装为一个service,供给集群内部服务使用。而今天介绍的ingress其实和service很类似,他都是将内部的服务暴露出来,给外界(包括集群内或集群外)去使用。只不过它两者工作的网络层级不同罢了。
1. Ingress引入
上一章节介绍的LoadBalancer已经能够将k8s内部服务暴露到公网上去了,似乎就已经可以了,为什么还需要ingress呢?因为服务最终无非就是内部使用或者外部使用。内部使用有clusterIP或者nodeIP,外部使用LoadBalancer,为什么还需要一个ingress呢?从LoadBalancer的原理上我们可以看到,如果每使用一个LoadBalancer Service,就需要一个新的公网LB+IP或者域名,而这些都需要花钱(当然在商业的驱动下,引入ingress也并没有说能够降低成本,但是确实是带来了便捷)。
这时候,ingress就出来了。Igress 是 Kubernetes 中定义“反向代理规则”的一种 API 对象,借助Ingress Controller(例如Nginx Ingress Controller)来执行反向代理。
2. Ingress是什么
ingress一共由2个组件组成:
-
ingress资源对象:配置了相关http路由转发规则的合集。
- 配置 Host(域名) 、Path(路径) 与后端 Service 的映射关系。
- 它本身不处理流量,只是一个“配置清单”。
- 通常不直接指定 Controller 名称,而是通过
spec.ingressClassName
间接关联 -
spec:ingressClassName: nginx-ingresclass # 指向IngressClass的名称rules:- host: example.comhttp:paths:- path: /apipathType: Prefixbackend:service:name: api-svc # 转发到哪个serviceport:number: 80 # service yaml文件中配置的port
-
ingressClass:ingres资源对象与ingress controller之间的桥梁。
-
apiVersion: networking.k8s.io/v1 kind: IngressClass metadata:name: nginx-ingresclass # Ingress资源定义中的spec.ingressClassName 一致annotations:ingressclass.kubernetes.io/is-default-class: "true" # 将这个 IngressClass 标记为集群中的“默认 IngressClass spec:controller: k8s.io/ingress-nginx # 与下面ingress controller的启动参数一致
-
-
ingress controller:一个运行在集群中的 Pod(或多个 Pod),本质是一个反向代理pod + 控制器(Controller)
-
反向代理:接收外部 HTTP/HTTPS 请求,根据规则转发到后端 Service 对应的 Pod。
-
控制器(Controller) :持续监听 Kubernetes API,自动发现 Ingress、Service、Endpoints 的变化,并动态更新自身的代理配置(如 Nginx 配置)。
-
启动时需声明自己自己的
controller
标识符(与 IngressClass 中的spec.controller
匹配)。# Ingress Controller Deployment 的启动参数示例 args:- --controller-class=k8s.io/ingress-nginx # 必须与 IngressClass.spec.controller 一致
-
当启动一个ingresss Controller的时候,会Watch所有的Ingress资源,然后对每个 Ingress,检查:
- 是否有
spec.ingressClassName
- 如果有,找到对应的
IngressClass
- 检查该
IngressClass.spec.controller
是否等于自己(k8s.io/ingress-nginx
) - 如果匹配则处理这个 Ingress(生成相关的反向代理规则),否则则忽略
Ingress能够提供从集群外部到集群内服务的http和https路由,是一组路由规则的集合。以下是一个ingress的请求例子。如果大家知道nginx的话,会发现ingress的原理是不是和nginx很类似。本质上来说ingress controller[注] 就是一个反向代理的服务(运行在pod上,基于Nginx、Traefik或者其他组件),然后基于路由规则,扮演着集群内部的“智能路由”角色。
互联网的网络流量,通过云产商的LB(或者Nodeport)转发到Ingress Controller上,然后Ingress Controller则会根据Ingress的路由定义,将又转发到Service,然后Service再转发到了pod中的服务。
@startuml
skinparam componentStyle rectangle
skinparam defaultTextAlignment center
skinparam wrapWidth 200package "外部网络" {[客户端\n(Client)] as client
}cloud "云平台 / 网络基础设施" {[负载均衡器\n(LoadBalancer)] as lb
}package "Kubernetes 集群" {[Ingress Controller\n(Pod)] as ingress_controllerpackage "Ingress 资源\n(定义多条路由规则)" {[Ingress\n(multi-rule-ingress)] as ingress_resource}package "Service 层" {[ClusterIP Service\n(web-svc)] as web_svc[ClusterIP Service\n(api-svc)] as api_svc[ClusterIP Service\n(shop-svc)] as shop_svc}package "工作负载" {[Pod\n(web-app-1)\napp=web] as web_pod1[Pod\n(web-app-2)\napp=web] as web_pod2[Pod\n(api-app-1)\napp=api] as api_pod1[Pod\n(api-app-2)\napp=api] as api_pod2[Pod\n(shop-app-1)\napp=shop] as shop_pod1}
}' ===== 数据流向 =====
client --> lb : 请求 1:\nhttps://example.com/
client --> lb : 请求 2:\nhttps://example.com/api/v1/users
client --> lb : 请求 3:\nhttps://shop.example.com/lb --> ingress_controller : 所有请求转发至\nIngress Controller\n(通过 LB IP/NodePort)ingress_controller --> ingress_resource : 读取 Ingress 规则\n匹配 Host/Path' 规则1: example.com/ -> web-svc
ingress_resource --> web_svc : 规则1:\nhost: example.com\npath: / -> web-svc' 规则2: example.com/api/ -> api-svc
ingress_resource --> api_svc : 规则2:\nhost: example.com\npath: /api/ -> api-svc' 规则3: shop.example.com/ -> shop-svc
ingress_resource --> shop_svc : 规则3:\nhost: shop.example.com\npath: / -> shop-svc' Service 到 Pod 的流量
web_svc --> web_pod1
web_svc --> web_pod2api_svc --> api_pod1
api_svc --> api_pod2shop_svc --> shop_pod1' ===== 配置与选择器关系(虚线)=====
ingress_controller ..> ingress_resource : 监听并动态加载\nIngress 配置web_svc ..> web_pod1 : selector:\napp=web
web_svc ..> web_pod2 : selector:\napp=webapi_svc ..> api_pod1 : selector:\napp=api
api_svc ..> api_pod2 : selector:\napp=apishop_svc ..> shop_pod1 : selector:\napp=shopnote right of ingress_resource**Ingress 多路由规则示例**:- 规则1: host=example.com, path=/ → web-svc- 规则2: host=example.com, path=/api/ → api-svc- 规则3: host=shop.example.com, path=/ → shop-svc
end notenote left of lbLoadBalancer 由云平台创建,将所有外部 HTTP/HTTPS 流量统一导入 Ingress Controller。
end notelegend**数据流转说明**:1. 客户端发起不同 Host/Path 的请求2. LB 将所有请求转发给 Ingress Controller3. Ingress Controller 根据 Ingress 资源中的多条规则匹配4. 不同规则路由到不同的 ClusterIP Service5. 各 Service 负载均衡到对应标签的 Pod
endlegend@enduml
Ingress 本身只是一个规则配置(一个资源对象),必须配合 Ingress Controller(如 Nginx、Traefik)才能工作。LoadBalancer 通常用于暴露 Ingress Controller 本身(通过 Service of type=LoadBalancer),而 Ingress Controller 再根据 Ingress 规则将流量分发到不同的内部 Service。
3. Ingress匹配规则
Ingress支持很多匹配规则,以下是相关常用的匹配规则:
匹配维度 | 规则类型 | 说明 | 示例 | 注意事项 |
---|---|---|---|---|
Host(域名) |
精确匹配 | 完全匹配指定域名 | host: example.com → 仅匹配 example.com |
区分大小写;必须是合法 DNS 名 |
单级通配符 | 仅支持前缀 *. ,匹配任意一级子域名 |
host: "*.example.com" → 匹配 foo.example.com ,不匹配 a.b.example.com |
不支持 example.* 或多级通配 |
|
省略 host | 匹配所有 Host(包括 IP 直接访问) | 无 host 字段 → 任何域名都进入该 rule |
生产环境慎用,易造成路由冲突 | |
Path(路径) |
pathType: Prefix |
前缀匹配(最常用) | path: /api → 匹配 /api 、/api/v1 、/api/ |
不匹配 /apis ;路径区分大小写 |
pathType: Exact |
完全相等匹配 | path: /api → 仅匹配 /api ,不匹配 /api/ |
路径末尾 / 视为不同路径 |
|
高级匹配 | 正则表达式(需 annotation) | 部分 Controller(如 Nginx)支持通过 annotation 启用正则 | nginx.ingress.kubernetes.io/use-regex: "true" + path: /v[0-9]+ |
依赖具体实现,非标准功能 |
匹配优先级 |
Host 优先 | 先匹配 Host,再在匹配的 Host 下匹配 Path | shop.example.com/api 不会匹配 api.example.com/api |
Host 不匹配则整条 rule 跳过 |
Path 最长前缀优先 | 在同一 Host 下,更长的路径优先匹配 | /api/v1 比 /api 优先 |
避免路径重叠导致意外路由 |
4. 4. 总结
Ingress 是 Kubernetes 中管理外部访问集群服务的核心机制,主要用于 HTTP/HTTPS 流量的七层路由。它本身只是一个 API 资源,定义了基于主机名(host)和路径(path) 的路由规则,将请求转发到后端 Service。但 Ingress 要真正生效,必须部署对应的 Ingress Controller(如 Nginx、Traefik、ALB 等)。Controller 会监听 Ingress 资源变化,动态生成反向代理配置(如 Nginx 配置),并自动重载以应用新规则。
5. 脚注
[注]
ingress controller