[翻译]为Kubernetes创建自定义Pod水平扩展器

原文链接:Building your own horizontal pod autoscaler for Kubernetes

当前版本(1.3)的Kubernetes为在生产环境中平滑运行容器化应用提供了大量开箱即用的特性。不过一些特性依然不够完善,比如Pod水平扩展器(Horizontal pod autoscaler, HPA)。现在你只能根据CPU和内存使用水平进行扩容调度,自定义指标的调度目前仅在Alpha版本中支持。

我们其中一个应用是一个Websocket服务器,用来处理来自客户端的长连接。然而性能测试显示我们的应用最大可以承载大约25000个Websocket活跃连接,更多的连接数会导致服务器不稳定甚至崩溃,然而这时通常不会引起CPU负载的升高和内存开销的增长。所以让Kubernetes根据Websocket连接数进行扩展调度的需求应运而生。本文介绍了我们创建自定义水平扩展器(HPA)的一些实践。

Kubernetes原生HPA如何工作

参考Kubernates的源码我们发现,原生扩展器的实现其实非常简单(参见computeReplicasForCPUUtilization()):

  1. 计算所有Pod的CPU使用率;
  2. 根据targetUtilization计算Pod的需求量;
  3. 按照计算出的Pod数量进行扩容。

所以我们打算做一个更强大的扩展器。按照需求,自定义扩展器应当满足下面的目标:

  • 当前负载下不崩溃,即使达到了当前负载能力;
  • 快速扩容,必要时超限扩容;
  • 应当为新扩容的容器实例预留启动时间;
  • 逐渐缩容,防止缩容低于系统的承载能力。

确保应用不崩溃

为了防止应用崩溃,我们实现了ReadinessProbe,当Pod达到连接数上限时,将其标记为NotReady,这样Kubernetes的负载均衡器将不会为其发送新的流量。一旦连接数低于连接数上限时,将其重新标记为Ready,Kubernates负载均衡器将继续为其发送流量。这个过程应当和容器扩容一起进行,否则新流量到达负载均衡器时,如果池中Pod不足将导致流量无法正确地被处理。

快速扩容

扩容时我们应当确保扩容容量能够处理新增的连接,因此扩容应当快速进行,必要时应该超限扩容。由于应用需要启动时间,所以我们必须预先判断扩容完成后可以承载的负载量。我们需要获取websocketConnectionCount的历史值。

开始我们设计了一个根据最近5个websocketConnectionCount值进行线性拟合预判的模型,不过在连接数以指数型增长或减少时这不是最优的。后来我们使用了regression库进行二度多项式回归来寻找一个反映connectionCount变化规律的方程,并找到预判值。

k8s-custom-hpa-scaling-up

点线是预测负载

逐渐缩容

缩容时我们并不按照预测值,因为预测可能会导致缩减到当前负载下仍需要的Pod。由于断开连接后Websocket会重连,所以对于缩容我们宽松留有余量。我们发现多项式回归预测值比少,因此我们按照websocketConnectionCount减少5%的比例作为预测值。这样缩容过程会非常长,以备重连使用。

k8s-custom-hpa-scaling-down

点线是5%缩减,由于预测低于当前负载需求值

如果长时间没有连接重连,我们会缓慢缩容。

执行Kuberetes扩容操作

由于我们自定义的HPA运行在同一Kubernetes集群中,所以在Master上可以直接从/var/run/secrets/kubernetes.io/serviceaccount/token获取服务Token来访问API。使用这个Token我们可以访问API来改变Pod副本的数量,来实现扩容。

完全迁移到RxJS

我们使用RxJS的Stream来实现函数式组件处理事件。这让代码的可读性非常高:

这样我们可以优雅地使用map() + switch()来持续调节部署、记录错误日志直到成功,或者下一次扩容请求开始。

后记

自定义HPA是一件非常有意思的事情。使用Kubernetes API是一次很棒的经历,也为如何设计API做出了很好的示范。刚开始我以为开发自己的HPA会有很大的工作量,不过最后能把各个部分组织到一起协同工作还是很开心。使用RxJS来定义工作流可以避免在状态管理上踩坑。总的来说,我们的预测扩容管理在生产环境中应用非常成功。