宅家学习，如何进行Kubernetes Ingress控制器的技术选型？

傷城~ 2023-07-25 14:14 14阅读 0赞

> 导语：在Kubernetes的实践、部署中，为了解决 Pod 迁移、Node Pod 端口、域名动态分配等问题，需要开发人员选择合适的 Ingress 解决方案。面对市场上众多Ingress产品，开发者该如何分辨它们的优缺点？又该如何结合自身的技术栈选择合适的技术方案呢？

### 文章目录 ###

*  名词解释
 *  Kubernetes现状
 *  Nginx Ingress 的缺点
 *  Ingress选型经验
 *   *  1.基本特点
     *  2.基础软件
     *  3.功能需求
 *  选择Apache APISIX
 *  总结
 *  题外话

# 名词解释 #

阅读本文需要熟悉以下基本概念：

*  集群：是指容器运行所需云资源的集合，包含了若干台云服务器、负载均衡器等云资源。
 *  实例（Pod）：由相关的一个或多个容器构成一个实例，这些容器共享相同的存储和网络空间。
 *  工作负载（Node）：Kubernetes 资源对象，用于管理 Pod 副本的创建、调度以及整个生命周期的自动控制。
 *  服务（Service）：由多个相同配置的实例（Pod）和访问这些实例（Pod）的规则组成的微服务。
 *  Ingress：Ingress 是用于将外部 HTTP（S）流量路由到服务（Service）的规则集合。

# Kubernetes现状 #

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SwUl608G-1586938588443)(http://km.oa.com/files/photos/pictures//20200219//1582092075\_26.png)\]][img-SwUl608G-1586938588443_http_km.oa.com_files_photos_pictures_20200219_1582092075_26.png]

在 Kubernetes 中，服务跟 Pod IP 主要供服务在集群内访问使用，对于集群外的应用是不可见的。怎么解决这个问题呢？为了让外部的应用能够访问 Kubernetes 集群中的服务，通常解决办法是 NodePort 和 LoadBalancer。

这两种方案其实各自都存在一些缺点：

*  NodePort 的缺点是一个端口只能挂载一个 Service，而且为了更高的可用性，需要额外搭建一个负载均衡。
 *  LoadBalancer 的缺点则是每个服务都必须要有一个自己的 IP，不论是内网 IP 或者外网 IP。更多情况下，为了保证 LoadBalancer 的能力，一般需要依赖于云服务商。

在Kubernetes的实践、部署中，为了解决像 Pod 迁移、Node Pod 端口、域名动态分配，或者是 Pod 后台地址动态更新这种问题，就产生了 Ingress 解决方案

# Nginx Ingress 的缺点 #

Ingress 是Kubernetes中非常重要的外网流量入口。在Kubernetes中所推荐的默认值为Nginx Ingress，为了与后面Nginx 提供的商业版 Ingress 区分开来，我就称它为Kubernetes Ingress。

Kubernetes Ingress，顾名思义基于 Nginx 的平台，Nginx 现在是世界上最流行的 Nginx HTTP Sever，相信大家都对 Nginx 也比较熟悉，这是一个优点。它还有一个优点是 Nginx Ingress 接入 Kubernetes 集群所需的配置非常少，而且有很多文档来指引你如何使用它。这对于大部分刚接触 Kubernetes 的人或者创业公司来说，Nginx Ingress 的确是一个非常好的选择。

但是当 Nginx Ingress 在一些大环境上使用时，就会出现很多问题：

*  第一个问题：Nginx Ingress用了一些 OpenResty 的特性，但最终配置加载还是依赖于原有的 Nginx config reload。当路由配置非常大时，Nginx reload 会耗时很久，时间长达几秒甚至十几秒，这样就会严重影响业务，甚至造成业务中断。
 *  第二个问题：Nginx Ingress 的插件开发非常困难。如果你认为 Nginx Ingress 本身插件不够用，需要使用一些定制化插件，这个额外的开发任务对程序员来说是十分痛苦的。因为Nginx Ingress自身的插件能力和可扩展性非常差。

# Ingress选型经验 #

既然发现了 Nginx Ingress 有很多问题，那是不是考虑选择其他开源的、更好用的 Ingress？市场上比 Kubernetes Ingress 好用的Ingress起码有十几家，那么如何从这么多 Ingress 中选择适合自己的呢？

Ingress 自身是基于 HTTP 网关的，市面上 HTTP 网关主要有这么几种：Nginx、Golang 原生的网关，以及新崛起的 Envoy 。但是每个开发人员所擅长的技术栈不同，所以适合的 Ingress 也会不一样。

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

下面来介绍一下我对 Ingress 控制器选型的一些经验。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70]

## 1.基本特点 ##

首先我认为Ingress 控制器应该具备以下基本功能，如果连这些功能都没有，那完全可以直接pass。

*  必须开源的，不开源的基本可以pass
 *  Kubernetes 中Pod 变化非常频繁，服务发现非常重要。
 *  现在 HTTPS 已经很普及了，TLS 或者 SSL 的能力也非常重要，比如证书管理的功能。
 *  支持 WebSocket 等常见协议，在某些情况下，可能还需要支持 HTTP2 、QUIC 等协议。

## 2.基础软件 ##

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

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

## 3.功能需求 ##

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

*  协议：是否支持 HTTP2、HTTP3；
 *  负载均衡算法：最基本的WRR、一致性哈希负载均衡算法是否能够满足需求，还是需要更加复杂的类似EWMA负载均衡算法。
 *  鉴权限流：仅需要简单的鉴权，或更进阶的鉴权方式。又或者需要集成，能够快速的开发出像腾讯云 IM 的鉴权功能。Kubernetes Ingress除了前面我们提到的存在Nginx reload 耗时长、插件扩展能力差的问题，另外它还存在后端节点调整权重的能力不够灵活的问题。

# 选择Apache APISIX #

相比Kubernetes Ingress，我个人更推荐 APISIX 作为Ingress controller。虽然它在功能上比 Kong 会少很多，但是 APISIX 很好的路由能力、灵活的插件能力，以及本身的高性能，能够弥补在 Ingress 选型上的一些缺点。对于基于 Nginx 或 Openresty 开发的程序员，如果对现在的 Ingress 不满意，我推荐你们去使用 APISIX 作为 Ingress。

如何将 APISIX 作为 Ingress 呢？我们首先要做出一个区分，Ingress 是 Kubernetes 名称的定义或者规则定义，Ingress controller 是将 Kubernetes 集群状态同步到网关的一个组件。但 APISIX 本身只是 API 网关，怎么把 APISIX 实现成 Ingress controller 呢？我们先来简要了解一下如何实现 Ingress。

实现 Ingress，本质上就只有两部分内容：

*  第一部分：需要将 Kubernetes 集群中的配置、或 Kubernetes 集群中的状态同步到 APISIX 集群。
 *  第二部分：需要将 APISIX中 的一些概念，比如像服务、upstream 等概念定义为 Kubernetes 中的 CRD。

如果实现了第二部分，通过 Kubernetes Ingress 的配置，便可以很快的产生 APISIX。通过 APISIX Ingress controller 就可以产生 APISIX 相关的配置。当前为了快速的将 APISIX 落地为能够支持 Kubernetes 的 Ingress ，我们创建了一个开源项目，叫 Ingress Controller。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70 1]

上图为Ingress controller 项目的整体架构图。左边部分为 Kubernetes 集群，这里可以导入一些 yaml 文件，对 Kubernetes 的配置进行变更。右边部分则是 APISIX 集群，以及它的控制面和数据面。从架构图中可以看出，APISIX Ingress 充当了 Kubernetes 集群以及 APISIX 集群之间的连接者。它主要负责监听 Kubernetes 集群中节点的变化，将集群中的状态同步到 APISIX 集群。另外，由于Kubernetes 倡导所有组件都要具备高可用的特性，所以在 APISIX Ingress 设计之初，我们通过双节点或多节点的模式来保证 APISIX Ingress Controller 的保障高可用。

# 总结 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70 2]

相对于市面上流行的 Ingress 控制器，我们简单对比来看看 APISIX ingress 有什么优缺点。上图是外国开发人员针对 Kubernetes Ingress 选型做的一张表格。我在原来表格的基础上，结合自己的理解，将 APISIX Ingress 的功能加入了进来。我们可以看到，最左边的是APISIX，后边就是 Kubernetes Ingress 和 Kong Ingress，后面的 Traefik，就是基于 Golang 的 Ingress。HAproxy 是比较常见的，过去是比较流行的负载均衡器。Istio 和 Ambassador 是国外非常流行的两个Ingress。接下来我们总结下这些 Ingress各自的优缺点：

*  APISIX Ingress：APISIX Ingress 的优点前面也提到了，它具有非常强大的路由能力、灵活的插件拓展能力，在性能上表现也非常优秀。同时，它的缺点也非常明显，尽管APISIX开源后有非常多的功能，但是缺少落地案例，没有相关的文档指引大家如何使用这些功能。
 *  Kubernetes Ingress：即 Kubernetes 推荐默认使用的 Nginx Ingress。它的主要优点为简单、易接入。缺点是Nginx reload耗时长的问题根本无法解决。另外，虽然可用插件很多，但插件扩展能力非常弱。
 *  Nginx Ingress：主要优点是在于它完全支持 TCP 和 UDP 协议，但是缺失了鉴权方式、流量调度等其他功能。
 *  Kong：其本身就是一个 API 网关，它也算是开创了先河，将 API 网关引入到 Kubernetes 中当Ingress。另外相对边缘网关，Kong 在鉴权、限流、灰度部署等方面做得非常好。Kong Ingress 还有一个很大的优点：提供了一些 API、服务的定义，可以抽象成 Kubernetes 的 CRD，通过K8S Ingress 配置便可完成同步状态至 Kong 集群。缺点就是部署特别困难，另外在高可用方面，与 APISIX 相比也是相形见绌。
 *  Traefik ：基于 Golang 的 Ingress，它本身是一个微服务网关，在 Ingress 的场景应用比较多。他的主要平台基于 Golang，自身支持的协议也非常多，总体来说是没有什么缺点。如果大家熟悉 Golang 的话，也推荐一用。
 *  HAproxy：是一个久负盛名的负载均衡器。它主要优点是具有非常强大的负载均衡能力，其他方面并不占优势。
 *  Istio Ingress 和 Ambassador Ingress 都是基于非常流行的 Envoy。说实话，我认为这两个 Ingress 没有什么缺点，可能唯一的缺点是他们基于 Envoy 平台，如果大家对这个平台都不是很熟悉，上手门槛会比较高。

综上所述，大家在了解了各个 Ingress 的优劣势后，可以结合自身情况快速选择适合自己的 Ingress。

# 题外话 #

https://github.com/Miss-you/awesome-ingress

半夜睡不着，熬夜把之前整理的一张关于ingress功能对比的表格开源了。

这张表格其实是在2019年11-12月份我依据自己对一些用过的网关的经验以及基于Comparing Ingress controllers for Kubernetes这篇文章整理的（因为比如traefik/ambassador等网关，我也没有足够的时间来对从未接触过的这些Ingress做功能以及性能等方面的评估。

另一方面，开源社区的Ingress他们的发展速度非常快，我相信半年后，我的表格可能就跟不上潮流了。

最后也是因为当我发了这张图后，有很多同事或者开源社区的朋友私下找我索要这张表格，足以说明我整理的内容的价值。

所以，为了让大家在选型Ingress的路上少走弯路，为了该表格也能够持续更新，我将这张表格开源出来了，希望大家会喜欢。

[img-SwUl608G-1586938588443_http_km.oa.com_files_photos_pictures_20200219_1582092075_26.png]: /images/20230528/a090b9ae93e44d018663e55bfc185304.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70]: /images/20230528/59d564f772dd47ad9c5db7efd8c6ee72.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70 1]: /images/20230528/7ccd3719b7ec4618843d41663a06b2de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1NDM3NjY3_size_16_color_FFFFFF_t_70 2]: /images/20230528/513b1bae9dc141bfa360b591f7f8a8ff.png