浅谈Kubernetes Ingress控制器的技术选型

导语：在Kubernetes的实践、部署中，为了解决 Pod 迁移、Node Pod 端口、域名动态分配等问题，须要开发人员选择合适的 Ingress 解决方案。面对市场上众多Ingress产品，开发者该如何分辨它们的优缺点？又该如何结合自身的技术栈选择合适的技术方案呢？在本文中，腾讯云中间件核心研发工程师厉辉将为你介绍如何进行Kubernates Ingress 控制器的技术选型。（编辑：中间件小Q妹）

名词解释

阅读本文须要熟悉如下基本概念：

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

Kubernetes 访问现状

△ Kubernetes 的外部访问方式

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

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

• NodePort 的缺点是一个端口只能挂载一个 Service，并且为了更高的可用性，须要额外搭建一个负载均衡。
• LoadBalancer 的缺点则是每一个服务都必需要有一个本身的 IP，不管是内网 IP 或者外网 IP。更多状况下，为了保证 LoadBalancer 的能力，通常须要依赖于云服务商。

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

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 控制器选型的一些经验。

△ 选型原则

基本特色

首先我认为Ingress 控制器应该具有如下基本功能，若是连这些功能都没有，那彻底能够直接pass。

• 必须开源的，不开源的没法使用。
• Kubernetes 中 Pod 变化很是频繁，服务发现很是重要。
• 如今 HTTPS 已经很普及了，TLS 或者 SSL 的能力也很是重要，好比证书管理的功能。
• 支持 WebSocket 等常见协议，在某些状况下，可能还须要支持 HTTP2 、QUIC 等协议。

基础软件

前面有提到，每一个人擅长的技术平台不同，因此选择本身更加熟悉的 HTTP 网关也显得相当重要。好比 Nginx、HAProxy、Envoy 或者是 Golang 原生网关。由于你熟悉它的原理，在使用中能够实现快速落地。

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

功能需求

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

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

选择 APISIX 做为 Ingress controller

相比Kubernetes Ingress，我我的更推荐 APISIX。虽然它在功能上比 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。

Ingress controller 架构图

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

总结

各种 Ingress 横向对比

相对于市面上流行的 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，经过Kubernetes Ingress 配置即可完成同步状态至 Kong 集群。缺点就是部署特别困难，另外在高可用方面，与 APISIX 相比也是相形见绌。
• Traefik ：基于 Golang 的 Ingress，它自己是一个微服务网关，在 Ingress 的场景应用比较多。他的主要平台基于 Golang，自身支持的协议也很是多，整体来讲是没有什么缺点。若是你们熟悉 Golang 的话，也推荐一用。
• HAproxy：是一个久负盛名的负载均衡器。它主要优势是具备很是强大的负载均衡能力，其余方面并不占优点。
• Istio Ingress 和 Ambassador Ingress 都是基于很是流行的 Envoy。说实话，我认为这两个 Ingress 没有什么缺点，可能惟一的缺点是他们基于 Envoy 平台，你们对这个平台都不是很熟悉，上手门槛会比较高。

综上所述，你们在了解了各个 Ingress 的优劣势后，能够结合自身状况快速选择适合本身的 Ingress。

做者介绍

厉辉，腾讯云中间件API网关核心研发成员，Apache APISIX PPMC。热爱开源，乐于分享，活跃于Apache APISIX社区。

欢迎扫码关注咱们的微信公众号，期待与你相遇~