文章：如何实现Docker应用的自定义弹性伸缩-cpu按集群和服务进行聚合的问题

1. cpu不使用容器的cpu，是因为容器的cpu是按照设置的比重去竞争物理主机的cpu，所以阈值无法固定，那么阿里云提供的方案中cpu按集群及服务进行聚合，请问如何理解？并且如何确定应该扩缩哪些实例（容器）？

答：首先说明一下阿里云容器服务中各种资源（集群、节点、容器等等）的层次关系，然后再讨论设置CPU告警规则阈值时为何使用聚合后的指标。

容器服务的资源有以下两条线：

集群 ——> 节点：一个集群包涵多个ECS节点，每个节点上面会运行很多容器（从这个角度看，容器是打散的，但实际上所有的容器都有逻辑上的归属关系，即归属于某个服务）。

应用 ——> 服务 ——> 容器：一个应用（例如wordpress）包涵多个服务（例如wordpress应用下会包涵 db服务、web界面服务），一个服务下包涵多个容器。

在了解这两条资源线以后，我们会发现，第一条资源线真正提供服务或者说承载业务压力的是节点，所以节点的状态（CPU、MEMORY）是反馈节点压力情况的重要指标。但是单个节点的CPU指标不能反馈一个集群的压力情况，因为集群上的节点所承载的压力不一样，有的节点承载流量多，压力大，但是不代表整个集群的资源已经到了库容的临界值，很可能其他节点压力并不大，所以这种情况下可以根据单个节点的监控报警来及时做节点上容器的重新调度，将容器调度到其他压力水平小的节点上。针对集群的节点伸缩角度来看，需要使用集群角度的、集群下所有节点CPU的聚合平均值来衡量一个集群是否需要扩容。

针对另外一条资源线，一个开发者在容器服务中关注的资源层次是 应用->服务->容器 ，即一个应用是由若干个服务组成，一个服务是由若干个容器组成。在弹性伸缩的场景中，容器虽然是最底层承载真实流量压力的资源，但是针对容器维度设置告警规则没有意义，因为对外提供服务的主体是 “服务”，所以要根据“服务”下的若干个容器的平均CPU使用率来判断一个服务当前压力水平，如果平均值高，则说明整个服务压力过大，应该给这个服务扩容，即再生成几个容器来支撑更多的流量。

以上是cpu使用集群维度的聚合指标、服务维度的聚合指标来设置告警阈值的原因。由于采用这种资源层次结构，所以自然就能确定应该扩缩哪些容器——那些业务压力大的服务扩容，生成新的相同的容器来支撑这个服务的流量。

2. 集群(aliyun.cluster)及服务(aliyun.service.id)是依赖label实现的吗？如果是，那么通过命令实现了cadvisor在监控容器的时候增加了捕获属性label，并且成功写入influxDB？（我尝试docker_env_metadata_whitelist=MARATHON_APP_ID,MARATHON_APP_DOCKER_IMAGE添加属性envs，cadvisor在监控容器的时候成功捕获属性envs，但是写入influxDB失败）

答：集群、服务在内部有地域内全局存储服务来记录其和容器的关系，容器自身的label也会反馈出该关系。目前容器服务的第三方集成是使用特殊的label来把数据写入到influxdb中，这一点可以查看帮助文档：https://help.aliyun.com/document_detail/47895.html?spm=5176.product25972.6.637.pRTnDf

至于您提到的您的使用方式写入到influxdb失败，可以加入我们的技术支持钉钉群来找相关同学做具体的技术支持。

3. kapacitor没有界面操作，所以阿里云是在后期自己设计了相应操作的界面？

答：目前对外提供的弹性伸缩服务是基于阿里云的云监控产品的，云监控中可以查看到监控数据和对应的弹性伸缩告警规则（如果创建应用时设置了弹性伸缩相关配置或者集群节点伸缩配置）。至于开源的弹性伸缩方案，我们会提供多种支持，kapacitor只是其中的一个，我们后面还会集成grafana等。