【问题记录】kubernetes hpa数据时有时无

运维归一

已于 2024-04-01 17:20:46 修改

阅读量765

点赞数 24

文章标签： kubernetes 容器 hpa adapter

于 2024-03-26 17:16:38 首次发布

运维归一

本文链接：https://blog.csdn.net/zhanremo3062/article/details/136928945

版权

问题记录专栏收录该内容

19 篇文章

订阅专栏

问题背景

Kubernetes 中的 Horizontal Pod Autoscaler（HPA）是一种自动扩缩容机制，它可以动态地调整部署（Deployment）、有状态集（StatefulSet）或副本集（ReplicaSet）中 Pod 的副本数量，以应对负载变化。具体来说：

HPA 根据预先设定的资源使用策略（如 CPU 使用率或者自定义应用指标），周期性地检查容器的实际资源使用情况并与目标使用率进行比较。当实际资源使用超出或低于预设阈值时，HPA 会自动增加或减少对应的 Pod 副本数，从而确保应用的整体性能和资源利用效率。

例如，默认情况下，HPA 可以基于每个 Pod 的 CPU 利用率进行伸缩操作，但也可以配置为监听其他特定的资源使用指标或者应用程序暴露的自定义度量标准来进行扩缩容决策。

简而言之，HPA 是 Kubernetes 集群中一种重要的自动化运维工具，它有助于提升集群整体的服务质量和资源优化程度

可以自定义指标并在 Horizontal Pod Autoscaler (HPA) 中使用它们，当您希望根据除 CPU 和内存之外的应用程序特定指标来决定是否需要扩缩容 Pod 数量时，就可以使用自定义指标。例如，您的应用程序可能提供了诸如请求处理速率（如 QPS - Queries Per Second）、数据库连接数、队列长度或其他反映服务负载或业务活动水平的指标。

要启用基于自定义指标的 HPA，通常需要以下步骤：
设置监控系统：使用像 Prometheus 这样的监控系统收集应用程序暴露的自定义指标。
安装适配器：部署 Prometheus Adapter 或其他能够将自定义指标转化为 Kubernetes 能够理解的指标格式的组件。这个适配器通常会与 Kubernetes API 服务器集成，将自定义监控数据转换成 Custom Metrics API，使得 Kubernetes 能够查询这些指标。
配置 HPA：创建或更新 HorizontalPodAutoscaler 资源对象，在其 spec.metrics 字段中指明要使用的自定义指标，包括指标名称、目标值以及用于比较的类型。

例如，您可能会定义一个 HPA，使其基于名为 myapp_qps 的自定义指标来调整 Pod 数量。这样，当 myapp_qps 超过或低于预设阈值时，Kubernetes 就会自动增减对应 Deployment 或 StatefulSet 中的 Pod 副本数量。

而我正要使用HPA功能，却发现华为云CCE并没有/apis/external.metrics.k8s.io/v1beta1API资源，暂且使用/apis/custom.metrics.k8s.io/v1beta1实现

问题过程

1、安装prometheus
2、安装prometheus-adapter
3、配置adapter rules文件

上面全部操作完成后，即将大功告成，使用kubectl get --raw '/apis/custom.metrics.k8s.io/v1beta1'| jq .获取监控指标，没有数据！！！
检查了n遍，认为一切没问题，试了几分钟（不信那个xie），写了一个shell脚本，发现每5分钟就出现数据了！怀疑是获取时间问题

解决办法

5分钟的获取时间间隔，想起了prometheus😊，我真是无语噢

来看下prometheus-server.yml文件配置：

  evaluation_interval: 5m
  scrape_interval: 5m
  scrape_timeout: 30s

evaluation_interval: 5m

evaluation_interval 指定了Prometheus服务器执行规则评估（rule evaluation）的频率。规则可以包括记录时间序列数据的记录规则（recording rules）和触发警报的通知规则（alerting rules）。在这个例子中，evaluation_interval 设置为 5m，即每5分钟执行一次规则评估。

当Prometheus到达设定的evaluation_interval时，它会计算这段时间内所有已定义规则所对应的表达式，并根据结果执行相应操作：

对于记录规则，将计算结果作为新的时间序列数据存储起来，便于后续查询时使用，通常用于预聚合或简化复杂查询。
对于通知规则，如果规则条件满足（如某个指标值超过阈值），则触发关联的警报并发送通知给指定的接收器（如电子邮件、PagerDuty、Slack等）。警报状态（如pending、firing、resolved）也会据此更新。
scrape_interval: 5m

scrape_interval 定义了Prometheus服务器从目标（targets）收集监控指标数据的时间间隔。这里的5m表示Prometheus每5分钟向配置好的监控目标（如应用程序的HTTP端点、Node Exporter等）发起一次HTTP请求，拉取其暴露的监控指标。

监控数据的采集是Prometheus的核心功能，定期抓取的数据会被存储在本地TSDB（Time Series Database）中，供后续查询、可视化和告警使用。设置合理的scrape_interval有助于平衡数据新鲜度与系统资源消耗。对于需要实时监控或快速响应变化的指标，可以设置较短的scrape_interval；而对于变化较慢或对实时性要求不高的指标，可以适当增大间隔以减轻服务器负担。

scrape_timeout: 30s

scrape_timeout 指定了Prometheus在从目标抓取监控数据时等待响应的最大时间。在这个例子中，scrape_timeout 设置为 30s，即每次数据抓取操作如果在30秒内未收到目标的响应，Prometheus将视为此次抓取超时并放弃此次请求。

设置合适的scrape_timeout有助于防止因个别目标响应缓慢或故障导致Prometheus服务器长时间阻塞。如果频繁出现超时情况，可能需要排查目标系统的性能问题或网络延迟，或者考虑调整scrape_interval以避免过于频繁地访问问题目标。

总结来说，这段配置决定了Prometheus服务器每5分钟（evaluation_interval 和 scrape_interval 都为 5m）执行一次规则评估和数据抓取，并在每次数据抓取时最多等待30秒（scrape_timeout 为 30s）获取目标的监控数据。这些参数的合理设置对于确保Prometheus有效、高效地进行监控数据收集、处理和告警至关重要。

这就瞬间明朗了啊，修改以上三个参数即可解决这个问题

  evaluation_interval: 30s
  scrape_interval: 30s
  scrape_timeout: 15s

这样配置的话，全局抓取的数据时间间隔都会变，抓紧自定义指标，可使用单独的scrape_interval参数

- job_name: 'test_dps_counts_monitor'
  scrape_interval: 1s
  static_configs: