kubernetes - 缩小 Kubernetes 中的视频会议软件

Question

我打算用 Kubernetes 部署一个 WebRTC 自定义视频会议软件（基于 NodeJS，使用 websockets），但我对缩小这个环境有些怀疑。

实际上，我计划使用云托管的 Kubernetes（GKE、EKS、AKS 或任何）来自动扩展集群中的节点以应对需求的增加和减少。但是，扩大规模不是问题，而是缩小规模。

据我了解，集群将根据集群中的一些 CPU 平均使用率指标进行缩减，如果它试图删除某个节点，它将开始耗尽连接并停止接收新连接，对吧？但是现在，想象一下这个“待删除”节点中仍在运行一个视频会议。有两个问题：

1 - 在视频会议结束之前停止节点（它将放弃会议）

2 - 随着开始缩减时的耗尽行为，它将停止接收新连接，所以如果有人试图加入这个正在运行的视频会议，它会收到超时，对吗？

那么，为视频会议解决方案缩减节点的最佳策略是什么？有任何想法吗？

谢谢

标签： kubernetesgoogle-kubernetes-engineazure-aksamazon-eks

Answer 1

我想说这不是通过某些特定的扩展策略在 Kubernetes 级别上解决它的问题，而是处理这种情况的应用程序能力。它甚至不是特定于 Kubernetes 的。想象一下，您将它直接部署在也受自动缩放影响的计算实例上，当负载减少并且其中一个实例从集合中删除时，您最终将处于完全相同的情况。

您应该问问自己，这样的应用程序是否适合部署为 Kubernetes 工作负载。我可以想象这样的视频会议会话不必仅依赖于部署在单个节点上的后端。您甚至可以定义一些亲和性或反亲和性规则，以防止您的 Pod 被调度在同一个节点上。因此，如果整个应用程序集群仍在运行（它的 Pod 运行在不同的节点上），则驱逐有限的 Pod 子集应该不会产生太大影响。

实际上，任何其他应用程序都可能面临同样的问题，因为它们中的绝大多数都基于需要在客户端软件和服务器部分之间建立的某些会话。我会说能够处理这种情况是应用程序的责任。如果某些用户意外断开连接，应该可以立即将他们重定向到正在运行的实例，例如仍然能够接受新请求的不同 Pod。

因此，基本上，如果应用程序被设计为高可用性，则扩展（当我们谈论水平扩展时，实际上是在谈论横向扩展时）底层虚拟机，或者更具体地说是 kubernetes 节点，不应该影响它的高可用性能力。另一方面，如果它不是为高可用而设计的，那么像 kubernetes 这样的解决方案可能不会有太大帮助。