K8s中的两种nginx-ingress-controller及其区别
有两种基于 NGINX 的 Ingress 控制器实现：一种是nginxinc/kubernetes-ingress，另一种是kubernetes/ingress-nginx。
什么是Ingress Controller?
为了让 Ingress 资源工作，集群中至少要有一个 Ingress Controller运行。 Ingress Controller抽象出 Kubernetes 应用程序流量路由的复杂性，并在 Kubernetes 服务和外部服务（外部世界）之间提供桥梁。[1]
您可以在集群中部署多个 Ingress Controller。这需要在创建 Ingress 时，使用适当的 ingress.class 注解 Ingress，以标识应使用哪个 Ingress Controller。如果没有定义指定，则使用默认的Ingress Controller。
一般情况下，所有Ingress Controller都应满足此规范，但各种Ingress Controller的操作略有不同。
目前有两种基于 NGINX 的 Kubernetes Ingress Controller——它们都是开源的并托管在 GitHub 上。一个是K8s开源社区的kubernetes/ingress-nginx，另一个是Nginx官方的nginxinc/kubernetes-ingress
主要区别
Kubernetes Ingress Controller
这是k8s官方社区开发维护的控制器，它是基于Nginx的，扩展功能则需要使用Lua插件实现。
NGINX Ingress Controller
这是由nginx的官方开发维护的控制器，它还有一个基于Nginx Plus的商业版本。NGINX 控制器具有高稳定性、持续向后兼容性、没有任何第三方模块、由于没有Lua 代码更高效（与k8s官方控制器相比）。
即使与官方控制器相比，免费软件版本也受到很大限制（由于没有Lua 模块）。同时，付费版本拥有相当广泛的附加功能：实时指标、JWT 验证、主动健康检查等。
关于 nginxinc/kubernetes-ingress 和kubernetes/ingress-nginx 的更多区别可见下表[2]:
| Aspect or Feature | kubernetes/ingress-nginx | nginxinc/kubernetes-ingress with NGINX | nginxinc/kubernetes-ingress with NGINX Plus |
|---|---|---|---|
| Fundamental | |||
| Authors | Kubernetes community | NGINX Inc and community | NGINX Inc and community |
| NGINX version | Custom NGINX build that includes several third-party modules | NGINX official mainline build | NGINX Plus |
| Commercial support | N/A | N/A | Included |
| Implemented in | Go/Lua (while Nginx is written in C) | Go/Python | Go/Python |
| Load balancing configuration via the Ingress resource | |||
| Merging Ingress rules with the same host | Supported | Supported via Mergeable Ingresses | Supported via Mergeable Ingresses |
| HTTP load balancing extensions - Annotations | See the supported annotations | See the supported annotations | See the supported annotations |
| HTTP load balancing extensions -- ConfigMap | See the supported ConfigMap keys | See the supported ConfigMap keys | See the supported ConfigMap keys |
| TCP/UDP | Supported via a ConfigMap | Supported via custom resources | Supported via custom resources |
| Websocket | Supported | Supported via an annotation | Supported via an annotation |
| TCP SSL Passthrough | Supported via a ConfigMap | Supported via custom resources | Supported via custom resources |
| JWT validation | Not supported | Not supported | Supported |
| Session persistence | Supported via a third-party module | Not supported | Supported |
| Canary testing (by header, cookie, weight) | Supported via annotations | Supported via custom resources | Supported via custom resources |
| Configuration templates | See the template | See the templates | See the templates |
| Load balancing configuration via Custom Resources | |||
| HTTP load balancing | Not supported | See VirtualServer and VirtualServerRoute resources | See VirtualServer and VirtualServerRoute resources |
| TCP/UDP load balancing | Not supported | See TransportServer resource | See TransportServer resource |
| TCP SSL Passthrough load balancing | Not supported | See TransportServer resource | See TransportServer resource |
| Deployment | |||
| Command-line arguments | See the arguments | See the arguments | See the arguments |
| TLS certificate and key for the default server | Required as a command-line argument/ auto-generated | Required as a command-line argument | Required as a command-line argument |
| Helm chart | Supported | Supported | Supported |
| Operator | Not supported | Supported | Supported |
| Operational | |||
| Reporting the IP address(es) of the Ingress controller into Ingress resources | Supported | Supported | Supported |
| Extended Status | Supported via a third-party module | Not supported | Supported |
| Prometheus Integration | Supported | Supported | Supported |
| Dynamic reconfiguration of endpoints (no configuration reloading) | Supported with a third-party Lua module | Not supported | Supported |
实际使用差别
当我们实际使用上述两个版本的Ingress控制器(Nginx官方和Kubernetes官方)时，特别需要注意的就是他们所支持的Annotation不同（这也是在我工作中经常处理遇到的问题，经常搞混导致设置不生效），比如下面的这个问题：
我们有一个数据量大的导出接口阻塞等待大约5分钟，每次在刚好1分钟时接口报错504 Gateway Time-out，怎么处理？
如果只是nginx，这只需要设置nginx的proxy_read_timeout（顾名思义这个参数是设置nginx代理读取超时时间，默认60s)即可。比如proxy_read_timeout 600s
对于kubernetes/ingress-nginx需要使用nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
对于nginxinc/kubernetes-ingress with NGINX需要使用nginx.org/proxy-read-timeout: "10m"
更多注解上的使用区分可查看kubernetes/ingress-nginx和nginxinc/kubernetes-ingress with NGINX