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

最新推荐文章于 2024-03-13 15:15:53 发布

xiaomin_____

最新推荐文章于 2024-03-13 15:15:53 发布

阅读量185

点赞数

分类专栏： Kubernetes 文章标签：网络

本文链接：https://blog.csdn.net/xiaomin1991222/article/details/84860220

版权

Kubernetes 专栏收录该内容

91 篇文章 3 订阅

订阅专栏

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

点线是预测负载

逐渐缩容

缩容时我们并不按照预测值，因为预测可能会导致缩减到当前负载下仍需要的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