<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>HorizontalPodAutoscaler · XB 现场笔记</title><link>https://www.xbcatm.com/zh/tags/horizontalpodautoscaler/</link><description>基于 HTTP、DNS、TLS、Caddy、SSH、发布与恢复的可复现运维现场笔记。</description><generator>Hugo</generator><language>zh-CN</language><atom:link href="https://www.xbcatm.com/zh/tags/horizontalpodautoscaler/index.xml" rel="self" type="application/rss+xml"/><item><title>HPA 按负载缩放 Deployment 的副本</title><link>https://www.xbcatm.com/zh/posts/kubernetes-hpa-autoscale-workloads/</link><pubDate>Wed, 11 Aug 2027 00:00:00 +0000</pubDate><guid>https://www.xbcatm.com/zh/posts/kubernetes-hpa-autoscale-workloads/</guid><description>横向自动伸缩器盯一个指标，把副本数量调到目标区间内。</description><content:encoded>&lt;p&gt;HorizontalPodAutoscaler 是反馈控制器，不是容量规划器，默认同步间隔为十五秒。根据配置，它读取资源、自定义或外部指标，再更新工作负载的 scale 子资源。基本计算为 desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)，之后还要考虑缺失数据、就绪状态、容忍度、稳定窗口及上下界，不能只靠这一行公式预测全部实际行为。&lt;/p&gt;
&lt;p&gt;一份看起来正确的 HPA 对象，不证明容量必然及时到位。指标可用性、请求、副本上限、调度及应用启动都会影响结果。应分别查看建议副本数与真实就绪容量；提高期望数量不会制造新节点，也不能自动修好受阻发布。判断伸缩是否有效，必须跟踪从指标到应用接流量的整段过程。&lt;/p&gt;
&lt;h2 id="比值与死区"&gt;比值与死区&lt;/h2&gt;
&lt;p&gt;CPU 利用率目标把实际 CPU 用量与相关请求比较，得到百分比，目标本身也是百分比。如果每个 Pod 只有一个容器，都请求 200m，目标为百分之六十，那么每 Pod 120m 是便于理解的简化等价值。它不是异构 Pod 或所有指标类型通用的分母；多个容器和不同请求会改变聚合结果。&lt;/p&gt;
&lt;p&gt;默认容忍度为一附近的 0.1。应把它理解为控制死区，而不是承诺 132m 永不伸缩、133m 必然动作。指标聚合、整数利用率、就绪状态及实现中的算术都会影响边界。忽略其他修正时，三个副本以 160m 对比 120m 目标，会建议四个副本；舍入、速率策略与最终能否调度仍需分别观察，不能从一个毫核数字直接推出真实扩容时刻。&lt;/p&gt;
&lt;h2 id="缺失指标与一票否决"&gt;缺失指标与一票否决&lt;/h2&gt;
&lt;p&gt;缺失 Pod 指标采用保守处理，假定的贡献会削弱建议扩容或缩容的幅度。CPU 对尚未就绪的 Pod 还有额外处理，涉及可配置的就绪延迟与初始化窗口。这些规则围绕启动采样及就绪变化，不表示所有 Pod 都一律被忽略整整五分钟。诊断时应查看实际采样和状态时间，不能把默认窗口当成一个简单倒计时。&lt;/p&gt;
&lt;p&gt;CPU 利用率计算需要相关资源请求；即使 kubectl top 能报告用量，缺失 request 仍可能让该指标不可计算。配置多个指标时，HPA 选择最大的建议副本数；一个不可用指标可能阻止缩容，另一个有效指标却仍能支持扩容。因此，缺一个来源不代表整个控制器必然停止，必须结合每个指标的结果和状态条件解释。&lt;/p&gt;
&lt;h2 id="稳定窗口与速率限制"&gt;稳定窗口与速率限制&lt;/h2&gt;
&lt;p&gt;默认缩容会考虑五分钟建议窗口，并选取其中仍相关的最高建议，以减轻振荡。这不是从外部负载曲线回落开始严格等待五分钟的保证。建议记录、当前副本、上下界和行为配置共同决定何时缩减。默认扩容稳定窗口为零，但用户可以修改行为；没有稳定窗口也不表示完全没有同步、采样和启动延迟。&lt;/p&gt;
&lt;p&gt;默认扩容速率策略允许十五秒内增加四个 Pod 或当前数量的一倍，取允许变化较大的策略。默认缩容策略可允许在其周期内全部减少，但仍受到稳定窗口和最小副本数限制。这是允许速率，不是自动按一、五、十不断增长的命令。指标必须要求相应扩容，maxReplicas 仍会封顶，新增副本还要经过实际调度与就绪过程。&lt;/p&gt;
&lt;h2 id="坏掉的样子"&gt;坏掉的样子&lt;/h2&gt;
&lt;p&gt;利用率 unknown 可能来自缺失请求、指标不可用、授权问题或其他获取与计算错误。应读取 ScalingActive 及其原因，不能把 unknown 直接当作没有 CPU 样本的证明。需要检查所有相关容器，只查第一个容器不能确定整份 Pod 的分母；同时还要核对准入默认值与实际 HPA 指标类型。&lt;/p&gt;
&lt;p&gt;达到 maxReplicas 的工作负载，即使控制器正确执行配置，也可能继续过载。ScalingLimited 能说明数量受限，但容量规划还需要节点空间、启动延迟和下游承载能力。提高上限可能只制造更多 Pending Pod，或压垮共享依赖。宣布自动伸缩成功前，应比较期望副本、可用副本与服务延迟，不能只看到 desired 数字增加就认为问题解决。&lt;/p&gt;
&lt;h2 id="快速验证"&gt;快速验证&lt;/h2&gt;
&lt;p&gt;以下保留的只读诊断本轮没有重新执行。请明确选择获准测试集群和命名空间，并把简略输出与完整 HPA、所有相关容器一起核对。&lt;/p&gt;
&lt;p&gt;确认指标存在、分母存在，以及控制器到底决定了什么：&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;kubectl get hpa web -o wide
kubectl top pods -l app=web
kubectl get deploy web -o jsonpath=&amp;#39;{.spec.template.spec.containers[0].resources.requests.cpu}{&amp;#34;\n&amp;#34;}&amp;#39;
kubectl get hpa web -o jsonpath=&amp;#39;{range .status.conditions[*]}{.type}={.status} {.reason}{&amp;#34;\n&amp;#34;}{end}&amp;#39;
kubectl describe hpa web | sed -n &amp;#39;/Events/,$p&amp;#39;
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;第一行给出当前利用率对目标利用率；这一列显示 &lt;code&gt;&amp;lt;unknown&amp;gt;&lt;/code&gt;，说明所需值未能建立，并不必然表示原始用量样本缺失。第三条在没有 CPU request 时什么都不打印，而这正是第二条能跑通、HPA 却仍拒绝伸缩的常见原因。最后两条给出状况原因和 &lt;code&gt;FailedGetResourceMetric&lt;/code&gt; 事件，真正的解释在那里。&lt;/p&gt;
&lt;h2 id="来源"&gt;来源&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/"&gt;Horizontal Pod Autoscaling&lt;/a&gt;，算法、容忍度、缺失指标处理、稳定窗口与默认策略，已核验 2026-10-15。&lt;/li&gt;
&lt;li&gt;&lt;a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/"&gt;HPA walkthrough&lt;/a&gt;，对 metrics-server 与 requests 的依赖，已核验 2026-10-15。&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/kubernetes-sigs/metrics-server"&gt;metrics-server&lt;/a&gt;，HPA 读取的 resource metrics API 实现，已核验 2026-10-15。&lt;/li&gt;
&lt;/ul&gt;</content:encoded></item></channel></rss>