概念
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/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$2
name: rewrite
namespace: default
spec:
ingressClassName: nginx
rules:
- host: rewrite.bar.com
http:
paths:
- path: /something(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: http-svc
port:
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
