在Kubernetes的实践和部署中，为了解决Pod迁移、NodePod端口、域名动态分配等问题，开发者需要选择合适的Ingress方案。面对市面上众多的Ingress产品，开发者应该如何区分它们的优缺点呢？又该如何根据自己的技术栈选择合适的技术方案呢？在本文中，腾讯云中间件核心研发工程师李辉将为大家介绍如何对KubernetesIngresscontroller进行技术选型。术语解释阅读本文需要熟悉以下基本概念：集群：指容器运行所需的云资源集合，包括若干个云服务器、负载均衡器等云资源。实例（Pod）：一个实例由一个或多个相关的容器组成，这些容器共享相同的存储和网络空间。Workload（Node）：Kubernetes资源对象，用于管理Pod副本整个生命周期的创建、调度和自动控制。服务（Service）：由多个相同配置的实例（Pod）和访问这些实例（Pod）的规则组成的微服务。入口：入口是用于将外部HTTP(S)流量路由到服务的规则集合。Kubernetes访问状态Kubernetes的外部访问方式在Kubernetes中，services和PodIPs主要用于访问集群内的服务，对于集群外的应用程序是不可见的。如何解决这个问题呢？为了让外部应用访问Kubernetes集群中的服务，通常的解决方案是NodePort和LoadBalancer。这两种方案其实都有一些缺点：NodePort的缺点是一个端口只能挂载一个Service，为了更高的可用性，需要额外搭建一个负载均衡器。LoadBalancer的缺点是每个服务都必须有自己的IP，不管是内网IP还是外网IP。更多情况下，为了保证LoadBalancer的能力，一般需要依赖云服务商。在Kubernetes的实践和部署中，为了解决Pod迁移、NodePod端口、域名动态分配、或者Pod后台地址动态更新等问题，Ingress解决NginxIngress缺点Ingress在Kubernetes中非常重要的外网流量入口.Kubernetes推荐的默认值为NginxIngress。为了区别于后面Nginx提供的商业版Ingress，我称之为KubernetesIngress。顾名思义，KubernetesIngress基于Nginx平台。Nginx现在是世界上最流行的NginxHTTP服务器。Nginx相信大家都不陌生，这是一个优势。它还有一个好处是NginxIngress连接到Kubernetes集群需要的配置非常少，而且有很多文档可以指导你如何使用它。对于大多数刚接触Kubernetes或者创业公司的人来说，NginxIngress确实是一个非常不错的选择。但是在一些大型环境中使用NginxIngress时，会出现很多问题：第一个问题：NginxIngress使用了一些OpenResty的特性，但是最终的配置加载还是依赖于原来的Nginxconfigreload。当路由配置非常大时，Nginxreload时间会很长，只要几秒甚至十几秒，会严重影响业务，甚至导致业务中断。第二个问题：NginxIngress的插件开发非常困难。如果觉得NginxIngress插件本身不够用，需要使用一些自定义插件，这种额外的开发工作对于程序员来说是非常痛苦的。因为NginxIngress本身的插件能力和扩展性很差。Ingress选择原则既然NginxIngress存在诸多问题，是否考虑选择其他开源更好的Ingress？市面上比KubernetesIngress好用的Ingress起码有十几种，那么这么多Ingress如何选择呢？如何选择适合自己的？Ingress本身基于HTTP网关。市面上的HTTP网关主要有几种：Nginx、Golang的原生网关，以及新出现的Envoy。但是每个开发者擅长的技术栈不一样，所以适合的Ingress也会不一样。那么问题来了，我们如何选择比较好用的Ingress呢？或者缩小范围，熟悉Nginx或OpenResty的开发者应该选择哪个Ingress？下面介绍一下我选择Ingress控制器的一些经验。选型原则1.基本特性首先，我认为Ingresscontroller应该具备以下基本功能。如果你连这些功能都没有，可以直接传过去。必须是开源的，不开源就不能用。Kubernetes中的Pod变化非常频繁，服务发现非常重要。现在HTTPS很流行，TLS或者SSL的能力也很重要，比如证书管理的功能。支持WebSocket等常用协议，在某些情况下可能还需要支持HTTP2、QUIC等协议。2.基础软件前面说了，每个人擅长的技术平台不同，所以选择自己比较熟悉的HTTP网关也很重要。例如Nginx、HAProxy、Envoy或Golang原生网关。因为熟悉它的原理，所以在使用中可以实现快速落地。在生产环境中，高性能是一个非常重要的特性，但比这更重要的是高可用性。这意味着您选择的网关必须具有非常强的可用性和稳定性。只有这样，服务才能稳定。3、功能需求除了以上两点，就是公司业务对网关的特殊需求。如果选择开源产品，最好开箱即用。比如你需要GRPC协议的转换能力，那么你当然希望选择的网关有这样的功能。以下是影响选择的因素的简要列表：协议：是否支持HTTP2和HTTP3；负载均衡算法：最基本的WRR和一致性hash负载均衡算法是否可以满足要求，或者需要像EWMA这样更复杂的负载均衡算法。认证权限流程：只需要简单的认证，或者需要更高级的认证方式。或者像腾讯云IM一样需要集成快速开发一个认证功能。KubernetesIngress除了上面提到的耗时较长的Nginxreload和插件扩展能力差之外，还存在后端节点权重调整能力不够灵活的问题。选择APISIX相比KubernetesIngress，我个人更推荐APISIX作为Ingresscontroller。虽然它的功能比Kong少很多，但APISIX良好的路由能力、灵活的插件能力和高性能可以弥补Ingress选型上的一些不足。对于基于Nginx或者Openresty的程序员，如果你对现在的Ingress不满意，我推荐你使用API??SIX作为Ingress。如何使用APISIX作为Ingress？我们首先要区分一下。Ingress是Kubernetes名称或规则定义的定义，Ingress控制器是将Kubernetes集群的状态同步到网关的组件。但APISIX本身只是一个API网关。如何将APISIX实现为Ingress控制器？我们先简单了解一下Ingress是如何实现的。Ingress的实现，本质上只有两部分：第1部分：需要将Kubernetes集群中的配置或者Kubernetes集群中的状态同步到APISIX集群中。第二部分：APISIX中的一些概念，比如services、upstream等，需要在Kubernetes中定义为CRD。如果实现第二部分，可以通过KubernetesIngress的配置快速生成APISIX。APISIX相关的配置可以通过APISIXIngresscontroller生成。目前，为了快速将APISIX实现为可以支持Kubernetes的Ingress，我们创建了一个名为IngressController的开源项目。Ingresscontroller架构图上图是Ingresscontroller项目的整体架构图。左边部分是Kubernetes集群，这里可以导入一些yaml文件来改变Kubernetes的配置。右侧部分是APISIX集群及其控制平面和数据平面。从架构图中可以看出，APISIXIngress充当了Kubernetes集群和APISIX集群之间的连接器。主要负责监控Kubernetes集群中节点的变化，将集群状态同步到APISIX集群。另外，由于Kubernetes提倡所有的组件都应该是高可用的，所以在APISIXIngress的设计之初，我们就采用了双节点或者多节点的方式来保证APISIXIngressController的高可用。总结各种Ingress的横向对比对比市面上流行的Ingress控制器，我们来做一个简单的对比，看看APISIXingress有哪些优缺点。上图是国外开发者为KubernetesIngress选型做的表格。在原有表的基础上，结合自己的理解，增加了APISIXIngress函数。我们可以看到最左边的是APISIX，后面是KubernetesIngress和KongIngress，Traefik后面是基于Golang的Ingress。HAproxy比较常见，曾经是比较流行的负载均衡器。Istio和Ambassador是国外非常流行的两个Ingress。接下来我们总结一下这几种Ingress的优缺点：APISIXIngress：APISIXIngress的优点上面也有提到。具有非常强大的路由能力，灵活的插件扩展能力，以及优秀的性能。同时，它的缺点也非常明显。APISIX开源后虽然有很多功能，但是缺乏实际案例和相关文档来指导大家如何使用这些功能。KubernetesIngress：Kubernetes默认推荐的NginxIngress。它的主要优点是简单易用。缺点是根本无法解决Nginxreload时间长的问题。另外，虽然可用的插件很多，但是插件的扩展能力很弱。NginxIngress：主要优点是全面支持TCP和UDP协议，但缺少认证方式、流量调度等功能。Kong：本身就是一个API网关，也是先行者，把API网关作为Ingress引入到Kubernetes中。此外，与边缘网关相比，Kong在鉴权、限流、灰度部署等方面都做得非常好。KongIngress还有一个很大的优势：它提供了一些API和服务定义，可以抽象成KubernetesCRD，通过K8SIngress配置完成状态到Kong集群的同步。缺点是部署特别困难，在高可用方面，与APISIX相比也是相形见绌。Traefik：基于Golang的Ingress，本身就是一个微服务网关，在Ingress场景中被广泛使用。其主要平台基于Golang，支持多种协议。总的来说，没有缺点。如果熟悉Golang，也推荐使用。HAproxy：是一个著名的负载均衡器。它的主要优点是有非常强大的负载均衡能力，其他方面不占优势。IstioIngress和AmbassadorIngress都是基于非常流行的Envoy。说实话，我不觉得这两款Ingress有什么缺点。唯一可能的缺点是它们基于Envoy平台。大家对这个平台不是很熟悉，入门门槛会比较高。综上所述，当你了解了各个Ingress的优缺点后，就可以根据自己的情况快速选择适合自己的Ingress了。
