如何使用Kubernetes创建自定义Pod水平扩展器

Kubernetes 1.3为在生产环境中平滑运行容器化应用提供了大量开箱即用的特性。不过一些特性依然不够完善，比如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来实现函数式组件处理事件。这让代码的可读性非常高：

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来定义工作流可以避免在状态管理上踩坑。总的来说，我们的预测扩容管理在生产环境中应用非常成功。