K8s中的两种nginx-ingress-controller及其区别

ycyin大约 4 分钟云原生k8snginx-ingress

有两种基于 NGINX 的 Ingress 控制器实现:一种是nginxinc/kubernetes-ingressopen in new window,另一种是kubernetes/ingress-nginxopen in new window

什么是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-nginxopen in new window,另一个是Nginx官方的nginxinc/kubernetes-ingressopen in new window

主要区别

Kubernetes Ingress Controller

这是k8s官方社区开发维护的控制器,它是基于Nginx的,扩展功能则需要使用Lua插件实现。

NGINX Ingress Controller

这是由nginx的官方开发维护的控制器,它还有一个基于Nginx Plus的商业版本。NGINX 控制器具有高稳定性、持续向后兼容性、没有任何第三方模块、由于没有Lua 代码更高效(与k8s官方控制器相比)。

即使与官方控制器相比,免费软件版本也受到很大限制(由于没有Lua 模块)。同时,付费版本拥有相当广泛的附加功能:实时指标、JWT 验证、主动健康检查等。

关于 nginxinc/kubernetes-ingressopen in new windowkubernetes/ingress-nginxopen in new window 的更多区别可见下表[2]:

Aspect or Featurekubernetes/ingress-nginxnginxinc/kubernetes-ingress with NGINXnginxinc/kubernetes-ingress with NGINX Plus
Fundamental
AuthorsKubernetes communityNGINX Inc and communityNGINX Inc and community
NGINX versionCustomopen in new window NGINX build that includes several third-party modulesNGINX official mainline buildopen in new windowNGINX Plus
Commercial supportN/AN/AIncluded
Implemented inGo/Lua (while Nginx is written in C)Go/PythonGo/Python
Load balancing configuration via the Ingress resource
Merging Ingress rules with the same hostSupportedSupported via Mergeable IngressesSupported via Mergeable Ingresses
HTTP load balancing extensions - AnnotationsSee the supported annotationsopen in new windowSee the supported annotationsopen in new windowSee the supported annotationsopen in new window
HTTP load balancing extensions -- ConfigMapSee the supported ConfigMap keysopen in new windowSee the supported ConfigMap keysopen in new windowSee the supported ConfigMap keysopen in new window
TCP/UDPSupported via a ConfigMapSupported via custom resourcesSupported via custom resources
WebsocketSupportedSupported via an annotationSupported via an annotation
TCP SSL PassthroughSupported via a ConfigMapSupported via custom resourcesSupported via custom resources
JWT validationNot supportedNot supportedSupported
Session persistenceSupported via a third-party moduleNot supportedSupported
Canary testing (by header, cookie, weight)Supported via annotationsSupported via custom resourcesSupported via custom resources
Configuration templatesSee the templateopen in new windowSee the templatesSee the templates
Load balancing configuration via Custom Resources
HTTP load balancingNot supportedSee VirtualServer and VirtualServerRouteopen in new window resourcesSee VirtualServer and VirtualServerRouteopen in new window resources
TCP/UDP load balancingNot supportedSee TransportServeropen in new window resourceSee TransportServeropen in new window resource
TCP SSL Passthrough load balancingNot supportedSee TransportServeropen in new window resourceSee TransportServeropen in new window resource
Deployment
Command-line argumentsSee the argumentsopen in new windowSee the argumentsopen in new windowSee the argumentsopen in new window
TLS certificate and key for the default serverRequired as a command-line argument/ auto-generatedRequired as a command-line argumentRequired as a command-line argument
Helm chartSupportedSupportedSupported
OperatorNot supportedSupportedSupported
Operational
Reporting the IP address(es) of the Ingress controller into Ingress resourcesSupportedSupportedSupported
Extended StatusSupported via a third-party moduleNot supportedSupported
Prometheus IntegrationSupportedSupportedSupported
Dynamic reconfiguration of endpoints (no configuration reloading)Supported with a third-party Lua moduleNot supportedSupported

实际使用差别

当我们实际使用上述两个版本的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-nginxhttps://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/open in new windownginxinc/kubernetes-ingress with NGINXhttps://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/open in new window

参考:


  1. https://grigorkh.medium.com/there-are-two-nginx-ingress-controllers-for-k8s-what-44c7b548e678open in new window ↩︎

  2. https://gist.github.com/grigorkh/f8e4fd73e99f0fde06a51e2ed7c2156copen in new window ↩︎