SRE文档1. Ingress文档
- Kubernetes Ingress
https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/
https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
https://kubernetes.github.io/ingress-nginx/
2. k8s和ingress对应版本关系
- Supported Versions table
Supported versions for the ingress-nginx project mean that we have completed E2E tests, and they are passing for the versions listed. Ingress-Nginx versions may work on older versions, but the project does not make that guarantee.
| Supported | Ingress-NGINX version | k8s supported version | Alpine Version | Nginx Version | Helm Chart Version |
|---|---|---|---|---|---|
| 🔄 | v1.10.1 | 1.29, 1.28, 1.27, 1.26 | 3.19.1 | 1.25.3 | 4.10.1* |
| 🔄 | v1.10.0 | 1.29, 1.28, 1.27, 1.26 | 3.19.1 | 1.25.3 | 4.10.0* |
| 🔄 | v1.9.6 | 1.29, 1.28, 1.27, 1.26, 1.25 | 3.19.0 | 1.21.6 | 4.9.1* |
| 🔄 | v1.9.5 | 1.28, 1.27, 1.26, 1.25 | 3.18.4 | 1.21.6 | 4.9.0* |
| 🔄 | v1.9.4 | 1.28, 1.27, 1.26, 1.25 | 3.18.4 | 1.21.6 | 4.8.3 |
| 🔄 | v1.9.3 | 1.28, 1.27, 1.26, 1.25 | 3.18.4 | 1.21.6 | 4.8.* |
| 🔄 | v1.9.1 | 1.28, 1.27, 1.26, 1.25 | 3.18.4 | 1.21.6 | 4.8.* |
| 🔄 | v1.9.0 | 1.28, 1.27, 1.26, 1.25 | 3.18.2 | 1.21.6 | 4.8.* |
| v1.8.4 | 1.27, 1.26, 1.25, 1.24 | 3.18.2 | 1.21.6 | 4.7.* | |
| v1.7.1 | 1.27, 1.26, 1.25, 1.24 | 3.17.2 | 1.21.6 | 4.6.* | |
| v1.6.4 | 1.26, 1.25, 1.24, 1.23 | 3.17.0 | 1.21.6 | 4.5.* | |
| v1.5.1 | 1.25, 1.24, 1.23 | 3.16.2 | 1.21.6 | 4.4.* | |
| v1.4.0 | 1.25, 1.24, 1.23, 1.22 | 3.16.2 | 1.19.10† | 4.3.0 | |
| v1.3.1 | 1.24, 1.23, 1.22, 1.21, 1.20 | 3.16.2 | 1.19.10† | 4.2.5 |
3. Ingress诞生背景
1、K8S集群内SVC不支持外部访问；
2、通过NodePort方式不易于后续管理；
3、应用层面需要更高级别的路由功能和负载平衡；
4. Ingress基本概念
4.1 为何需要Ingress
service的三种方式ClusterIP、NodePort与LoadBalance，这几种方式都是在service的维度提供的，service的作用体现在两个方面，
对集群内部，它不断跟踪pod的变化，更新endpoint中对应pod的对象，提供了ip不断变化的pod的服务发现机制，
对集群外部，他类似负载均衡器，可以在集群内外部对pod进行访问。
单独用service暴露服务的方式，存在一些问题：
1.如果通过NodePort暴露端口过多，后期维护成本太大，且不易于管理；
2.ClusterIP的方式只能在集群内部访问
3.LoadBalance方式受限于云平台，且通常在云平台部署ELB还需要额外的费用
4.目前Service底层使用的是IptabLes、IPVS，仅支持4层协议，无法完成https协议传输；
Kubernetes为了解决这种需求，提供了一种高级的流量管理，也就是Ingress和Ingress控制器，Kubernetes使用Ingress控制器来接收所有入口的流量，然后通过Ingress资源来定义流量如何区分，以及流量如何转发的规则。
有了Ingress和Ingress控制器，我们就可以直接定义流量转发规则来发布服务，而无需创建一堆的NodePort和LoadBalance类型的Service.
4.2 什么是Ingress
Ingress其实就是Kubernetes中的一种资源，它主要是用来定义流量转发规则。但Ingress资源自身并不能实现流量的转发和调度，它仅仅是一组流量路由的规则集合，这些规则要真正发挥作用还需要使用到Ingress控制器，由Ingress控制器读取对应的Ingress规则，然后完成流量的路由或转发。
Kubernetes 提出了一种新的 API 对象，叫做 Ingress，它通过定义不同的 HTTP 路由规则，将集群内部的 Service 通过 HTTP 的方式暴露到集群外部
4.3 Ingress Controller
Ingress ControLler就是一类以代理HTTP/HTTPS协议为主的代理程序。如:Nginx、Traefik、Envoy、Haproxy。Ingress Controller通过Pod的形式运行在Kubernetes集群上，它能够与集群上的Pod直接通信。这样就可以让用户的流量经过Ingress控制器时直接调度到对应的Pod上。
Ingress Controller类似Nginx服务，它负责读取Ingress的规则,然后转换将规则转换为nginx.conf配置文件，这样就可以根据对应的规则来实现流量的调度。同时它还会实时感知后端Service对应的Pod变化，当Pod发生变动后，Ingress控制器会再次结合Ingress的规则，进而完成对应的配置动态更新。
❌ 注意
使用Ingress资源进行流量分发时，Ingress控制器可基于ingress定义的规则将客户端的请求流量直接转发至Service对应的后端Pod资源上。比如：用户请求api.xxx.net，Ingress控制器根据对应的规则直接将请求流量调度至Pod3或Pod4，而无需经过Service对象转发
4.4 Ingress的组成
Ingress资源是一种虚拟的资源和规则定义，需要配合ingressController才能生效。所以要让Ingress资源工作，集群必须有一个正在运行的ingressController。
Ingress由Ingress规则、IngressController、IngressClass这3部分组成。
Ingress规则只是一系列的配置，必须使用IngressController才能使其生效，而IngressClass是IngressController的具体实现.
其他控制器
