转载

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

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

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

Kubernetes原生HPA如何工作

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

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

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

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

确保应用不崩溃

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

快速扩容

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

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

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

点线是预测负载

逐渐缩容

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

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

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

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

执行Kuberetes扩容操作

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

完全迁移到RxJS

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

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 （翻译：刘思贤)

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

译者介绍

刘思贤，爱油科技架构师，PMP，喜欢关注互联网相关技术与软件项目管理，是一名DevOps实践者，乐于整理和分享一些实践经验。

原文 http://dockone.io/article/1639

正文到此结束