49丨CustomMetrics让AutoScaling不再“食之无味”.pdf
10墨值下载
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
2018-12-14 张磊
深入剖析Kubernetes
进入课程
讲述：张磊
时长 07:51 大小 7.20M
你好，我是张磊。今天我和你分享的主题是：Custom Metrics，让 Auto Scaling 不
再“食之无味”。
在上一篇文章中，我为你详细讲述了 Kubernetes 里的核心监控体系的架构。不难看到，
Prometheus 项目在其中占据了最为核心的位置。
实际上，借助上述监控体系，Kubernetes 就可以为你提供一种非常有用的能力，那就是
Custom Metrics，自定义监控指标。
在过去的很多 PaaS 项目中，其实都有一种叫作 Auto Scaling，即自动水平扩展的功能。
只不过，这个功能往往只能依据某种指定的资源类型执行水平扩展，比如 CPU 或者
Memory 的使用值。
下载APP
而在真实的场景中，用户需要进行 Auto Scaling 的依据往往是自定义的监控指标。比如，
某个应用的等待队列的长度，或者某种应用相关资源的使用情况。这些复杂多变的需求，在
传统 PaaS 项目和其他容器编排项目里，几乎是不可能轻松支持的。
而凭借强大的 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。
比如，现在我们要实现一个根据指定 Pod 收到的 HTTP 请求数量来进行 Auto Scaling 的
Custom Metrics，这个 Metrics 就可以通过访问如下所示的自定义监控 URL 获取到：
这里的工作原理是，当你访问这个 URL 的时候，Custom Metrics APIServer 就会去
Prometheus 里查询名叫 sample-metrics-app 这个 Pod 的 http_requests 指标的值，然
后按照固定的格式返回给访问者。
当然，http_requests 指标的值，就需要由 Prometheus 按照我在上一篇文章中讲到的核
心监控体系，从目标 Pod 上采集来。
这里具体的做法有很多种，最普遍的做法，就是让 Pod 里的应用本身暴露出一个 /metrics
API，然后在这个 API 里返回自己收到的 HTTP 的请求的数量。所以说，接下来 HPA 只需
要定时访问前面提到的自定义监控 URL，然后根据这些值计算是否要执行 Scaling 即可。
1 https://<apiserver_ip>/apis/custom-metrics.metrics.k8s.io/v1beta1/namespaces/default/pod
复制代码
of 10
10墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
文档被以下合辑收录
评论