一文读懂 Kubernetes Ingress Controller 选型实践

Hello folks， 众所周知，Ingress 对于任何成功的 Kubernetes 集群部署拓扑架构都至关重要，尤其是在自建的容器云平台。 Ingress 允许我们在实际的业务场景中能够基于当前的网络环境定义外部（或内部）流量以及其如何路由至集群内的服务。

在 Kubernetes 官方文档中针对 I ngress 的 定义及定位：

“可以将 Ingress 配置为向服务提供外部可访问的 URL、负载均衡流量、终止 SSL / TLS 并提供基于名称的虚拟主机。”

然而，Ingress 本身并没有做任何事情——它们只是元数据。繁重的工作则由 Ingress Controller 即“ 入口控制器”执行，这也意味着缺少 Ingress Controller 的入口是无法完成任何事情。

当然，除此之外，我们还面临一个问题：虽然有许多系统控制器（如 ReplicaSet 控制器、端点控制器、命名空间控制器等）由 Kubernetes 控制平面管理，但 Ingress Controller 并 不会因容器集群的状态而自动存在。因此，我们需要在特定的环境中安装、配置和管理自己的 Ingress Controller 。

通常，在实际的业务环境中，在同一个集群中也可以存在多个 Ingress Controller 。我们可以基于 Ingress 类注释来划分路由空间，以便每个 Ingress 知道应该由哪个 Ingress Controller 来处理其流经的请求。最终还可能会针对同一集群中的不同业务场景使用 Ingress Controller 组合以实现业务架构需要。例如，在某一特定的场景中，可能存在一个入口控制器用于处理流经集群的外部流量，包括与 SSL 证书的绑定等等，而另一个没有 SSL 绑定的内部入口控制器则用来处理集群内流量。

截 至 目前 ， 基于不同的业务场景和技术架构， 业界活跃着多种风格的 Ingress Controller 可供选择。 Kubernetes 官方文档在也列出了常见的 Ingress 控制器，具体可参考链接 所示： https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/#additional-controllers

上述这些 Controller 往往 具有不同的功能集以及不同级别的社区、平台或商业支持。有些是 纯 粹的边缘路由器，而另一些则具有更类似于服务网格的功能特性。

Ingress Controller 选型要素分析

那么如何选择合适的 Ingress Controller（ 入口控制器）呢？在前期的技术规划以及选型时往往有几个重要的核心参考标准需要关注。在本文中，我不打算在特定的 Ingress Controller 类型 之间进行功能比较，毕竟，目前互联网上已经有很多相关文章对其进行直接比较，而且 Ingress Controller 种类也比较多 。相反，我将讨论在选择 Ingress Controller 时应该权衡哪些关键特性，以支撑现有的业务发展。

1、 流量协议

基于特定的业务场景，我们首先需要明确所定义的技术架构，以及基于架构所选取的技术框架。比如，我们是否需要路由 HTTP(S)、HTTP/2 还是 Websockets？技术实现是否支持路由 TCP/UDP 还是 gRPC？

在实际的业务场景中，并非所有 Ingress Controller 都支持所选这些协议，因此，我们需要定义并检查所选 取 的 Ingress Controller 支持哪些协议。 基于当前的 Ingress，无论是 Kubernetes Ingress、Nginx In g re ss、Kong Ingress、Traefik Ingress、APISIX Ingress 甚至 Ambassador Ingress，其基本的协议均得以支持，比如， HTTP(S)、HTTP/2、 TCP、UDP 以及 gRPC 等。故此，在满足基础的协议功能外，我们还需要依据实际的业务场景去对其他层面进行对比。

2、动态配置更新

是否存在这样一种场景：为使我们的业务能够持续性正常提供服务，往往 需要零停机时间的配置更新——通常，也称为“无中断重新加载”或“热加载”。

在实际的业务场景中，我们需要对某一组件进行配置更新，往往需要进行人工重启以使其生效，例如，传统的 Nginx 组件需要停机才能更新配置，而其他 Ingress Controller 则无需停机即可动态更新。例如，Traefik Ingress 。其动态配置由 Provider 自己提供，这里包含了定义系统如何处理请求的所有内容，此配置可以被无缝热加载，无需外界干预， 没有任何请求中断或连接损耗，以实现组件配置的自定义更新。

3、 可扩展性

在日常的项目维护过程中，我们是否需要在边缘进行速率限制、重试或断路器，或者是否有必要将此功能内置到我们的服务中？其实，在某些特定的场景中，一些 Ingress Controller 可 支持这些功能，这意味着我们不必自己投入过多的时间花费在编写代码之上。

除此之外，我们是否与外部托管的基于云的负载均衡器集成？ 确保所选择的 Ingress Controller 能够 与外部负载均衡器很好地集成，以减少我们的网络团队的工作和管理。

最后，也是至关重要的一项，我们所选用的 Ingress Controller 能否进行动态的二次开发以适应不同的协议、平台及环境诉求。

4、服务网格

Ingress Controller 可以配置为处理外部流量（源自集群外部的流量）、内部流量或两者兼而有之。如果我们需要观测或跟踪内部流量，可能需要一种特殊的入口控制器——服务网格。Kubernetes 通过 SMI 规范为服务网格提供互操作性标准。

基于实际的业务场景，我们如果确实需要服务网格，那么则需要确保为正确的工作选择正确的工具。毕竟， Ingress Controller 和 Service Mesh 两者不是相互排斥的。

5、API 网关

在实际的业务场景中，我们到底是需要 Ingress Controller 或 API 网关，还是两者兼而有之？ 这个是我们需要关注的地方。 就使用规范及用途而言，API 网关通常集成业务逻辑，而边缘路由器通常则与业务无关。 例如，API 网关能够帮助我们监控每个客户的流量，或衡量交易以进行计费。 如果我们需要边缘的业务逻辑，可能应该查看 API 网关而不是 Ingress 控制器。 就像服务网格一样，入口控制器和 API 网关并不是相互排斥的。

其实，在实际的技术选型或微服务上云容器化场景中，我们可以根据当前的系统架构进行适应性网络拓扑改造，可能在传统的网络拓扑架构中，我们的接入层和网关层隶属于不同的技术体系，选用不同的组件去实现。

然而，随着微服务架构的成熟化，传统的接入层和网关层可使用同一个云原生组件去实现，例如 Traefik 组件，其不仅支持接入层所具备的流量接入、路由转发功能，同时，基于其 Middleware 框架实现网关层相关功能，例如，访问控制、认证鉴权等。在某些特定的业务场景中，其不仅优化网络拓扑，而且能够做到一举双得之效。

6、 高可用性

当服务器因计划内或计划外维护而重新启动时，我们的业务能否承受停机以及停机时长？除此之外，随着业务量的增长，当前的接入层架构能否 扛 得住所涌入的流量请求而造成单点故障，导致业务受损？ 若基于此种场景，那么，我们需要为 Ingress 控制器提供高可用性，以满足其因外界导致的业务异常情况。

基于当前市面上所提供的解决方案，并非所有的 Ingress Controller 都支持高可用性。 因此，我们往往需要基于当前的数据中心需求建设而进行方案决策，以满足实际的业务要求。

7、负载均衡算法

Load Balancing 用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到 资源使用 最优化、 吞吐率 最大化、 响应 时间 最小化以及同时避免过载的目的。用于解决互联网架构中的高并发和高可用的问题。

对于负载均衡我们往往有多种选择，从传统的 Round-Robin 到非传统的 Rdp-Cookie 以及 Sticky Sessions（ 粘滞会话 ）在这里也很常见。 我们需要哪种基于算法的路由？ 大多数的 Ingress Controller 都支持循环，但如果我们想要最少的连接以考虑服务负载，那么将需要一个支持更高级负载均衡算法的 Ingress Controller 。

毕竟，负载均衡有时往往不能简单 地 通过请求的负载来作为负载均衡的唯一依据。 其需要结合服务的当前连接数量、最近响应时间等维度进行总体均衡，总而言之，就是为了达到资源使用的负载均衡，以获取最大的效益。

8、 发布策略

在我们所应用的容器云平台，我们是否需要执行金丝雀发布（将一定比例的流量转移到不同的服务以进行渐进式升级）？是否执行灰度发布、滚动发布？以及是否执行蓝绿发布？负载均衡允许分散服务的负载，但并非所有负载均衡器都可以使用更复杂的规则进行流量 拆分 。如果使用金丝雀测试等技术在生产环境中进行测试，那么我们则需要确保所选择的 Ingress Controller 能够 支持流量转移。

9、 技术支撑度

在进行技术选型过程中，我们往往需要问下自己、团队，需要其他企业、社区支持吗？我们是否有足够的能力去应付此组件所发生的潜在风险？毕竟，开源的 Ingress Controller 很容易部署实施及落地应用，然而，当我们面对未知的异常或错误以及当我们在后半夜需要技术支撑时会发生什么情况？自我研究？求助社区？当然，一些开源 Ingress 控制器也提供企业支持计划，我们可以基于此种服务进行技术求助，从而获得相关解决方案。

10、 生态拥抱性

最后一个便是生态成熟度，毕竟，随着技术的革新、周边衍生平台的崛起，我们所选择的组件，如 Ingress Controller 是否能够 在 Kubernetes 合作伙伴生态系统中得到进一步的支持与扩展，毕竟，任何产品都是有生命周期。

11、其他关联属性

除了上述核心特性外，一些关联属性也需要值得斟酌，就集群中的资源而言，我们所采用的技术框架是否对成本敏感？公司团队规模如何？是否有强大的技术团队去支撑？从本质而言， Ingress Controller 可能是资源密集型的，因此如果我们对成本比较敏感，那么使用轻量级的 Ingress Controller 或许 会更好。毕竟，一些 Ingress Controller 支持向上和向下扩展，而另一些则不支持。

针对资源监控层面而言， 我 们 是否需要与现有的指标和日志收集系统集成？ 一些 Ingress Controller 提供有限的监控和日志记录，可能不支持当前系统架构所选用的特定监控和日志记录工具。除此之外，针对路由匹配、全链路追踪也需要应给予合理的决策。

结论

如上述所述，在为容器集群选择正确的 Ingress Controller 之前，往往需要考虑诸多因素。不能仅选择一个以“炒作驱动”为聚焦点的流行选项，毕竟，所有的选型都是为业务服务，故此，我们需要仔细斟酌我们的业务诉求，然后根据上面列出的参考标准进行评估。若基于此种规范或标准，我们则能够将对基础架构的一个清晰的认识以及对核心环节做出明智的决策。

对于大规模部署微服务架构的企业来说，强大的网络解决方案是必不可少的。无论是传统的 F5 厂商，还是国内外各大容器云厂商，其均能够提供基于各自平台的 Ingress Controller 组件。

Traefik Enterprise 将 API 管理、入口控制和服务网格组合在一个简单的控制平面中。它与生态系统无关、高度可用、高度自动化，并提供专门的技术支持。因此，如果大家正在评估 Ingress Controller 的话，不妨可以尝试一下 Traefik Ingress 。