k8s 中的HPA

一、概念

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