我们正在考虑使用具有以下独特功能的 GKE 网络服务:
> < li>
每次会话都需要客户端上传大量数据,这些数据经过预处理并存储在Pod的内存中-每次会话大约1GB到5GB。出于性能原因,我们认为在Pod中简单地在内存中维护会话是有意义的,而不是像Reddis一样拥有一个共享的DB(即,Pod不是无状态的——因此标题中提到了粘性会话)。这样,当客户端发出下一个请求,试图用它们的数据进行另一个繁重的计算时,它就可以处理这个请求并返回结果,而不需要从Reddis这样的外部源重新生成内存繁重状态。
每个Pod需要整个VM的资源(例如4vCPU 32GB,附加1个GPU),因为它为每个连接的会话提供的服务涉及GPU/CPU使用的短突发(即水平扩容每次都需要新的NODES,而不是单个节点上的额外Pod)。这个想法是Pod可以支持的会话数量仅受节点上内存的限制(因为实际处理将在短突发中发生,如前所述)。
似乎GKE自动扩展开箱即用,目标内存使用量约为50%,对于这些重载会话来说效果很好,但这是我的担忧:
GKE似乎很适合无状态服务,但对于像我们这样的每一个会话都需要大量内存的服务,将状态卸载到外部存储库(如Reddis)并为每个后续请求重新加载将导致显著的性能损失,我不太确定它是否能正常工作。。。但如果我能够解决上述问题,这样我就可以确信GKE将确保新的会话路由到内存使用率较低的节点,并且GKE不会杀死具有活动会话的节点(是的,会话会超时,因此它们不会永远保持节点活动),那么我认为这可能非常合适。
我也很乐意接受其他建议,我是Kubernetes的新手,至少可以说这个黑匣子很吓人!
编辑(关于应用程序的更多细节以了解更多上下文):我们目前的想法是让每个Pod运行一个python web应用程序,该应用程序充当生成子流程的监管程序,这些子流程实际上完成繁重的工作,每个粘性会话一个子流程。然后,似乎只是将请求从客户端路由到它们各自的子流程,以进行繁重的处理,并将结果返回给客户端。只要会话还存在,子流程就会一直存在(当然有超时)。这里的关键问题似乎是,这些子进程/会话中的每一个都需要1-5GB的内存,因此出于性能原因(不仅仅是带宽问题,还包括重新生成状态),将它传递给外部资源似乎不是一个好主意,因此我们认为最好将状态保存在pod本身的子进程/会话中,然后依靠GKE的水平扩展来按需添加必要的内存资源...假设我们能解决我提到的两个问题。
要在GKE上配置Ingress对象,集群必须配置为VPC Native集群,您可以使用BackendConfig设置与客户端IP或生成的cookie的会话关联。GKE中的会话亲和性以尽力而为的方式运行,以将请求传递到为初始请求提供服务的同一后端。默认情况下,平衡模式会确定后端何时达到容量,如果您想使用外部HTTPS负载平衡器,建议的平衡模式为RATE。您提到的示例类似于“利用”,不建议使用“会话相关性”。这是因为实例利用率的变化会导致负载平衡服务将新请求或连接定向到未满的后端VM。
关于Autoscaler,GKE提供了ClusterAutoscaler来根据工作负载的需求自动调整GKE集群的节点池大小。当需求较高时,集群自动缩放器会将节点添加到节点池中。当需求较低时,集群自动缩放器会缩小到您指定的最小大小。此外,还有一个结合了垂直和水平自动缩放的新功能,称为多维荚自动缩放,该功能仍在测试版中。多维PodAutoscaler对象修改内存请求并添加副本,以便每个副本的平均CPU利用率与目标利用率相匹配