kubernetesK8s学习笔记第十期集群资源与弹性上篇监控与自动扩缩——Metrics Server HPA本笔记为 Kubernetes 系列第十期聚焦集群资源监控与自动扩缩容。涵盖Metrics Server 部署与使用、Horizontal Pod AutoscalerHPA基于 CPU/内存的自动扩缩容实战、扩容/缩容时间参数详解、HPA vs VPA 对比。所有命令和 YAML 示例均来自课堂笔记经过整理和注释。全文约3900 字包含12 个 YAML 示例、45 命令示例和10 张对比表格是 Kubernetes 集群资源管理的入门指南。更多kubernetes系列知识kubernetes从入门到进阶— Compiled and Authored by Whisky — July 1 st, 2026目录引子从“资源管理的三个层次”说起Metrics ServerHorizontal Pod AutoscalerHPA总结与知识点一览表引子从“资源管理的三个层次”说起在 Kubernetes 集群中资源管理是一个贯穿始终的核心话题。如果把集群比作一个城市节点就是城市中的“建筑”Pod 就是建筑中的“住户”。随着业务的发展住户数量不断增加城市管理者需要面对三个核心问题如何知道每栋建筑住了多少人用了多少水电—— 这是监控问题当某栋建筑住满了如何快速把新住户安排到其他建筑—— 这是调度问题如何防止某个小区占用过多资源影响其他小区—— 这是限制问题围绕这三个问题Kubernetes 集群资源管理形成了三个层次层次问题K8s 组件本期/下期监控层资源用了多少Metrics Server本期上篇扩缩层资源不够怎么办HPA水平扩缩本期上篇约束层如何防止超用ResourceQuota / LimitRange下期下篇本期的学习路径部署 Metrics Server获取资源可见性 ↓ 设置 HPA 自动扩缩容CPU/内存 ↓ 理解扩容/缩容的时间参数一句话总结本期的价值Metrics Server 让你“看得见”资源HPA 让你“管得住”资源——这就是集群资源管理的“眼睛”和“手”。一、Metrics Server1.1 为什么需要 Metrics Server在使用 Kubernetes 的过程中集群管理员和开发者常常面临三个核心问题如何查看节点的 CPU/内存使用情况如何查看 Pod 的资源消耗如何根据资源使用情况自动扩缩容Metrics Server正是为了解决这三个问题而存在的。官方定位Metrics Server 是 Kubernetes 内置自动缩放管道的可扩展、高效的容器资源指标来源。它通过 Kubelet 收集资源指标并通过 Metrics API 将它们公开在 Kubernetes API Server 中供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。核心特点特性说明部署简单单一 Deployment适用于大多数集群采集频率每 15 秒收集一次指标资源消耗每个节点仅需 1 mili 核心 CPU 和 2 MB 内存可扩展性支持多达 5,000 个节点的集群Metrics Server 与其他监控工具的关系工具作用是否替代 Metrics ServerMetrics Server提供 CPU/内存指标给 HPA—Prometheus完整的监控告警体系❌ 不替代可并行使用kubectl top查看实时资源使用✅ 依赖 Metrics Server重要说明Metrics Server不适用于非自动缩放目的。如果需要将指标转发到监控解决方案如 Prometheus应直接从 Kubelet 的/metrics/resource端点采集数据。1.2 部署 Metrics Server下载部署文件rootmaster30:~# wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.1/components.yaml修改部署文件Metrics Server 默认需要验证 Kubelet 的 TLS 证书在某些环境中如使用自签名证书会导致连接失败。我们添加--kubelet-insecure-tls参数跳过 TLS 验证rootmaster30:~# sed -i /metric-resolution/a\ - --kubelet-insecure-tls components.yaml查看所需镜像rootmaster30:~# grep image: components.yamlimage: registry.k8s.io/metrics-server/metrics-server:v0.7.1部署rootmaster30:~# kubectl apply -f components.yamlserviceaccount/metrics-server created clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created clusterrole.rbac.authorization.k8s.io/system:metrics-server created rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created service/metrics-server created deployment.apps/metrics-server created apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created验证部署状态rootmaster30:~# kubectl get pods -n kube-system | grep metricsmetrics-server-6556f8cb6c-78mhq1/1 Running045s确认 Metrics API 可用rootmaster30:~# kubectl get apiservice v1beta1.metrics.k8s.io -o yaml | grep -A3 status1.3 使用 Metrics Server部署完成后可以使用kubectl top命令查看资源使用情况。查看节点资源使用rootmaster30:~# kubectl top nodeNAME CPU(cores)CPU% MEMORY(bytes)MEMORY% master30.whisky.cloud 97m4% 1328Mi35% worker31.whisky.cloud 49m2% 912Mi24% worker32.whisky.cloud 45m2% 926Mi24%输出解读CPU(cores)当前使用的 CPU 核心数毫核为单位CPU%相对节点 CPU 总容量的百分比MEMORY(bytes)当前使用的内存量MEMORY%相对节点内存总容量的百分比查看 Pod 资源使用rootmaster30:~# kubectl top pods -n kube-systemNAME CPU(cores)MEMORY(bytes)calico-kube-controllers-6dfcd885bf-8rhg2 2m 11Mi calico-node-crfr7 27m 57Mi coredns-6d56c8448f-nhjpg 3m 12Mi etcd-master.whisky.cloud 16m 54Mi kube-apiserver-master.whisky.cloud 46m 355Mi metrics-server-6556f8cb6c-78mhq 1m 11Mi单位说明1 CPU 核心 1000mmillicores。例如97m表示使用了 0.097 个 CPU 核心。Mi是 Mebibyte1Mi 1024Ki 1,048,576 字节。二、Horizontal Pod AutoscalerHPA2.1 HPA 概述HPAHorizontal Pod Autoscaler水平 Pod 自动扩缩器是 Kubernetes 中用于根据资源使用情况自动调整 Pod 副本数的控制器。适用场景流量波动大的无状态服务如 Web 应用、API 网关、微服务需要提高并发处理能力、削峰填谷Deployment 和 StatefulSet 都支持核心特点不修改 Pod 配置只调整副本数实时、秒级扩缩支持 CPU、内存、自定义指标如 QPS、延迟支持指标来源metrics.k8s.ioMetrics Server 提供的 CPU/内存指标custom.metrics.k8s.io自定义指标如 Prometheus 接入external.metrics.k8s.io外部指标2.2 扩容与缩容时间参数HPA 的扩容和缩容行为由 kube-controller-manager 的参数控制参数作用默认值--horizontal-pod-autoscaler-sync-period指标采样周期15s--horizontal-pod-autoscaler-initial-readiness-delayPod 启动就绪等待时间30s--horizontal-pod-autoscaler-downscale-stabilization缩容稳定窗口期5m扩容流程每 15 秒采集一次 CPU/内存指标Pod 启动前 30 秒视为“启动中”不参与 HPA 计算扩容冷却时间默认45 秒3 个采样周期缩容流程同样每 15 秒采样一次需要指标持续低于阈值至少5 分钟才会触发缩容每次缩容后再次锁定 5 分钟设计理念扩容要快应对突发流量缩容要慢避免流量抖动导致频繁扩缩。这就像一个“油门”和“刹车”的配合——踩油门要快松刹车要稳。修改参数示例kube-controller-manager 静态 Podrootmaster30:~# vim /etc/kubernetes/manifests/kube-controller-manager.yaml在command段添加spec:containers:-command:-kube-controller-manager---allocate-node-cidrstrue---horizontal-pod-autoscaler-sync-period10s---horizontal-pod-autoscaler-initial-readiness-delay20s---horizontal-pod-autoscaler-downscale-stabilization60s保存退出后静态 Pod 会自动重启生效。2.3 基于 CPU 使用率的 HPA 实验步骤 1创建 Deploymentrootmaster30:~# kubectl create deployment web --imagenginx步骤 2为 Pod 设置资源限制HPA 需要知道 Pod 的资源限制才能计算使用率百分比rootmaster30:~# kubectl edit deployments.apps web添加 resources 配置spec:template:spec:containers:-name:nginximage:nginxresources:limits:cpu:100mmemory:200Mi为什么必须设置 resources.limitsHPA 计算 CPU 使用率的方式是实际使用量 / limit。如果未设置 limitsHPA 无法计算百分比TARGETS 列会显示unknown。步骤 3创建 HPA语法kubectl autoscale deploymentname--minmin--maxmax--cpu-percenttargetrootmaster30:~# kubectl autoscale deployment web --max5 --min2 --cpu-percent80horizontalpodautoscaler.autoscaling/web autoscaled查看 HPArootmaster30:~# kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:0%/80%25230sHPA 生效后Deployment 的副本数会自动从 1 调整到 2minReplicas2。生成 HPA YAML查看完整定义rootmaster30:~# kubectl get hpa web -o yamlapiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:webspec:maxReplicas:5metrics:-resource:name:cputarget:averageUtilization:80type:Utilizationtype:ResourceminReplicas:2scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:web步骤 4创建 Servicerootmaster30:~# kubectl expose deployment web --port80 --target-port80步骤 5开启监控窗口在第一个终端中持续监控 HPA 和 Pod 状态rootmaster30:~# while true; do clear; kubectl get hpa; echo; kubectl get pod; echo; kubectl top pods; sleep 1; done步骤 6施加 CPU 压力在第二个终端中使用abApache Benchmark工具施加压力rootmaster30:~# apt install -y apache2-utilsrootmaster30:~# while true; do ab -n 300000 -c 100 http://10.100.255.92/; sleep 1; done-n 300000总请求数-c 100并发数步骤 7观察自动扩容初始状态CPU 0%2 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:0%/80%2528m开始压测后CPU 负载上升HPA 开始扩容NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:100%/80%2529m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-6gwd2 101m 3Mi web-6dcdc45c94-dvd2m 100m 3MiHPA 检测到 CPU 使用率超过目标值80%开始扩容到 3 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:95%/80%25310m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-2zbmb 93m 3Mi web-6dcdc45c94-6gwd2 100m 3Mi web-6dcdc45c94-dvd2m 90m 3Mi继续扩容到 4 个副本最终到 5 个副本maxReplicasNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:100%/80%25511m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-2zbmb 101m 3Mi web-6dcdc45c94-6gwd2 100m 3Mi web-6dcdc45c94-dvd2m 100m 3Mi web-6dcdc45c94-hpg45 98m 3Mi web-6dcdc45c94-tsjkr 101m 3Mi观察结论随着 CPU 使用率上升HPA 自动增加 Pod 副本数扩容速度约为 30 秒左右创建一个新 PodPod 数量不会超过 maxReplicas5 个停止压力测试后负载降低Pod 数量会逐步减少回 2 个缩容较慢默认 5 分钟稳定窗口步骤 8清理资源rootmaster30:~# kubectl delete hpa webrootmaster30:~# kubectl delete deployment web# svc 保留后续实验使用2.4 基于内存使用率的 HPA 实验基于内存的 HPA 与 CPU 类似但内存压力的模拟方式不同。我们让 Nginx 返回一个超大响应体来消耗内存。步骤 1准备大文件在 Worker 节点上创建 200MB 的大文件[rootworker31 ~]# mkdir /www[rootworker31 ~]# dd if/dev/zero of/www/big.img bs1M count200[rootworker32 ~]# mkdir /www[rootworker32 ~]# dd if/dev/zero of/www/big.img bs1M count200步骤 2创建 Deployment挂载大文件apiVersion:apps/v1kind:Deploymentmetadata:name:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-name:nginximage:nginxports:-containerPort:80volumeMounts:-name:big-filemountPath:/usr/share/nginx/htmlresources:limits:cpu:100mmemory:200Mivolumes:-name:big-filehostPath:path:/wwwrootmaster30:~# kubectl apply -f deployment-web.yaml步骤 3创建 HPA基于内存apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:webspec:minReplicas:2maxReplicas:5scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:webmetrics:-resource:name:memorytarget:type:UtilizationaverageUtilization:60type:Resourcerootmaster30:~# kubectl apply -f hpa-mem.yaml提示内存 HPA 的 target 默认是 Utilization使用率百分比。如果使用AverageValue则指定具体数值如 200Mi。步骤 4查看 HPArootmaster30:~# kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:1%/60%25230s步骤 5施加内存压力rootmaster30:~# while true; do ab -n 300000 -c 100 http://10.99.129.137/big.img; sleep 1; done步骤 6观察自动扩容内存负载上升Every4.0s: kubectl get hpa;echo;kubectltoppods NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:86%/60%25216m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-76pg2 15m 171Mi扩容到 3 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:58%/60%25316m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-4hcm5 5m 3Mi web-88cff78bb-76pg2 15m 171Mi最终扩容到 5 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:58%/60%25516m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-4hcm5 5m 3Mi web-88cff78bb-76pg2 15m 171Mi web-88cff78bb-ws6t4 1m 3Mi web-88cff78bb-t4q2p 1m 3Mi观察结论内存指标采集同样需要 Metrics Server内存 HPA 的扩容逻辑与 CPU 相同新启动的 Pod 内存使用量很低整体平均使用率下降步骤 7清理资源rootmaster30:~# kubectl delete hpa webrootmaster30:~# kubectl delete deployment webrootmaster30:~# kubectl delete svc web2.5 HPA vs VPA 对比VPAVertical Pod Autoscaler是另一种自动扩缩容方式与 HPA 形成互补。对比项HPA水平扩缩容VPA垂直扩缩容扩缩方式增加/减少 Pod 数量调整 CPU/内存 request/limit是否重启 Pod❌ 不重启✅ 一般需要重启适合负载流量波动大资源配置不合理生效速度快秒级慢需要重启稳定性高中生产使用非常普遍较少能否一起开不能同时开会冲突—支持资源CPU、内存、自定义CPU、内存总结HPA 管理“数量”VPA 管理“大小”。HPA 适合应对流量突发VPA 适合优化资源配置。两者各有侧重但不能同时开启否则会出现调度冲突。三、总结与知识点一览表3.1 回到“资源管理的三个层次”在开篇的引子中我们提出了资源管理的三个层次。现在让我们回顾本期学到的内容如何对应这三个层次层次问题K8s 组件本期内容监控层资源用了多少Metrics Server✅ kubectl top 查看节点/Pod 资源扩缩层资源不够怎么办HPA✅ 基于 CPU/内存自动扩缩容约束层如何防止超用ResourceQuota / LimitRange下期讲解一句话回顾本期我们通过 Metrics Server 获得了资源“可见性”通过 HPA 实现了资源“自动调配”——这就是集群资源管理的“监控”与“扩缩”两大核心能力。3.2 核心知识点汇总模块核心概念关键命令Metrics Server资源指标采集kubectl top node,kubectl top podHPA自动水平扩缩容kubectl autoscale,kubectl get hpaCPU HPA基于 CPU 使用率--cpu-percent80内存 HPA基于内存使用率averageUtilization: 60扩容参数sync-period / readiness-delay默认 15s / 30s缩容参数downscale-stabilization默认 5m3.3 实验对比CPU vs 内存扩缩对比项CPU 扩缩实验内存扩缩实验压测工具ab并发请求ab下载大文件关键条件设置 CPU limits挂载大文件hostPathHPA targetaverageUtilization: 80averageUtilization: 60触发条件CPU 使用率超过 80%内存使用率超过 60%扩容速度~30s 创建一个 Pod~30s 创建一个 PodmaxReplicas553.4 常用命令速查操作命令查看节点资源kubectl top node查看 Pod 资源kubectl top pod -n ns创建 HPACPUkubectl autoscale deployment name --min2 --max5 --cpu-percent80创建 HPA内存 YAMLkubectl apply -f hpa-mem.yaml查看 HPAkubectl get hpa查看 HPA 详情kubectl describe hpa name删除 HPAkubectl delete hpa name3.5 常见错误排查错误现象可能原因解决方法kubectl top报错Metrics Server 未部署部署 Metrics ServerHPA TARGETS 为unknownPod 未设置 resources.limits为 Pod 配置 CPU/内存限制HPA TARGETS 为unreachableMetrics Server 与 Kubelet 连接失败检查--kubelet-insecure-tls参数扩容速度慢默认采样周期 15s调整--horizontal-pod-autoscaler-sync-period缩容不触发默认稳定窗口 5 分钟等待或调整--horizontal-pod-autoscaler-downscale-stabilization扩容超过 maxReplicasmaxReplicas 设置过低修改 HPA 的spec.maxReplicas压测后 HPA 不触发未创建 Service 或 Service 不可访问确认kubectl get svc和访问路径下一期预告KubernetesK8s学习笔记第十一期集群资源与弹性下篇资源配额与限制——ResourceQuota LimitRange。涵盖ResourceQuota 命名空间资源配额、LimitRange 容器资源默认值与限制范围、request/limit 的配置实验。— Compiled and Authored by Whisky — July 1 st, 2026
kubernetes（K8s）学习笔记（第十期）：集群资源与弹性（上篇）：监控与自动扩缩——Metrics Server + HPA
kubernetesK8s学习笔记第十期集群资源与弹性上篇监控与自动扩缩——Metrics Server HPA本笔记为 Kubernetes 系列第十期聚焦集群资源监控与自动扩缩容。涵盖Metrics Server 部署与使用、Horizontal Pod AutoscalerHPA基于 CPU/内存的自动扩缩容实战、扩容/缩容时间参数详解、HPA vs VPA 对比。所有命令和 YAML 示例均来自课堂笔记经过整理和注释。全文约3900 字包含12 个 YAML 示例、45 命令示例和10 张对比表格是 Kubernetes 集群资源管理的入门指南。更多kubernetes系列知识kubernetes从入门到进阶— Compiled and Authored by Whisky — July 1 st, 2026目录引子从“资源管理的三个层次”说起Metrics ServerHorizontal Pod AutoscalerHPA总结与知识点一览表引子从“资源管理的三个层次”说起在 Kubernetes 集群中资源管理是一个贯穿始终的核心话题。如果把集群比作一个城市节点就是城市中的“建筑”Pod 就是建筑中的“住户”。随着业务的发展住户数量不断增加城市管理者需要面对三个核心问题如何知道每栋建筑住了多少人用了多少水电—— 这是监控问题当某栋建筑住满了如何快速把新住户安排到其他建筑—— 这是调度问题如何防止某个小区占用过多资源影响其他小区—— 这是限制问题围绕这三个问题Kubernetes 集群资源管理形成了三个层次层次问题K8s 组件本期/下期监控层资源用了多少Metrics Server本期上篇扩缩层资源不够怎么办HPA水平扩缩本期上篇约束层如何防止超用ResourceQuota / LimitRange下期下篇本期的学习路径部署 Metrics Server获取资源可见性 ↓ 设置 HPA 自动扩缩容CPU/内存 ↓ 理解扩容/缩容的时间参数一句话总结本期的价值Metrics Server 让你“看得见”资源HPA 让你“管得住”资源——这就是集群资源管理的“眼睛”和“手”。一、Metrics Server1.1 为什么需要 Metrics Server在使用 Kubernetes 的过程中集群管理员和开发者常常面临三个核心问题如何查看节点的 CPU/内存使用情况如何查看 Pod 的资源消耗如何根据资源使用情况自动扩缩容Metrics Server正是为了解决这三个问题而存在的。官方定位Metrics Server 是 Kubernetes 内置自动缩放管道的可扩展、高效的容器资源指标来源。它通过 Kubelet 收集资源指标并通过 Metrics API 将它们公开在 Kubernetes API Server 中供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。核心特点特性说明部署简单单一 Deployment适用于大多数集群采集频率每 15 秒收集一次指标资源消耗每个节点仅需 1 mili 核心 CPU 和 2 MB 内存可扩展性支持多达 5,000 个节点的集群Metrics Server 与其他监控工具的关系工具作用是否替代 Metrics ServerMetrics Server提供 CPU/内存指标给 HPA—Prometheus完整的监控告警体系❌ 不替代可并行使用kubectl top查看实时资源使用✅ 依赖 Metrics Server重要说明Metrics Server不适用于非自动缩放目的。如果需要将指标转发到监控解决方案如 Prometheus应直接从 Kubelet 的/metrics/resource端点采集数据。1.2 部署 Metrics Server下载部署文件rootmaster30:~# wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.1/components.yaml修改部署文件Metrics Server 默认需要验证 Kubelet 的 TLS 证书在某些环境中如使用自签名证书会导致连接失败。我们添加--kubelet-insecure-tls参数跳过 TLS 验证rootmaster30:~# sed -i /metric-resolution/a\ - --kubelet-insecure-tls components.yaml查看所需镜像rootmaster30:~# grep image: components.yamlimage: registry.k8s.io/metrics-server/metrics-server:v0.7.1部署rootmaster30:~# kubectl apply -f components.yamlserviceaccount/metrics-server created clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created clusterrole.rbac.authorization.k8s.io/system:metrics-server created rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created service/metrics-server created deployment.apps/metrics-server created apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created验证部署状态rootmaster30:~# kubectl get pods -n kube-system | grep metricsmetrics-server-6556f8cb6c-78mhq1/1 Running045s确认 Metrics API 可用rootmaster30:~# kubectl get apiservice v1beta1.metrics.k8s.io -o yaml | grep -A3 status1.3 使用 Metrics Server部署完成后可以使用kubectl top命令查看资源使用情况。查看节点资源使用rootmaster30:~# kubectl top nodeNAME CPU(cores)CPU% MEMORY(bytes)MEMORY% master30.whisky.cloud 97m4% 1328Mi35% worker31.whisky.cloud 49m2% 912Mi24% worker32.whisky.cloud 45m2% 926Mi24%输出解读CPU(cores)当前使用的 CPU 核心数毫核为单位CPU%相对节点 CPU 总容量的百分比MEMORY(bytes)当前使用的内存量MEMORY%相对节点内存总容量的百分比查看 Pod 资源使用rootmaster30:~# kubectl top pods -n kube-systemNAME CPU(cores)MEMORY(bytes)calico-kube-controllers-6dfcd885bf-8rhg2 2m 11Mi calico-node-crfr7 27m 57Mi coredns-6d56c8448f-nhjpg 3m 12Mi etcd-master.whisky.cloud 16m 54Mi kube-apiserver-master.whisky.cloud 46m 355Mi metrics-server-6556f8cb6c-78mhq 1m 11Mi单位说明1 CPU 核心 1000mmillicores。例如97m表示使用了 0.097 个 CPU 核心。Mi是 Mebibyte1Mi 1024Ki 1,048,576 字节。二、Horizontal Pod AutoscalerHPA2.1 HPA 概述HPAHorizontal Pod Autoscaler水平 Pod 自动扩缩器是 Kubernetes 中用于根据资源使用情况自动调整 Pod 副本数的控制器。适用场景流量波动大的无状态服务如 Web 应用、API 网关、微服务需要提高并发处理能力、削峰填谷Deployment 和 StatefulSet 都支持核心特点不修改 Pod 配置只调整副本数实时、秒级扩缩支持 CPU、内存、自定义指标如 QPS、延迟支持指标来源metrics.k8s.ioMetrics Server 提供的 CPU/内存指标custom.metrics.k8s.io自定义指标如 Prometheus 接入external.metrics.k8s.io外部指标2.2 扩容与缩容时间参数HPA 的扩容和缩容行为由 kube-controller-manager 的参数控制参数作用默认值--horizontal-pod-autoscaler-sync-period指标采样周期15s--horizontal-pod-autoscaler-initial-readiness-delayPod 启动就绪等待时间30s--horizontal-pod-autoscaler-downscale-stabilization缩容稳定窗口期5m扩容流程每 15 秒采集一次 CPU/内存指标Pod 启动前 30 秒视为“启动中”不参与 HPA 计算扩容冷却时间默认45 秒3 个采样周期缩容流程同样每 15 秒采样一次需要指标持续低于阈值至少5 分钟才会触发缩容每次缩容后再次锁定 5 分钟设计理念扩容要快应对突发流量缩容要慢避免流量抖动导致频繁扩缩。这就像一个“油门”和“刹车”的配合——踩油门要快松刹车要稳。修改参数示例kube-controller-manager 静态 Podrootmaster30:~# vim /etc/kubernetes/manifests/kube-controller-manager.yaml在command段添加spec:containers:-command:-kube-controller-manager---allocate-node-cidrstrue---horizontal-pod-autoscaler-sync-period10s---horizontal-pod-autoscaler-initial-readiness-delay20s---horizontal-pod-autoscaler-downscale-stabilization60s保存退出后静态 Pod 会自动重启生效。2.3 基于 CPU 使用率的 HPA 实验步骤 1创建 Deploymentrootmaster30:~# kubectl create deployment web --imagenginx步骤 2为 Pod 设置资源限制HPA 需要知道 Pod 的资源限制才能计算使用率百分比rootmaster30:~# kubectl edit deployments.apps web添加 resources 配置spec:template:spec:containers:-name:nginximage:nginxresources:limits:cpu:100mmemory:200Mi为什么必须设置 resources.limitsHPA 计算 CPU 使用率的方式是实际使用量 / limit。如果未设置 limitsHPA 无法计算百分比TARGETS 列会显示unknown。步骤 3创建 HPA语法kubectl autoscale deploymentname--minmin--maxmax--cpu-percenttargetrootmaster30:~# kubectl autoscale deployment web --max5 --min2 --cpu-percent80horizontalpodautoscaler.autoscaling/web autoscaled查看 HPArootmaster30:~# kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:0%/80%25230sHPA 生效后Deployment 的副本数会自动从 1 调整到 2minReplicas2。生成 HPA YAML查看完整定义rootmaster30:~# kubectl get hpa web -o yamlapiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:webspec:maxReplicas:5metrics:-resource:name:cputarget:averageUtilization:80type:Utilizationtype:ResourceminReplicas:2scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:web步骤 4创建 Servicerootmaster30:~# kubectl expose deployment web --port80 --target-port80步骤 5开启监控窗口在第一个终端中持续监控 HPA 和 Pod 状态rootmaster30:~# while true; do clear; kubectl get hpa; echo; kubectl get pod; echo; kubectl top pods; sleep 1; done步骤 6施加 CPU 压力在第二个终端中使用abApache Benchmark工具施加压力rootmaster30:~# apt install -y apache2-utilsrootmaster30:~# while true; do ab -n 300000 -c 100 http://10.100.255.92/; sleep 1; done-n 300000总请求数-c 100并发数步骤 7观察自动扩容初始状态CPU 0%2 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:0%/80%2528m开始压测后CPU 负载上升HPA 开始扩容NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:100%/80%2529m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-6gwd2 101m 3Mi web-6dcdc45c94-dvd2m 100m 3MiHPA 检测到 CPU 使用率超过目标值80%开始扩容到 3 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:95%/80%25310m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-2zbmb 93m 3Mi web-6dcdc45c94-6gwd2 100m 3Mi web-6dcdc45c94-dvd2m 90m 3Mi继续扩容到 4 个副本最终到 5 个副本maxReplicasNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web cpu:100%/80%25511m NAME CPU(cores)MEMORY(bytes)web-6dcdc45c94-2zbmb 101m 3Mi web-6dcdc45c94-6gwd2 100m 3Mi web-6dcdc45c94-dvd2m 100m 3Mi web-6dcdc45c94-hpg45 98m 3Mi web-6dcdc45c94-tsjkr 101m 3Mi观察结论随着 CPU 使用率上升HPA 自动增加 Pod 副本数扩容速度约为 30 秒左右创建一个新 PodPod 数量不会超过 maxReplicas5 个停止压力测试后负载降低Pod 数量会逐步减少回 2 个缩容较慢默认 5 分钟稳定窗口步骤 8清理资源rootmaster30:~# kubectl delete hpa webrootmaster30:~# kubectl delete deployment web# svc 保留后续实验使用2.4 基于内存使用率的 HPA 实验基于内存的 HPA 与 CPU 类似但内存压力的模拟方式不同。我们让 Nginx 返回一个超大响应体来消耗内存。步骤 1准备大文件在 Worker 节点上创建 200MB 的大文件[rootworker31 ~]# mkdir /www[rootworker31 ~]# dd if/dev/zero of/www/big.img bs1M count200[rootworker32 ~]# mkdir /www[rootworker32 ~]# dd if/dev/zero of/www/big.img bs1M count200步骤 2创建 Deployment挂载大文件apiVersion:apps/v1kind:Deploymentmetadata:name:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-name:nginximage:nginxports:-containerPort:80volumeMounts:-name:big-filemountPath:/usr/share/nginx/htmlresources:limits:cpu:100mmemory:200Mivolumes:-name:big-filehostPath:path:/wwwrootmaster30:~# kubectl apply -f deployment-web.yaml步骤 3创建 HPA基于内存apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:webspec:minReplicas:2maxReplicas:5scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:webmetrics:-resource:name:memorytarget:type:UtilizationaverageUtilization:60type:Resourcerootmaster30:~# kubectl apply -f hpa-mem.yaml提示内存 HPA 的 target 默认是 Utilization使用率百分比。如果使用AverageValue则指定具体数值如 200Mi。步骤 4查看 HPArootmaster30:~# kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:1%/60%25230s步骤 5施加内存压力rootmaster30:~# while true; do ab -n 300000 -c 100 http://10.99.129.137/big.img; sleep 1; done步骤 6观察自动扩容内存负载上升Every4.0s: kubectl get hpa;echo;kubectltoppods NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:86%/60%25216m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-76pg2 15m 171Mi扩容到 3 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:58%/60%25316m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-4hcm5 5m 3Mi web-88cff78bb-76pg2 15m 171Mi最终扩容到 5 个副本NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE web Deployment/web memory:58%/60%25516m NAME CPU(cores)MEMORY(bytes)web-88cff78bb-2b7vh 15m 174Mi web-88cff78bb-4hcm5 5m 3Mi web-88cff78bb-76pg2 15m 171Mi web-88cff78bb-ws6t4 1m 3Mi web-88cff78bb-t4q2p 1m 3Mi观察结论内存指标采集同样需要 Metrics Server内存 HPA 的扩容逻辑与 CPU 相同新启动的 Pod 内存使用量很低整体平均使用率下降步骤 7清理资源rootmaster30:~# kubectl delete hpa webrootmaster30:~# kubectl delete deployment webrootmaster30:~# kubectl delete svc web2.5 HPA vs VPA 对比VPAVertical Pod Autoscaler是另一种自动扩缩容方式与 HPA 形成互补。对比项HPA水平扩缩容VPA垂直扩缩容扩缩方式增加/减少 Pod 数量调整 CPU/内存 request/limit是否重启 Pod❌ 不重启✅ 一般需要重启适合负载流量波动大资源配置不合理生效速度快秒级慢需要重启稳定性高中生产使用非常普遍较少能否一起开不能同时开会冲突—支持资源CPU、内存、自定义CPU、内存总结HPA 管理“数量”VPA 管理“大小”。HPA 适合应对流量突发VPA 适合优化资源配置。两者各有侧重但不能同时开启否则会出现调度冲突。三、总结与知识点一览表3.1 回到“资源管理的三个层次”在开篇的引子中我们提出了资源管理的三个层次。现在让我们回顾本期学到的内容如何对应这三个层次层次问题K8s 组件本期内容监控层资源用了多少Metrics Server✅ kubectl top 查看节点/Pod 资源扩缩层资源不够怎么办HPA✅ 基于 CPU/内存自动扩缩容约束层如何防止超用ResourceQuota / LimitRange下期讲解一句话回顾本期我们通过 Metrics Server 获得了资源“可见性”通过 HPA 实现了资源“自动调配”——这就是集群资源管理的“监控”与“扩缩”两大核心能力。3.2 核心知识点汇总模块核心概念关键命令Metrics Server资源指标采集kubectl top node,kubectl top podHPA自动水平扩缩容kubectl autoscale,kubectl get hpaCPU HPA基于 CPU 使用率--cpu-percent80内存 HPA基于内存使用率averageUtilization: 60扩容参数sync-period / readiness-delay默认 15s / 30s缩容参数downscale-stabilization默认 5m3.3 实验对比CPU vs 内存扩缩对比项CPU 扩缩实验内存扩缩实验压测工具ab并发请求ab下载大文件关键条件设置 CPU limits挂载大文件hostPathHPA targetaverageUtilization: 80averageUtilization: 60触发条件CPU 使用率超过 80%内存使用率超过 60%扩容速度~30s 创建一个 Pod~30s 创建一个 PodmaxReplicas553.4 常用命令速查操作命令查看节点资源kubectl top node查看 Pod 资源kubectl top pod -n ns创建 HPACPUkubectl autoscale deployment name --min2 --max5 --cpu-percent80创建 HPA内存 YAMLkubectl apply -f hpa-mem.yaml查看 HPAkubectl get hpa查看 HPA 详情kubectl describe hpa name删除 HPAkubectl delete hpa name3.5 常见错误排查错误现象可能原因解决方法kubectl top报错Metrics Server 未部署部署 Metrics ServerHPA TARGETS 为unknownPod 未设置 resources.limits为 Pod 配置 CPU/内存限制HPA TARGETS 为unreachableMetrics Server 与 Kubelet 连接失败检查--kubelet-insecure-tls参数扩容速度慢默认采样周期 15s调整--horizontal-pod-autoscaler-sync-period缩容不触发默认稳定窗口 5 分钟等待或调整--horizontal-pod-autoscaler-downscale-stabilization扩容超过 maxReplicasmaxReplicas 设置过低修改 HPA 的spec.maxReplicas压测后 HPA 不触发未创建 Service 或 Service 不可访问确认kubectl get svc和访问路径下一期预告KubernetesK8s学习笔记第十一期集群资源与弹性下篇资源配额与限制——ResourceQuota LimitRange。涵盖ResourceQuota 命名空间资源配额、LimitRange 容器资源默认值与限制范围、request/limit 的配置实验。— Compiled and Authored by Whisky — July 1 st, 2026
