为Kubernetes创建自定义Pod水平扩展器

当前版本（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 变化规律的方程，并找到预判值。

点线是预测负载

逐渐缩容

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

点线是5%缩减，因为预测值会比当前所需负载低

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

执行Kuberetes扩容操作

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

完全迁移到RxJS

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

 

 

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

const Rx = require ( rx ) ; const credentials = getKubernetesCredentials ( ) ;   Rx . Observable . interval ( 10 * 1000 ) . map ( i = > getMetricsofPods ( credentials . masterUrl , credentials . token ) ) . map ( metrics = > predictNumberOfPods ( metrics , MAX_CONNECTIONS_PER_POD ) ) . distinctUntilChanged ( prediction = > prediction ) . map ( prediction = > scaleDeploymentInfiniteRetries ( credentials . masterUrl , credentials . token , prediction ) ) . switch ( ) . subscribe ( onNext = > { } , onError = > { console . log ( ` Uncaught error : $ { onError . message } $ { onError . stack } ` ) ; process . exit ( 1 ) ; } ) ; // NOTE: getKubernetesCredentials(), getMetricsofPods(), predictNumberOfPods(), scaleDeploymentInfiniteRetries() left out for brevity

 

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

后记

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

原文链接： Building your own horizontal pod autoscaler for Kubernetes （翻译：刘思贤)

======================

 

http://lcbk.net/3758.html

https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/proposals/custom-metrics.md