路由概述

为什么需要Ingress

Service基于TCP和UDP协议进行访问转发，为集群提供了四层负载均衡的能力。但是在实际场景中，Service无法满足应用层中存在着大量的HTTP/HTTPS访问需求。因此，Kubernetes集群提供了另一种基于HTTP协议的访问方式——Ingress。

Ingress是Kubernetes集群中一种独立的资源，制定了集群外部访问流量的转发规则。如图1所示，用户可根据域名和路径对转发规则进行自定义，完成对访问流量的细粒度划分。

图1 Ingress示意图

Ingress简介

在Kubernetes中，Ingress资源本身是一个抽象的概念，实际的流量处理是由Ingress Controller来完成的。

• Ingress资源：一组基于域名或路径把请求转发到指定Service实例的访问规则，是Kubernetes的一种资源对象，通过接口服务实现增、删、改、查的操作。
• Ingress Controller：请求转发的执行器，用以实时监控资源对象Ingress、Service、Endpoint、Secret（主要是TLS证书和Key）、Node、ConfigMap的变化，解析Ingress定义的规则并负责将请求转发到相应的后端Service。
  Ingress Controller在不同厂商之间的实现方式不同，CCE支持ELB型和Nginx型两种Ingress Controller类型：

  • ELB Ingress Controller部署在master节点，基于弹性负载均衡服务（ELB）实现流量转发，所有策略配置和转发行为均在ELB侧完成。
  • Nginx Ingress Controller使用Kubernetes社区维护的模板与镜像部署在集群内部，并通过NodePort对外提供访问，外部流量经过Nginx组件转发到集群内其他业务，流量转发行为及转发对象均在集群内部。

Ingress特性对比

由于ELB Ingress和社区开源的Nginx Ingress在原理上存在本质区别，因此支持的Service类型不同，详情请参见ELB Ingress支持的Service类型。

ELB Ingress Controller部署在master节点，所有策略配置和转发行为均在ELB侧完成。非ELB直通Pod场景下，集群外部的ELB只能通过VPC的IP对接集群内部节点，因此ELB Ingress只支持NodePort类型的Service。但是ELB直通Pod场景（CCE Turbo集群 + 独享型ELB实例）下，ELB可直接将流量转发到集群内Pod，此时Ingress仅支持对接ClusterIP类型的Service。

Nginx Ingress Controller运行在集群中，作为服务通过NodePort对外暴露，流量经过Nginx-ingress转发到集群内其他业务，流量转发行为及转发对象均在集群内部，因此支持ClusterIP和NodePort类型的Service。

综上，ELB Ingress使用企业级LB进行流量转发，拥有高性能和高稳定性的优点，而Nginx Ingress Controller部署在集群节点上，牺牲了一定的集群资源但可配置性相对更好。

ELB Ingress Controller工作原理

CCE自研的ELB Ingress Controller基于弹性负载均衡服务ELB实现公网和内网（同一VPC内）的七层网络访问，通过不同的路径将访问流量分发到对应的服务。

ELB Ingress Controller部署于Master节点上，与集群所在VPC下的弹性负载均衡器绑定，支持在同一个ELB实例（同一IP）下进行不同域名、端口和转发策略的设置。ELB Ingress Controller的工作原理如下：

1. 用户创建Ingress资源，在Ingress中配置流量访问规则，包括负载均衡器、访问路径、SSL以及访问的后端Service端口等。
2. Ingress Controller监听到Ingress资源发生变化时，就会根据其中定义的流量访问规则，在ELB侧重新配置监听器以及后端服务器路由。
3. 当用户进行访问时，流量根据ELB中配置的转发策略转发到关联的各个工作负载。

ELB Ingress Controller的工作原理和集群类型及ELB类型有关，不同场景的配置流程及网络流向如下所示：

Nginx Ingress Controller工作原理

Nginx型的Ingress使用弹性负载均衡（ELB）作为流量入口，并在集群中部署NGINX Ingress控制器来对流量进行负载均衡及访问控制。

NGINX Ingress控制器插件使用开源社区的模板与镜像，使用过程中可能存在缺陷，CCE会定期同步社区版本来修复已知漏洞。请评估是否满足您的业务场景要求。

Nginx型的Ingress Controller通过pod部署在工作节点上，因此引入了相应的运维成本和Nginx组件运行成本，其工作原理如图5，实现步骤如下：

1. 当用户更新Ingress资源后，Ingress Controller就会将其中定义的转发规则写入到Nginx的配置文件（nginx.conf）中。
2. 内置的Nginx组件进行reload，加载更新后的配置文件，完成Nginx转发规则的修改和更新。
3. 在流量访问集群时，首先被已创建的负载均衡实例转发到集群内部的Nginx组件，然后Nginx组件再根据转发规则将其转发至对应的各个工作负载。

图5 Nginx Ingress Controller工作原理

Ingress支持的Service类型

由于ELB Ingress和社区开源的Nginx Ingress的实现原理不同，因此支持的Service类型不同。