混合 PoolManager/NewDeploy 执行策略的可行性

经过对 Fission 的执行策略 (PoolManager 与 NewDeploy) 的分析后,我们已经确定了众所周知的权衡: - **PoolManager**: 通过重用热容器,提供出色的冷启动性能(专化时间小于 100 毫秒),但缺乏针对每个函数的资源调整(CPU/内存限制/请求在环境层面设置),并且不使用标准 HPA 来根据指标进行精细的、针对每个函数的扩展。 - **NewDeploy**: 提供标准的 Kubernetes 资源限制/请求,以及基于 HPA 的自动扩展(包括缩放到零),但需要全面的 Kubernetes pod 冷启动延迟,可能会明显延长。 - 理想情况下,我们希望将两种方法的优点结合在一起,为单个函数实现低延迟的冷启动,同时利用 NewDeploy 的高效、针对每个函数的扩展和资源管理,以持续负载。 **建议的混合行为**: 对于单个 Fission 函数,一个潜在的混合执行模型可以如下操作: 1. **初始调用(冷启动)**: 对空闲函数的第一个请求被路由到 PoolManager。从适当的环境池中快速专化一个空闲容器,提供低于 100 毫秒的响应时间,从而消除了冷启动问题。 2. **持续负载/扩展**: 随着负载增加,初始专化的容器(或可能是在第一次请求后)的容量超出了 Fission 的扩展范围,函数将转向使用专用 pod 进行扩展,类似于 NewDeploy 模型。这些专用 pod 将: - 具有针对每个函数的特定资源请求/限制。 - 由标准的 Kubernetes HPA 管理,以基于 CPU/内存/自定义指标的高效扩展。 - 可能在负载减弱时缩小到零。 **动机/优势**: 这种混合方法旨在提供"两全其美": - 最小的冷启动延迟: 利用 PoolManager 的核心优势来处理初始请求。 - 高效的资源使用: 允许针对扩展实例根据函数进行精细调整 CPU/Memory 请求和限制。 - 精细的自动扩展: 使用标准 HPA 根据单个函数负载进行可预测的扩展(类似于 NewDeploy)。 - 更好的隔离: 扩展实例的专用 pod 减少了共享池中固有的"噪声邻居"问题。 参考现有想法: 我遇到了以下文本(与较旧的问题/讨论有关): > 混合方法也可能可行: 函数的第一个实例可以从池中提取(以使冷启动快速),而后续实例则可以在新 pod 中创建(以使自动扩展更容易)。这种实现的起源已经存在于自动扩展分支中。 这表明此概念之前已经被考虑过,并且可能已经实现了原型。 问题: - Fission 是否目前支持这种混合执行策略,即使是实验性的或通过功能标志? - 如果不是,那么将这种混合执行策略技术上是否可行? 如何将其应用于 Fission?