删除 HPA 后副本数没恢复：重新接管 Deployment 的 replicas
删除 HPA 后 Pod 仍保持扩容规模时，核对目标 Deployment、其他规模写入方与部署清单，再安排缩容和副本管理权交接。
Deployment 原本运行 1 个副本，HPA 把它扩到 11 个；删除 HPA 后，Pod 仍保持 11 个。这个现象通常不需要通过重启控制器修复。HPA 写入的是目标工作负载的期望规模，删除 HPA 会停止它的后续调节，不会自动恢复启用前的副本数。
以下针对 HPA 的 scaleTargetRef 指向 Deployment 的情况。先确认业务可以缩容，再把副本数交回实际负责部署的清单、GitOps 或人工管理流程；不要直接修改 Deployment 所管理的 ReplicaSet。
先找出副本数由谁管理
在同一命名空间保存 HPA 和目标 Deployment 的配置。以下名称是示例，尚未删除 HPA 时可以先读它的目标：
kubectl -n team-app get hpa web-autoscaler -o yaml
kubectl -n team-app get deployment web -o yaml
kubectl -n team-app get hpa
核对 HPA 的 scaleTargetRef.kind、name 和目标对象的 spec.replicas。HPA 当前推荐数量、Deployment 期望副本数、实际存在的 Pod 数和 Ready 数属于不同信息，不能只数 Pod 就认定某个控制器仍在扩容。
HPA 通过目标对象的 scale 子资源调节规模。目标是 Deployment 时，Deployment 再管理 ReplicaSet 和 Pod。删除 HPA 不会删除 Deployment，也不会把已经写入的规模当成临时补丁撤销。minReplicas 是自动伸缩期间的下限，同样不是停用 HPA 后的恢复值。
如果 HPA 已不存在，但 spec.replicas 又被改回较大的数量，检查其他 HPA 是否指向同一对象，以及部署平台、Helm、GitOps 或脚本是否还在写入这个字段。比对 managedFields、保存的清单和平台同步记录有助于确定写入方；单次查看字段值不能证明以后不会再次被覆盖。
停用自动伸缩时，明确写入新的目标规模
决定恢复到 1 个副本前，需要确认当前负载、可用性要求以及终止中的任务。原来的数量只说明历史配置，不保证能承担现在的流量。缩容会终止部分 Pod，连接、内存中的任务和没有外部持久化的状态可能受到影响。
确认缩容条件后，保存 HPA 定义、部署清单及当前规模，在负责部署的配置中明确新的 spec.replicas，并停用自动生成或同步 HPA 的配置。如果 HPA 由部署工具管理，只手动删 Kubernetes 对象可能会被下一次同步重建。
对于已经停止其他规模写入、由人工管理的 Deployment，可以在删除目标 HPA 后缩容。以下仅示例操作对象和目标数量，11 与 1 都不能直接套到其他业务：
kubectl -n team-app delete hpa web-autoscaler
kubectl -n team-app scale deployment web --replicas=1
若由 GitOps 管理，应在其受控配置中完成同样的管理权交接，避免临时 scale 与仓库清单相互覆盖。也不要缩放某个旧 ReplicaSet：Deployment 控制器会继续按自身的期望状态协调，直接改下层对象不能稳定表达这个工作负载的规模。
不要用删除 replicas 字段代替恢复操作
启用 HPA 时，通常建议让部署清单不再反复写 spec.replicas，否则一次 apply 可能先把规模拉回清单里的固定值，随后 HPA 又重新调整。
但从已有清单中删除这个字段也需要处理字段管理方式。对于之前通过客户端 apply 管理 replicas 的对象，直接删除字段并 apply，可能出现一次回到默认 1 个副本的缩容。默认值不等于业务选定的恢复值。继续使用 HPA 时，应按客户端 apply 的历史配置或服务端 apply 的字段所有权完成迁移；停用 HPA 后采用固定规模，则在正式部署配置中明确所需数量。
因此，不建议为了把 11 恢复成 1 而随意删字段、重新创建 Deployment，或删掉全部 Pod。后两项还会引入不必要的重建，且不能保证规模写入方已经停止。
检查规模是否保持稳定，业务是否还能承受负载
修改后查看 Deployment 的期望副本数、Ready 数、不可用数量与最近事件，并从实际业务入口观察错误率和处理能力。缩容中的 Pod 可能在终止宽限期内继续存在，应区分正在终止的对象与仍被期望运行的副本。
完成一次正常部署同步后再检查规模。如果 replicas 被改回，继续查写入方；若目标数量保持稳定但业务能力不足，应调整固定规模或恢复自动伸缩，而不是把 Pod 少了当作验收成功。
回退时，可先恢复经过容量确认的规模，再恢复保存的 HPA 定义和对应部署配置，确保没有多个流程争用 replicas。恢复 HPA 后，它仍会按指标、上下限和伸缩行为继续调节，不保证保持启用前的某一个数量。缩容已经丢失的临时状态也不会因副本扩回去而自动回来。