博客

入口控制器: 新名称,熟悉功能

Lori MacVittie 缩略图
洛里·麦克维蒂
2017 年 8 月 10 日发布

口语化。 这些单词和短语具有独特的当地含义,可能会使非本地人感到困惑。 例如,当我外出并且感到口渴时,我会寻找一个起泡器。 您可能(猜测您不是“Sconnie”)正在寻找喷泉。 在威斯康星州,我们以时间来测量距离,而不是英里。 交通信号灯是“停停走走”灯。 因为,这就是你要做的。

我的丈夫(他不是本地人)最喜欢笑的一句话是“过来一次”。 我不会尝试向我和用它的孩子解释超出范围的事情。 我们本能地明白,“北上”不是一个方向,而是一个地方,它的位置可能特定于说话者,但却带有每个威斯康星州本地人共同的内涵,描述“我们去逃避一切的地方”。

你可能也有自己的清单,因为你是在其他地方长大的。 但这是我的博客,所以我可以使用我的博客。

然而,今天的重点并不是语义学本身的课程,而是关于它对你家后院的更本地化的现象的适用性。 至少如果你的后院是你的组织的话。

容器及其十分必要的自动化集群控制系统(通常称为编排)的兴起带来了意想不到的后果,迫使口语从州界的一端转移到了另一端。 顺便说一句,这就是应用程序开发真正意义上的 IT 工作。

集装箱俗语的奇怪案例

实现所需的灵活性和可靠性所需的许多功能意味着将某些以前仅用于生产的服务迁移到容器“环境”中。 这些功能现在表面上已经“融入”到该环境中,使用轻量级集成(API 和消息队列)实现了迄今为止只能从完全实现的云计算环境中实现的功能:自动扩展、高可用性应用。

新直流平衡

在这样做时,负载均衡功能通过小型、类似守护进程的服务原生于 pod/节点。 虽然它们不是非常先进(我们所说的只是略高于网络负载均衡能力),但它们完成了它们设计的任务。 如果你愿意的话,这些服务可以是(而且是)可插入的,从而启用其他项目(开源和供应商提供),以解锁更高级的功能(并且希望是算法)。

但就其本身而言,这些负载均衡功能无法实现我们最终寻求的(以及在生产环境中需要的)规模和高可用性。 它们也无法路由 API——这需要 HTTP(L7)智能。 如果我们要高效扩展由微服务支持并以 API 外观为前端的现代应用,就需要这样做。 我们需要一个更强大的解决方案。

这就是入口控制器发挥作用的地方。 这些是“负载均衡器”,它们根据 URI 和 HTTP 标头剖析和引导入口流量,以实现应用层路由和可扩展性。

发生的情况是,创建(并随后使用)入口控制器的开发人员基本上重新创建了我们(在网络运营中)所称的流量管理、应用交付或内容交换/路由。 多年来,我们在 netops 中使用了很多不同的术语,在 dev(ops) 中也是如此。 应用程序路由和页面路由也是开发人员用来描述 L7 路由的术语。 这一概念对于这两个群体来说都不陌生。 但术语 — — 口语 — — 是。

入口控制器的任务是将请求路由到容器集群内的适当(虚拟)服务。 该服务可能是另一个负载均衡代理,也可能是容器系统特定的构造。 无论哪种情况,入口控制器的作用都是根据 HTTP 请求的 HTTP 标头内的第 7 层 (HTTP) 值来路由流量。 通常这是 URI,但它可以是主机名,也可以是其他自定义值(如版本号或 API 密钥)。

一旦入口控制器从标头中提取了值,它就会使用资源文件描述的策略来确定如何分发它。 它可以平均分配,或者将 75% 发送给一个版本的服务,将 25% 发送给另一个版本。 这样就非常灵活了。 入口控制器还具有监控(健康和状态)职责,并且需要非常小心,不要将请求分发给“死”服务。

听起来很熟悉,网络操作员? 应该如此,因为这基本上是智能(L7 功能)代理(如 BIG-IP)的功能。

现在您知道它们有何相同之处,让我向您保证它们之间还是存在一些差异的。 值得注意的是,入口控制器是声明式配置的。 也就是说,它的配置是由控制器本身之外的资源文件中的描述决定的。 这与控制和引导入口流量的传统智能代理不同。 传统的智能代理是环境的权威来源。 入口控制器不是。 它在其他地方寻找充当某种“抽象层”的文件,以便在实现上具有灵活性。 这意味着它(或补充组件)必须读取它、解释它并创建适合该描述的配置。 并且它必须保持最新状态。 虽然容器环境入口控制的变化小于系统深处的变化,但它仍然会发生变化,必须引起注意。

当一切都完成后,入口控制器负责将来自外​​部的请求应用层路由到容器环境内的适当资源。 这几乎就是智能负载均衡器的定义。

名称可能已改变,但功能仍然基本相同。