概念
Ingress 公开了从集群外部到集群内服务的 HTTP 和 HTTPS 路由,ingress能代理集群为内部的网络,将集群外部的HTTP/HTTPS网络请求转发至不同的service,其本质就是创建一个NodePort类型的svc,和一个nginx
组成
k8s中的ingress 其实是指的两个部分,第一个为ingress-controller (nginx) , 另一个为Ingress resource (nginx配置)那么到现在,有了 Ingress 和 Ingress Controller,我们是不是就可以完美地管理集群的进出流量了呢?
ingress控制器类似于nginx,Ingress类似于nginx的配置文件。如果只安装nginx,而没有nginx的配置文件,则此nginx将毫无意义;反过来,若只有nginx的配置文件,但没安装nginx,则配置文件无运行载体
IngressClass
最初 Kubernetes 也是这么想的,一个集群里有一个 Ingress Controller,再给它配上许多不同的 Ingress 规则,应该就可以解决请求的路由和分发问题了。
但随着 Ingress 在实践中的大量应用,很多用户发现这种用法会带来一些问题,比如:
由于某些原因,项目组需要引入不同的 Ingress Controller,但 Kubernetes 不允许这样做;
Ingress 规则太多,都交给一个 Ingress Controller 处理会让它不堪重负;
多个 Ingress 对象没有很好的逻辑分组方式,管理和维护成本很高;
集群里有不同的租户,他们对 Ingress 的需求差异很大甚至有冲突,无法部署在同一个 Ingress Controller 上。
所以,Kubernetes 就又提出了一个 Ingress Class 的概念,让它插在 Ingress 和 Ingress Controller 中间,作为流量规则和控制器的协调人,解除了 Ingress 和 Ingress Controller 的强绑定关系。
现在,Kubernetes 用户可以转向管理 Ingress Class,用它来定义不同的业务逻辑分组,简化 Ingress 规则的复杂度。比如说,我们可以用 Class A 处理博客流量、Class B 处理短视频流量、Class C 处理购物流量
ingress的类型
ingress重写转发路径
文档地址:https://kubernetes.github.io/ingress-nginx/examples/rewrite/
ingress 转发的时候是默认是将匹配的到路径直接转发到对应的svc
也就是说path中设置的前缀是会直接带到svc中去的,比如path为/java
访问www.abc/java 到svc中就是 svcIP:port/java,如果想重写url 比如
www.abc/java 到svc中变成 svcIP:port/就需要使用到注解 nginx.ingress.kubernetes.io/rewrite-target
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:annotations:nginx.ingress.kubernetes.io/use-regex: "true"nginx.ingress.kubernetes.io/rewrite-target: /$2name: rewritenamespace: defaultspec:ingressClassName: nginxrules:- host: rewrite.bar.comhttp:paths:- path: /something(/|$)(.*)pathType: ImplementationSpecificbackend:service:name: http-svcport: number: 80
效果:
rewrite.bar.com/something rewrites to rewrite.bar.com/
rewrite.bar.com/something/ rewrites to rewrite.bar.com/
rewrite.bar.com/something/new rewrites to rewrite.bar.com/new