Knative 的 Mixer 适配器
演示了一个 Mixer 进程外适配器,它实现了 Knative 的从零扩展逻辑。
这篇文章演示了如何使用 Mixer 将应用程序逻辑推送到 Istio 中。它描述了一个 Mixer 适配器,该适配器使用简单的代码和与原始实现类似的性能实现了 Knative 的从零扩展逻辑。
Knative Serving
Knative Serving 基于 Kubernetes 支持部署和服务无服务器应用程序。无服务器平台的核心功能之一是缩放到零功能,该功能可减少非活动工作负载的资源使用和成本。当空闲应用程序收到新请求时,需要一种新机制来从零扩展。
下图显示了当前 Knative 用于从零扩展的架构。
通过使用 VirtualServices
和 DestinationRules
对 Istio 进行编程,将空闲应用程序的流量重定向到 Activator 组件。当 Activator 接收到新请求时,它会
- 缓冲传入请求
- 触发 Autoscaler
- 在应用程序扩展后将请求重定向到应用程序,包括重试和负载均衡(如果需要)
应用程序再次启动并运行后,Knative 会将路由从 Activator 恢复到正在运行的应用程序。
Mixer 适配器
Mixer 在 Istio 组件和基础设施后端之间提供了一个丰富的中间层。它被设计为一个独立组件,与 Envoy 分开,并具有简单的扩展模型,使 Istio 能够与各种后端互操作。Mixer 本身比 Envoy 更易于扩展。
Mixer 是一个属性处理引擎,它使用操作员提供的配置将 Istio 代理中的请求属性映射到对基础设施后端系统的调用,并通过一组可插拔的适配器进行。适配器使 Mixer 能够公开一个单一的、一致的 API,而独立于所使用的基础设施后端。运行时使用的适配器确切集合是通过操作员配置确定的,并且可以轻松扩展以针对新的或自定义的基础设施后端。
为了实现 Knative 的从零扩展,我们使用 Mixer 进程外适配器 来调用 Autoscaler。Mixer 的进程外适配器允许开发人员使用任何编程语言,并将扩展程序构建和维护为独立程序,而无需构建 Istio 代理。
下图显示了使用 Mixer 适配器的 Knative 设计。
在此设计中,无需像原始 Knative 设置那样更改空闲应用程序的路由到/从 Activator。当由入口网关组件表示的 Istio 代理接收到对空闲应用程序的新请求时,它会通知 Mixer,包括所有相关的元数据信息。然后,Mixer 调用您的适配器,该适配器使用原始 Knative 协议触发 Knative Autoscaler。
Istio 使用 Mixer 适配器,可以将原本复杂的基于网络的应用程序逻辑替换为更简单的实现,如 Knative 适配器 中所示。
当适配器从 Mixer 接收到消息时,它会使用 Knative 协议直接向 Autoscaler 组件发送 StatMessage
。Autoscaler 所需的元数据信息(命名空间
和服务名称
)由 Istio 代理传输到 Mixer,然后从那里传输到适配器。
总结
我将原始 Knative 参考架构的冷启动时间与新的 Istio Mixer 适配器参考架构进行了比较。结果表明冷启动时间相似。使用 Mixer 适配器的实现具有更高的简单性。无需处理低级基于网络的机制,因为这些机制由 Envoy 处理。
下一步是将此 Mixer 适配器转换为在入口网关内运行的 Envoy 特定过滤器。这将进一步减少延迟开销(不再需要调用 Mixer 和适配器),并消除对 Istio Mixer 的依赖。