当前位置：首页 > news >正文

Kubernetes 自动扩缩容方案详解

news 2025/10/14 14:36:51

一、自动（弹性）扩缩容背景分析

1.1 核心概念

弹性伸缩是根据业务需求和预设策略，自动调整弹性资源的管理服务。通过定时、周期或监控策略，动态增加 / 减少资源并完成实例配置，保障业务平稳运行。

1.2 实际业务场景

在实际工作中，以下场景需频繁进行扩缩容操作：

流量峰值场景：电商平台 “618”“双十一” 秒杀活动，流量骤增需扩容；
资源优化场景：非峰值时段负载降低，需缩容以减少资源浪费；
高可用保障：服务故障时，通过扩容快速补充实例，避免业务中断。

1.3 Kubernetes 扩缩容分层

K8s 中的扩缩容分为两个核心层面，分别对应不同资源对象：

分层	操作对象	核心目标	典型场景
Node 层面	物理 / 虚拟节点	调整集群整体计算资源池大小	集群长期负载增长，现有节点无法满足所有 Pod 调度需求
Pod 层面	Deployment/StatefulSet 管理的 Pod 副本	调整单服务的实例数量，匹配业务流量	单服务流量波动（如 API 服务峰值 / 谷值）

二、Kubernetes 自动伸缩核心方案

K8s 提供三类主流自动伸缩方案，分别针对 Pod 水平、Pod 垂直、集群节点三个维度，适配不同业务需求：

2.1 HPA（Horizontal Pod Autoscaler）：Pod 水平自动伸缩

2.1.1 核心定位

通过监控指标（CPU、内存、自定义指标）自动调整 Pod 副本数量，实现 “流量增则扩容、流量减则缩容”，是最常用的 Pod 伸缩方案。

2.1.2 HPA 版本差异（核心指标支持）

HPA 分多个版本，核心区别在于支持的监控指标范围，需根据业务需求选择：

HPA 版本	支持指标类型	适用场景	局限性
v1	仅 CPU 使用率	简单 CPU 密集型服务（如计算任务）	无法支持内存、请求数（RPS）等关键指标，适用场景窄
v2（v2beta2/v2stable）	1. 资源指标（CPU、内存）2. 自定义指标（如 RPS、QPS）3. 外部指标（如消息队列堆积数）	复杂业务场景：- 内存密集型服务（如缓存服务）- 流量驱动型服务（如 Web 后端）- 依赖外部系统的服务（如消费 Kafka 消息的服务）	需额外部署指标采集组件（如 Metrics Server、Prometheus Adapter）

2.1.3 HPA 工作三要素

实现 HPA 自动伸缩，需解决 “依据什么指标、如何采集指标、如何执行伸缩” 三个核心问题：

指标选择：依据什么决定扩缩容？
- 基础指标：CPU 使用率（默认阈值 50%-80%）、内存使用率（适用于内存密集型服务）；
- 自定义指标：每秒请求数（RPS，如 “单 Pod 承载 100 RPS，超过则扩容”）、请求延迟（如 “P95 延迟超过 500ms 则扩容”）；
- 外部指标：消息队列堆积数（如 “Kafka 消费组堆积超过 1000 条则扩容”）。
指标采集：如何获取监控数据？
- 资源指标（CPU / 内存）：依赖 Metrics Server，K8s 官方组件，周期性采集节点 / Pod 的 CPU、内存使用数据，提供 metrics.k8s.io API；
- 自定义 / 外部指标：依赖 Prometheus + Prometheus Adapter，Prometheus 采集自定义指标，Adapter 将指标转换为 K8s 标准 API（custom.metrics.k8s.io），供 HPA 调用。
伸缩逻辑：如何执行扩缩容？
- 控制循环周期：HPA Controller 默认每 15 秒（可通过 --horizontal-pod-autoscaler-sync-period 调整）查询指标；
- 副本数计算：通过 “当前指标值 / 目标指标值” 计算预期副本数，公式示例：预期副本数 = 当前副本数 × (当前指标值 / 目标指标值)（如：当前 2 个 Pod，CPU 使用率 100%，目标阈值 50%，则预期副本数 = 2 × (100%/50%) = 4）；
- 稳定期限制：默认 5 分钟内不重复扩缩容，避免 “抖动”（如短时间流量波动导致频繁伸缩）。

2.2 VPA（Vertical Pod Autoscaler）：Pod 垂直自动伸缩

2.2.1 核心定位

与 HPA 增加 Pod 数量不同，VPA 通过调整 单个 Pod 的资源请求（requests）和限制（limits）（如 CPU 从 200m 调整为 500m，内存从 256Mi 调整为 512Mi），适配 Pod 的资源需求变化。

2.2.2 核心功能

资源推荐：分析 Pod 历史资源使用数据，推荐合理的 CPU / 内存 requests/limits；
自动调整：根据实时资源使用情况，动态更新 Pod 的资源配置（需重启 Pod 生效）；
资源占比保持：保持 requests 与 limits 的比例（如 requests:limits = 1:2），避免资源浪费或超配。

2.2.3 适用场景

单 Pod 资源需求波动大，但实例数量无需调整的服务（如定时任务，执行时需大量 CPU，空闲时资源需求低）；
资源配置不合理导致的浪费（如 Pod 长期使用 100m CPU，但 requests 配置为 500m）。

2.3 KPA（Knative Pod Autoscaler）：基于请求的 Pod 伸缩

2.3.1 核心定位

Knative 生态中的 Pod 伸缩组件，基于并发请求数（Concurrency） 实现自动伸缩，支持 “零到 N” 的伸缩（流量为 0 时缩容至 0 个 Pod，有流量时快速扩容）。

2.3.2 核心特性

并发请求驱动：以 “单 Pod 承载的并发请求数” 为核心指标（如默认单 Pod 承载 10 个并发请求）；
快速伸缩：支持秒级扩容，适配突发流量（如直播推流、瞬时 API 调用峰值）；
伸缩边界控制：可设置最小 / 最大 Pod 数量，避免过度伸缩。

2.3.3 局限性

不支持 CPU / 内存等资源指标，仅依赖请求数；
需集成 Knative Serving 组件，学习成本较高，适用于 Knative 生态场景。

三、HPA 实战：基于 CPU / 内存的 Pod 自动扩缩容

3.1 前置条件：部署 Metrics Server

Metrics Server 是采集 CPU / 内存指标的核心组件，需先部署才能让 HPA 正常工作。

3.1.1 部署步骤

下载配置文件：

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.2/components.yaml

修改镜像（国内环境）：将 image: k8s.gcr.io/metrics-server/metrics-server:v0.6.2 替换为国内镜像：

image: registry.cn-hangzhou.aliyuncs.com/chenby/metrics-server:v0.6.2

启用 API 聚合（1.17+ 版本需配置）：编辑 kube-apiserver 配置文件（/etc/kubernetes/manifests/kube-apiserver.yaml），添加聚合路由参数：

command:- kube-apiserver- --enable-aggregator-routing=true  # 新增此行

部署 Metrics Server：

kubectl apply -f components.yaml

验证部署：

# 查看 Pod 状态（kube-system 命名空间）
kubectl get pods -n kube-system | grep metrics-server
# 测试指标采集（查看节点 CPU/内存使用）
kubectl top nodes
# 查看 Pod 指标
kubectl top pods -n kube-system

3.2 实战 1：基于 CPU 指标的 HPA 配置

3.2.1 步骤 1：部署测试服务（php-apache）

构建自定义镜像（模拟 CPU 密集型任务）：创建 Dockerfile 和 index.php：

# Dockerfile
FROM php:5-apache
ADD index.php /var/www/html/index.php
RUN chmod a+rx index.php

# index.php（CPU 密集型计算）
<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {$x += sqrt($x);
}
echo "OK!";
?>

构建并分发镜像：

# 构建镜像
docker build -t hpa-example:v1 .
# 打包镜像（用于分发到其他节点）
docker save -o hpa-example.tar.gz hpa-example:v1
# 其他节点加载镜像
docker load -i hpa-example.tar.gz

部署 Deployment 和 Service：创建 php-apache.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: php-apache
spec:selector:matchLabels:run: php-apachereplicas: 1  # 初始副本数 1template:metadata:labels:run: php-apachespec:containers:- name: php-apacheimage: hpa-example:v1imagePullPolicy: IfNotPresentports:- containerPort: 80resources:limits:cpu: 500m  # CPU 上限 500mrequests:cpu: 200m  # CPU 请求 200m（HPA 基于此计算使用率）
---
apiVersion: v1
kind: Service
metadata:name: php-apachelabels:run: php-apache
spec:ports:- port: 80selector:run: php-apache

部署资源：

kubectl apply -f php-apache.yaml

3.2.2 步骤 2：创建 HPA 规则

通过命令行快速创建 HPA，设置 CPU 阈值 50%，副本数范围 1-10：

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

验证 HPA 创建：

kubectl get hpa
# 初始状态（无流量）：TARGETS 为 0%/50%，REPLICAS 为 1

3.2.3 步骤 3：压测验证扩容

启动压测容器：使用 busybox 容器循环发送请求，模拟高 CPU 负载：

# 启动 busybox 容器
kubectl run v1 -it --image=busybox:1.28 -- /bin/sh
# 容器内执行压测命令（无限循环请求）
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

2.观察 HPA 扩容：1 分钟后查看 HPA 状态，CPU 使用率会超过 50%，触发扩容：

kubectl get hpa
# 示例输出：TARGETS 231%/50%，REPLICAS 从 1 增至 4（计算逻辑：231%/50% ≈ 4.6 → 取整 4）
# 查看 Pod 数量
kubectl get pods | grep php-apache

3.2.4 步骤 4：停止压测验证缩容

停止压测：在 busybox 容器中按 Ctrl+C 停止循环请求，退出容器。
观察缩容：1-2 分钟后，CPU 使用率降至 0%，HPA 自动缩容至初始副本数 1：

kubectl get hpa
kubectl get deployment php-apache

3.3 实战 2：基于内存指标的 HPA 配置

3.3.1 步骤 1：部署 Nginx 服务（内存测试）

创建 nginx.yaml，配置内存 requests/limits：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-hpa
spec:selector:matchLabels:app: nginxreplicas: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:latestimagePullPolicy: IfNotPresentports:- containerPort: 80resources:requests:cpu: 10mmemory: 25Mi  # 内存请求 25Milimits:cpu: 50mmemory: 60Mi  # 内存上限 60Mi
---
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:selector:app: nginxtype: NodePortports:- port: 80targetPort: 80

部署资源：

kubectl apply -f nginx.yaml

3.3.2 步骤 2：创建基于内存的 HPA（v2 版本）

创建 hpa-v1.yaml（HPA v2 支持内存指标）：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:name: nginx-hpa
spec:maxReplicas: 10minReplicas: 1scaleTargetRef:  # 关联的 DeploymentapiVersion: apps/v1kind: Deploymentname: nginx-hpametrics:  # 内存指标配置- type: Resourceresource:name: memorytarget:averageUtilization: 60  # 目标内存使用率 60%type: Utilization

部署 HPA：

kubectl apply -f hpa-v1.yaml

3.3.3 步骤 3：压测内存验证扩容

进入 Nginx 容器，生成大文件占用内存：

# 进入容器
kubectl exec -it $(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}') -- /bin/sh
# 创建 100Mi 大文件（占用内存）
dd if=/dev/zero of=/tmp/a bs=100M count=1

2.观察 HPA 扩容：内存使用率超过 60%，触发扩容：

kubectl get hpa
# 示例输出：TARGETS 200%/60%，REPLICAS 从 1 增至 4

3.3.4 步骤 4：清理文件验证缩容

删除大文件：

kubectl exec -it <nginx-pod-name> -- rm -rf /tmp/a

2.观察缩容：内存使用率降至阈值以下，HPA 缩容至 1 个 Pod：

kubectl get hpa
kubectl get deployment nginx-hpa

四、Cluster Autoscaler：Kubernetes 集群节点自动扩缩容

4.1 核心定位

Cluster Autoscaler（CA）是 集群级别的自动伸缩组件，负责根据 Pod 调度需求动态调整节点数量：

扩容：当 Pod 因 “资源不足” 无法调度到任何现有节点时，CA 向云厂商（如 AWS、阿里云、GCP）申请创建新节点；
缩容：当节点长期资源利用率低（如 CPU / 内存使用率 < 50%），且节点上的 Pod 可调度到其他节点时，CA 自动删除该节点。

4.2 核心逻辑

4.2.1 扩容触发条件

存在处于 Pending 状态的 Pod，且原因是 “资源不足”（如 Insufficient cpu 或 Insufficient memory）；
新节点加入后，Pending Pod 可成功调度。

4.2.2 缩容触发条件

节点资源利用率低（默认 CPU / 内存使用率 < 50%，可配置）；
节点上所有 Pod 均可重新调度到其他节点（无本地存储、无不可调度约束）；
节点无特殊保护（如未标注 cluster-autoscaler.kubernetes.io/scale-down-disabled: true）。

4.2.3 节点保护规则（不被缩容的场景）

以下情况，CA 不会删除节点，避免业务中断：

节点上有被 PodDisruptionBudget（PDB） 保护的 Pod（如 PDB 要求最少 2 个实例，删除节点会导致实例数低于阈值）；
节点上有 kube-system 命名空间的 Pod（如 CoreDNS、Calico，除非配置允许删除）；
节点上有非控制器（Deployment/StatefulSet）创建的 Pod（如手动创建的 Pod，无重建能力）；
节点上有使用本地存储的 Pod（如 emptyDir、hostPath，迁移后数据丢失）；
节点标注了 cluster-autoscaler.kubernetes.io/scale-down-disabled: true（手动保护）。

4.3 HPA 与 CA 的协同工作流程

HPA 与 CA 配合，实现 “Pod 伸缩” 到 “节点伸缩” 的端到端自动化，流程如下：

流量增长：业务流量增加 → HPA 检测到 CPU / 内存超标 → 增加 Pod 副本数；
节点扩容：新增 Pod 因资源不足进入 Pending 状态 → CA 检测到 Pending Pod → 向云厂商申请新节点；
Pod 调度：新节点加入集群 → K8s Scheduler 将 Pending Pod 调度到新节点；
流量下降：业务流量减少 → HPA 检测到指标低于阈值 → 减少 Pod 副本数；
节点缩容：部分节点资源利用率长期过低 → CA 检测到可缩容节点 → 驱逐节点上的 Pod 到其他节点 → 删除空节点。

4.4 支持的云厂商

CA 支持主流公有云厂商，需结合云厂商的容器服务（如 EKS、ACK、GKE）配置使用：

AWS（Amazon EKS）、阿里云（ACK）、GCP（GKE）、Azure（AKS）；
开源云平台：OpenStack、CloudStack；
其他厂商：DigitalOcean、Hetzner、Linode 等。

五、总结

Kubernetes 自动扩缩容方案覆盖 “Pod 水平、Pod 垂直、集群节点” 三个维度，需根据业务场景选择合适方案：

方案	核心能力	适用场景	依赖组件
HPA	动态调整 Pod 副本数	流量波动大的服务（Web 后端、API 服务）	Metrics Server（基础指标）、Prometheus Adapter（自定义指标）
VPA	动态调整 Pod 资源配置	单 Pod 资源需求波动大的服务（定时任务）	VPA Controller、Metrics Server
KPA	基于并发请求的 Pod 伸缩（支持 0 到 N）	Knative 生态、请求驱动型服务（直播、瞬时流量）	Knative Serving、KPA Controller
CA	动态调整集群节点数量	集群资源长期不足或闲置	云厂商 API（如 AWS EC2、阿里云 ECS）、CA Controller