3同行回答
目前，我们企业内部使用的是Kubernetes1.5版本，其自带的自动伸缩组件相对比较简单，仅仅支持基于CPU和内存指标的自动伸缩，不能满足复杂的业务需求。 另外，K8S原生的自动伸缩组件算法相对简单，对噪声比较敏感。极易产生应用伸缩抖动，为此我们企业内部自研了一套AutoScale Agent，用于集群节点和集群内Pod的自动伸缩。
集群的自动伸缩主要分为横向伸缩和纵向伸缩，其中横向伸缩是应用Pod数的伸缩，纵向伸缩是集群节点节点数的伸缩，这两种类型的伸缩均是基于监控指标来进行的。
对于横向伸缩，我们主要是基于以下几个指标来进行的：
1、 Pod的CPU使用率
2、 Pod的内存使用率
3、 接入层的流量数据
4、 根据业务需要，预先设定的伸缩时间段，定时定期进行伸缩
对于前三种伸缩策略，我们会预先设定伸缩阈值以及期望的最大Pod数和最小Pod数。例如，Pod CPU使用率的自动伸缩，我们是基于heapster收集上来的Pod监控指标来进行。当CPU的使用率超过了预先设定的阈值时，Autoscale Agent会根据计算出的期望Pod数，如果期望Pod数在预先设定的最大期望Pod数以内，则集群伸缩到计算出的期望Pod数，反之则伸缩到最大期望Pod数。由于Pod中容器在启动过程中，CPU的使用率会急剧增加，此时极易对自动伸缩组件产生噪声，造成误判，所以我们的Autoscale Agent对于一个Deployment，如果在5分钟内进行过伸缩操作，则即使根据监控数据计算出Pod数需要进行扩展，也不会再进行伸缩操作。这么做也就避免了应用不受自动伸缩组件产生的抖动的影响。另外，基于CPU使用率的自动伸缩策略配置需要应用开发者提供数据支持。特别是CPU阈值的设定必须要基于压力测试报告中的数据，切不可凭空想象。因为有些情况下，由于容器内Tomcat中间件的性能调优做的不够好，可能容器的CPU使用率达不到阈值的时候，Tomcat就已经无法正常响应外界的请求了。这种情况下，容器的CPU可能永远达不到设定的阈值，但是实际情况是应用已经由于负载过大而无法正常对外服务了。
另外，当负载降下来的时候，我们需要对Pod数进行收缩。当然收缩Pod数并不像增加Pod数那样急迫，所以我们的Autoscale Agent设定的策略是：Pod数收缩的最小间隔是10分钟，既如果10分钟内同一个Deployment进行过伸缩操作，即使目前根据监控数据计算出Pod数需要收缩，也不执行收缩操作。
在PaaS云实际的运营过程中，我们意外地发现，上述第四种根据业务需求来定时定期伸缩的策略是使用最多的。很多情况下，Pod的数的伸缩需求是可以根据业务提前预知的。最典型的一个例子是“双11”，我们完全可以提前预知到，在“双11”的时候，我们的支付平台应用会有流量激增的情况，那么我们就可以预先配置伸缩策略，在“双11”到来之前，对Pod数进行扩容，在“双11”过去以后，对Pod数进行收缩。
对于纵向伸缩，我们主要是通过跟IaaS平台深度结合来完成的。当监控平台监测到PaaS节点的CPU和内存使用率过高时，就会给IaaS平台发送资源申请，IaaS平台就会根据申请分配给PaaS平台一定数量的节点完成集群的纵向伸缩。
这个话题可能还有另一种情况，也就是对PaaS平台的节点数进行动态扩容。
以OpenShift这样的PaaS平台为例，其采用ansible来完成集群的部署以及动态扩容功能。用户可以根据集群资源的情况，调用扩容的API来实现动态的集群扩容，这里的API接口可以用户自行开发，也可以使用Ansible Tower来提供。
收起