Ingress 不仅可以让外部客户端访问服务，还可以自定义服务的访问策略。在前面介绍的 LoadBalancer Service 中，我们知道每一个服务都需要定义一个负载均衡器和唯一的共有 IP 地址，如果一个应用可以提供多种服务，那么显然这种方式是不够友好的。而 Ingress 只需要一个公网 IP 地址就可以为多个服务提供自定义的访问。因此，Ingress 是一种非常灵活、得到越来越多厂商支持的集群服务暴露方式，在实际的生产环境中使用得最多，而其他的服务暴露方式更多地适用于服务调试、特殊应用部署等方面。 #### 2.1 Ingress 和 Ingress Controller 在 kubernetes 集群中，Ingress 只是一个统称，具体而言由两部分组成： * `Ingress`：Ingress 资源对象，使用 YAML 文件定义负载均衡的策略（规则） * `Ingress Controller`：控制器，以插件形式存在于集群中，从 apiServer 中获取 Ingress 的规则变化 在集群中，需要先部署 Ingress Controller，再创建 Ingress 资源对象。Ingress Controller 控制器是一个 docker 容器，容器镜像中包含一个负载均衡器（比如：Nginx 或是 HAProxy）和一个 Ingress Controller。 整个底层的实现是这样的：Ingress Controller 从 kubernetes apiServer 中（实际上是监控 apiServer 的 /ingress 接口后端的 backend services）获取 Ingress 的配置信息，然后动态生成一个 Nginx 或 HAProxy 配置文件，重启负载均衡器进程使配置生效。所以，虽然 Ingress Controller 是以插件形式集成在环境中，但依然是由 kubernetes 管理的负载均衡器。 Ingress Controller 容器中的负载均衡器可以是各种主流的负载均衡软件，比如：Nginx、HAProxy、Traefik 等。不管具体的软件类型是什么，官方都统称为 Ingress Controller。 #### 2.2 原理图 当集群使用 Ingress 进行负载分发时，Ingress Controller 基于 Ingress 规则将客户端请求直接转发到 Service 对应的后端 Endpoint(Pod) 上，所以会跳过 kube-proxy 的转发功能，kube-proxy 在这里并不会起作用。这种方式比 LoadBalancer 更加高效。 比如下面的例子：  当客户端访问实验楼（[www.lanqiao.cn）时：](http://www.lanqiao.xn--cn%29:-x99h/) * 访问[https://www.lanqiao.cn/courses](https://www.lanqiao.cn/courses)的请求会被路由到后端名为 courses 的 Service； * 访问[https://www.lanqiao.cn/louplus](https://www.lanqiao.cn/louplus)的请求会被路由到后端名为 louplus 的 Service； * 访问[https://www.lanqiao.cn/vip](https://www.lanqiao.cn/vip)的请求会被路由到后端名为 vip 的 Service； 使用 Ingress 不仅可以实现对 HTTP 的路由，还可以实现基于 cookie 的会话亲和性、SSL 直通/终止等功能。