k8s 中的HPA

网络高瘦

已于 2024-06-13 17:49:58 修改

阅读量1.1k

点赞数 30

文章标签： kubernetes 容器云原生

于 2024-06-13 17:45:05 首次发布

本文链接：https://blog.csdn.net/mikechen1/article/details/139637714

版权

一、概念

1.1 定义

HPA（Horizontal Pod Autoscaling）Pod 水平自动伸缩，Kubernetes 有一个 HPA 的资源，HPA 可以根据 CPU 利用率自动伸缩一个 Replication Controller、Deployment 或者Replica Set 中的 Pod 数量。以此来优化资源的使用和提高服务的响应能力。通过此功能，只需简单的配置，便可以利用监控指标（CPU使用率、磁盘、自定义指标等）自动的扩容或缩容服务中的Pod数量，当业务需求增加时，系统将无缝地自动添加适量Pod容器，提高系统稳定性。

① HPA 基于 Master 上的 kube-controller-manager 服务启动参数 horizontal-pod-autoscaler-sync-period 定义的时长（默认为30秒），周期性的检测 Pod 的 CPU 使用率。

② HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理

③ metrics-server 也需要部署到集群中，它可以通过 resource metrics API 对外提供度量数据

HPA的API有三个版本，通过Kubectl api-versions | grep autoscal可看到

autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2

#autoscaling/v1 只支持基于CPU指标的缩放
autoscaling/v2beta1支持Resource Metrics（资源指标，如Pod的内存）和Custom Metrics（自定义指标）的缩放
autoscaling/v2beta2支持Resource Metrics（资源指标，如Pod的内存）和Custom Metrics

HPA/v1版本只能基于CPU做扩容

HPA/v2版本可以基于内存和自定义的指标做扩容和缩容

Pod自动缩放不适用于无法缩放的对象，比如DaemonSet；

HPA由Kubernetes API 资源和控制器实现。控制器会周期性的获取平均CPU利用率，并与目标值相比较后调整Deployment中的副本数量

1.2 核心概念

        水平扩展（Horizontal Scaling）：增加Pod的数量来分摊负载，与垂直扩展（增加单个Pod的资源）相对。
        Pod副本（Pod Replicas）：运行应用程序的容器实例，通常是在Deployment或ReplicaSet等控制器下管理的。
        指标（Metrics）：用于触发HPA扩缩容的度量值，如CPU使用率、内存使用量、自定义的应用程序指标等。

1.3 工作原理

        指标收集：HPA监控Pod的资源使用情况，如CPU和内存利用率。这些指标可以通过Kubernetes的Metrics API获取，或者使用自定义的指标提供者（如Prometheus）。
        计算扩缩容：HPA根据当前的资源使用情况和预设的目标值（如CPU的目标利用率）计算出所需的Pod副本数量。如果当前的资源使用超过了目标值，HPA会增加Pod副本数量；如果资源使用低于目标值，HPA会减少Pod副本数量。
        执行扩缩容：HPA通过更新相关的Deployment或ReplicaSet来改变Pod副本的数量。增加副本时，Kubernetes会创建新的Pod；减少副本时，会删除多余的Pod。

如何实现自动扩缩容？

K8s的HPA Controller已经实现了一套简单的自动扩缩容逻辑，默认情况下，每30秒检测一次指标，只要检测到了配置HPA的目标值，则会计算出预期的工作负载的副本数，再进行扩缩容操作。同时，为了避免过于频繁的扩缩容，默认再5分钟内没有重新扩缩容的情况下，才会触发扩缩容。HPA本身的算法相对比较保守，可能并不适用于很多场景。例如，一个快速的流量突发场景，如果正处在5分钟内的HPA稳定期，这个时候根据HPA的策略，会导致无法扩容。

1.4 HPA的配置关键参数

        ScaleTargetRef：指定 HPA 将要作用的资源对象，如 Deployment、Replica Set 或 RC 的名称。
        MinReplicas：最小副本数，即使在负载很低时也不会低于这个数量。
        MaxReplicas：最大副本数，即使在负载很高时也不会超过这个数量。
        Metrics：定义用于触发伸缩的度量标准和目标值。例如，可以设置 CPU 的利用率目标，当实际利用率超过这个目标值时，HPA 会增加副本数量；当利用率低于目标值时，HPA 会减少副本数量。

1.5 关键组件

① HPA控制器（HPA Controller）

这是HPA的核心组件，负责周期性地检查Pod的资源使用情况，并根据这些信息计算出所需的Pod副本数量。

它使用Metrics Server或其他监控工具来获取资源使用数据。

② Metrics Server

Metrics Server是Kubernetes集群中的一个组件，用于聚合资源使用数据，并通过Metrics API提供这些数据。

它提供了CPU和内存使用率等资源指标，这些指标是HPA进行扩缩容决策的基础。

③ 自定义指标适配器（Custom Metrics Adapter）

当需要使用自定义指标（如来自Prometheus的指标）时，自定义指标适配器允许HPA使用这些外部指标。

它通过Custom Metrics API将外部指标转换为Kubernetes可以理解的格式。

④ Deployment/ReplicaSet

HPA通常与Deployment或ReplicaSet一起使用，这些是定义了Pod副本数量和更新策略的高级抽象。

当HPA决定调整副本数量时，它会通过修改Deployment或ReplicaSet的规格来实现。

⑤ Pods

Pod是Kubernetes中的基本工作单元，HPA的目标就是根据指标自动调整Pod的数量。

每个Pod可以有一个或多个容器，HPA关注的是整个Pod的资源使用情况。

⑥ API服务器（API Server）

Kubernetes API服务器是集群的通信中心，所有资源的创建、更新和删除都通过它进行。

HPA控制器通过API服务器与集群中的其他组件交互，如更新Deployment或ReplicaSet的副本数量。

⑦ Kubelet

Kubelet是运行在每个节点上的守护进程，负责维护Pod的生命周期，包括启动、停止容器。

当HPA触发扩容时，Kubelet会在节点上启动新的Pod实例。

⑧ 监控和日志系统

虽然不是HPA的直接组件，但监控和日志系统对于理解和调试HPA的行为至关重要。

它们提供了关于Pod状态、资源使用和扩缩容事件的详细信息。

这些组件共同工作，使得HPA能够根据实际的负载情况自动调整Pod的数量，从而实现应用程序的弹性伸缩。

1.6 Prometheus 生态组件

Prometheus server：以http pull （拉取）方式的数据采集，TSDB的数据存储alter告警生成

client-libray 客户端库使用服务原生支持Prometheus监控的系统和应用的数据采集

exporter 对应指标暴露端，用于收集原生不支持Prometheus监控的系统和应用的数据暴露给Prometheus。node-exporter nginx-expoter mysql-exporter

altermanger：接受Prometheus推送的告警信息，并且负责告警路由转发给接收人

grafana：外置的监控数据展示平台使用primQL，查询Prometheus的数据源

1.7 Prometheus工作流程

        1️⃣Prometheus 以 Prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server 从监控目标中通过 pull 方式拉取指标数据，或通过 pushgateway 把采集的数据拉取到 Prometheus server 中。
        2️⃣Prometheus server 把采集到的监控指标数据通过 TSDB 存储到本地 HDD/SSD 中。
        3️⃣Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的告警通知发送到 Alertmanager。
        4️⃣Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
        5️⃣Prometheus 自带的 Web UI 界面提供 PromQL 查询语言，可查询监控数据。
        6️⃣Grafana 可接入 Prometheus 数据源，把监控数据以图形化形式展示出。

1.8 Prometheus的局限性

Prometheus 是一款指标监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；

Prometheus 认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；
若需要存储长期的历史数据，建议基于远端存储机制将数据保存于 InfluxDB 或 OpenTSDB 等系统中；

Prometheus 的集群机制成熟度不高，可基于 Thanos 或 Cortex 实现 Prometheus 集群的高可用及联邦集群。

二、部署Prometheus

//Prometheust Server 端安装和相关配置
（1）上传 prometheus-2.35.0.linux-amd64.tar.gz 到 /opt 目录中，并解压
systemctl stop firewalld
setenforce 0

cd /opt/
tar xf prometheus-2.35.0.linux-amd64.tar.gz
mv prometheus-2.35.0.linux-amd64 /usr/local/prometheus

cat /usr/local/prometheus/prometheus.yml | grep -v "^#"
global:                   #用于prometheus的全局配置，比如采集间隔，抓取超时时间等
scrape_interval: 15s           #采集目标主机监控数据的时间间隔，默认为1m
evaluation_interval: 15s        #触发告警生成alert的时间间隔，默认是1m
# scrape_timeout is set to the global default (10s).
scrape_timeout: 10s           #数据采集超时时间，默认10s

alerting:               #用于alertmanager实例的配置，支持静态配置和动态服务发现的机制
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093

rule_files:               #用于加载告警规则相关的文件路径的配置，可以使用文件名通配机制
# - "first_rules.yml"
# - "second_rules.yml"

scrape_configs:           #用于采集时序数据源的配置
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: "prometheus"       #每个被监控实例的集合用job_name命名，支持静态配置（static_configs）和动态服务发现的机制（*_sd_configs）

# metrics_path defaults to '/metrics'
metrics_path: '/metrics' #指标数据采集路径，默认为 /metrics
# scheme defaults to 'http'.

static_configs:               #静态目标配置，固定从某个target拉取数据
- targets: ["localhost:9090"]

（2）配置系统启动文件，启动 Prometheust
cat > /usr/lib/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--storage.tsdb.path=/usr/local/prometheus/data/ \
--storage.tsdb.retention=15d \
--web.enable-lifecycle

ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

（3）启动
systemctl start prometheus
systemctl enable prometheus

netstat -natp | grep :9090

浏览器访问：http://192.168.10.80:9090 ，访问到 Prometheus 的 Web UI 界面
点击页面的 Status -> Targets，如看到 Target 状态都为 UP，说明 Prometheus 能正常采集到数据
http://192.168.10.80:9090/metrics ，可以看到 Prometheus 采集到自己的指标数据，其中 Help 字段用于解释当前指标的含义，Type 字段用于说明数据的类型

三、部署Exporters

//部署 Node Exporter 监控系统级指标
（1）上传 node_exporter-1.3.1.linux-amd64.tar.gz 到 /opt 目录中，并解压
cd /opt/
tar xf node_exporter-1.3.1.linux-amd64.tar.gz
mv node_exporter-1.3.1.linux-amd64/node_exporter /usr/local/bin

2）配置启动文件
cat > /usr/lib/systemd/system/node_exporter.service <<'EOF'
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--collector.ntp \
--collector.mountstats \
--collector.systemd \
--collector.tcpstat

ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

（3）启动
systemctl start node_exporter
systemctl enable node_exporter

netstat -natp | grep :9100

浏览器访问：http://192.168.10.80:9100/metrics ，可以看到 Node Exporter 采集到的指标数据

常用的各指标：
●node_cpu_seconds_total
●node_memory_MemTotal_bytes
●node_filesystem_size_bytes{mount_point=PATH}
●node_system_unit_state{name=}
●node_vmstat_pswpin：系统每秒从磁盘读到内存的字节数
●node_vmstat_pswpout：系统每秒钟从内存写到磁盘的字节数

更多指标介绍：https://github.com/prometheus/node_exporter

（4）修改 prometheus 配置文件，加入到 prometheus 监控中
vim /usr/local/prometheus/prometheus.yml
#在尾部增加如下内容
- job_name: nodes
metrics_path: "/metrics"
static_configs:
- targets:
   - 192.168.10.80:9100
   - 192.168.10.13:9100
   - 192.168.10.14:9100
labels:
service: kubernetes