Ingress 选型

Nginx ingress 的缺点

Ingress 是 K8S 中非常重要的外网流量入口，前面又拍云的总监也讲到了 K8S 默认的 Nginx ingress。这个 ingress 是 K8S 所推荐的默认的 ingress。为了跟后面的 Nginx 提供的商业版 ingress 作为区分，我就叫它叫 K8S ingress。

第一个优点 K8S ingress，顾名思义基于 Nginx 的平台，Nginx 现在是世界上最流行的 Nginx HTTP Sever，相信在座各位都对 Nginx 比较熟悉，这是一个优点。

第二个优点则是 Nginx ingress 接入 K8S 集群所需配置非常少，而且有很多文档来指引你如何使用这个 ingress。这对于大部分刚接触 K8S 的人或者创业公司来说，Nginx ingress 确实是一个非常好的选择。

但是当 Nginx ingress 在一些大环境上使用时，就会有非常多的问题。

第一个，Nginx ingress它用了一些 OpenResty 的特性，但最终配置加载还是依赖于原有的 Nginx config reload。当路由配置非常大的时候，Nginx reload 会耗时非常久，可以达到几秒甚至十几秒，这种 reload 会很严重的影响业务，甚至造成业务中断，这是第一个问题。

第二个问题是 Nginx ingress 的插件开发非常困难，如果你觉得 Nginx ingress 本身插件够用，那还是可以用的。但如果想用一些定制化的插件，比如像阿里云的IM鉴权，或者是腾讯云的 KM 鉴权都需要进行额外的开发。Nginx ingress 开发插件非常痛苦，额外开发就非常麻烦，所以 Nginx ingress 的插件能力和可扩展性是比较差的。

Ingress 选型原则

既然发现了 Nginx ingress 有很多问题，那是不是考虑选择开源的更好用的 ingress，市场上说比 K8S ingress 好用的起码有十几家。如何从这么多 ingress 中选择适合自己的，这让人感到困扰。

Ingress 最终是基于 HTTP 网关的，市面上 HTTP 网关主要有这么几种。比如 Nginx、Golang 原生的以及新崛起的 Envoy 这些网关。但是每个开发人员所擅长的技术栈不同，例如我对 Nginx 比较熟悉，但有些人对 HAproxy 更加熟悉，或者有些人对新兴的 Envoy 这个网关更加熟悉。因为每个人熟悉的底层网关不一样，所以适合的 ingress 也会不一样。

那么问题来了，我们如何选择一个更加好用的 ingress 呢？或者缩小点范围，熟悉 Nginx 或 OpenResty 的开发人员，应该选择哪一个 ingress 呢？

下面来介绍一下我对 ingress 控制器选型的一些经验。△ 选型原则

基本特点

图中的这些我觉得是基本功能，这些功能必须要有。如果连这些功能都没有，那完全可以直接pass。

• 必须开源的，不开源的无法使用

• K8S 中 Pod 变化非常频繁，服务发现非常重要

• 现在 HTTPS 已经很普及了，TLS 或者 SSL 的能力也非常重要，比如证书管理的功能

• 支持 WebSocket 等常见协议，在某些情况下，可能还需要支持 HTTP2 、QUIC 等

基础软件

前面有提到，每个人擅长的技术平台不一样，所以选择自己更加熟悉的 HTTP 网关也显得至关重要。比如 Nginx、HAProxy、Envoy 或者是 Golang 原生网关。因为你熟悉它的原理，在使用中可以更快落地。

在生产环境上，高性能是一个很重要的点，但比之更重要的是高可用。这意味着你选择的网关，它的可用性、稳定性一定要非常强，只有这样，服务才能稳定。

功能需求

抛开上述两点，就是公司业务对网关的特殊需求。你选择一个开源产品，最好肯定是开箱能用的。比如你需要 GRPC 协议转换的能力，那当然希望选的网关直接支持这个功能。而肯定不希望去选择还需要开发的网关。这里简单列一下影响选择的点：

• 协议上是否支持 HTTP2、HTTP3；

• 负载均衡算法上，最基本的WRR，或者是一致性哈希这种负载均衡算法是否足够，还是需要更加复杂的类似EWMA负载均衡算法。

鉴权限流上，简单的鉴权是否足够，还是说需要更进阶的鉴权方式，或者要集成，或者很方便的能开发像阿里云、腾讯云的 IM 鉴权。前面我们有提到K8S ingress主要有这么些缺点，比如说 Nginx reload 的问题，插件扩展能力比较弱。其实它的后端节点调整权重的能力也不太好。

各种 Ingress 横向对比

Nginx ingress主要优点是在于它对 TCP 和 UDP 协议的完全支持，但是其他的，比如像鉴权方式，或者流量调度，这个功能都是非常缺失的。

Kong 本身是一个 API 网关，他也算是开创了先河，将 API 网关引入到 K8S 中当 ingress。另外对于边缘网关，大家还是有很多需求的，比如说像鉴权、限流、灰度部署等能力。Kong 在这些方面做的非常好。另外 Kong ingress 还有一个非常大的优点，他提供了一些 API、服务的定义，去抽象成 K8S 的 CRD，所以可以很方便地通过 K8S ingress 配置，去同步到 Kong 的集群。虽然 Kong 有很多优点，但 Kong 也有一个非常大的缺点，那就是部署特别困难，另外他的高可用，与 APISIX 相比也是相形见绌。

Traefik 是基于 Golang 的 ingress，它本身是一个微服务网关，但是在 ingress 的场景应用比较多。他的主要平台是基于 Golang，自身支持的协议也非常多，总体来说是没有什么缺点。如果大家熟悉 Golang 的话，也推荐一用。

HAproxy，是一个久负盛名的负载均衡器。它主要优点是有非常强大的负载均衡能力，其他方面并不占优势。

Istio ingress 和 Ambassador ingress 都是基于最近非常流行的 envoy。说实话，我觉得这两个 ingress 没有什么缺点，可能唯一的缺点是他们基于 envoy 平台，大家对这个平台都不是很熟悉，上手门槛会比较高。