49 | Custom Metrics: 让Auto Scaling不再“食之无味”

HPA 通过 HorizontalPodAutoscaler 配置要访问的 Custom Metrics, 来决定如何scale。 Custom Metric APIServer 的实现其实是一个Prometheus 的Adaptor，会去Prometheus中读取某个Pod/Servicce的具体指标值。比如，http request的请求率。 Prometheus 通过 ServiceMonitor object 配置需要监控的pod和endpoints，来确定监控哪些pod的metrics。 应用需要实现/metrics， 来响应Prometheus的数据采集请求。 留给自己的思考，Pod 的 metrics endpoint 如何对应到http_requests 这个指标的？

张老师，伸缩是不是写的简单了点，毕竟伸缩也是核心功能之一。主要想了解下，hpa伸缩的判定算法的替换方法，vpa预测算法的常见类型及优缺点，ca在大规模场景下实现的原理，ar的应用场景等；还有就是自定义伸缩（prometheus)时间戳优化原理、方法，及最后微服务下伸缩的结合方法等。可不可以从伸缩的数据分类、获取手段、处理算法、伸缩流程、调度算法、故障处理反馈机制等方面，再列几章讲一下，谢谢张老师！！

请问能否实现跨node的水平扩展?

请教一个问题：对于多POD的应用（如多副本的deployment），假设配置了根据CPU使用率进行自动水平伸缩（HPA），那么HPA执行水平伸缩的依据是各个POD中CPU使用率平均值还是最高值？另外HPA探测到多少次CPU高于设置值才会开始伸缩？CPU使用率探测的频率又是多久一次呢？

就为了做自定义业务指标的监控，我们也做了水晶桥(Crystal Bridge)项目开源在github上了。思路是自采通过annotations公开的promethus指标，然后推往prometheus GW，最后再由上层prometheus来采集。 今天这种让HPA通过自定义指标来完成扩容/缩容操作的技术设计的确很棒，学习了，感谢。

请问下老师，扩容好理解就是加容器，那缩容的话如何实现呢，怎么保证在删除容器的时候容器上的请求不受影响呢

请张老师帮忙解惑，对于多实例应用，采集 service暴露的指标才是正确的做法，这句怎么理解？采集每个pod对应的指标不好吗，service后面对应的api无法确认来自哪个pod吧？数据可能忽大忽小，如果采集到一个刚刚hpa的pod指标，数据可能更小，这样应该没有采集每个pod，然后平均值来的更精确吧？类似对于cpu 的hpa，就是采集的每个pod的指标然后做平均值

“所以说，我们在对前面的 Custom Metircs URL 进行访问时，会看到值是 501484m，这里的格式，其实就是 milli-requests，相当于是在过去两分钟内，每秒有 501 个请求。”——这个 501484m 是怎么折算成 501 QPS的，老师能再解释下嘛？

第四十七课:Custom Metrics: 让Auto Scaling不再“食之无味” 很多 PaaS 项目中的Auto Scaling，即自动水平扩展的功能，只能依据某种指定的资源类型执行水平扩展，比如 CPU 或者 Memory 的使用值。凭借强大的 API 扩展机制，Custom Metrics 已经成为了 Kubernetes 的一项标准能力。并且，Kubernetes 的自动扩展器组件 Horizontal Pod Autoscaler （HPA）， 也可以直接使用 Custom Metrics 来执行用户指定的扩展策略，这里的整个过程都是非常灵活和可定制的。Kubernetes 里的 Custom Metrics 机制，也是借助 Aggregator APIServer 扩展机制来实现的。这里的具体原理是，当你把 Custom Metrics APIServer 启动之后，Kubernetes 里就会出现一个叫作custom.metrics.k8s.io的 API。而当你访问这个 URL 时，Aggregator 就会把你的请求转发给 Custom Metrics APIServer 。而 Custom Metrics APIServer 的实现，其实就是一个 Prometheus 项目的 Adaptor。

Hpa里面配置了对哪些deploy等进行水平伸缩、伸缩的范围，对应的指标的阈值。 指标是普罗主动拉取的，需要个servicemonitor告诉普罗哪个指标拉取哪个pod。 这样指标有了，需扩展的k8资源确定了，ha功能也就可以了。