在 Kubernetes 里跑多实例应用，核心并不是简单地把同一个镜像启动多次，而是让调度器、服务发现和负载均衡共同配合，保证任意时刻都有足够且健康的副本处理请求，并在压力变化时自动调整规模。本文围绕 Deployment 与 HorizontalPodAutoscaler 两个对象，说明从静态多副本到动态扩缩的完整路径。
用 Deployment 稳定运行多实例应用
Deployment 是 Kubernetes 中管理无状态多实例应用最常用的控制器。它通过 ReplicaSet 保证集群中始终存在指定数量的 Pod 副本，当某个节点宕机或 Pod 被误删时，控制器会迅速在其它节点上重建，使实际副本数向声明值收敛。我们在编写 Deployment 时，最核心的字段是 spec.replicas 和 spec.template，前者定义期望副本数，后者描述 Pod 的容器与配置。
只设置副本数并不能算“稳”。如果新启动的容器需要几秒完成缓存预热，而服务注册中心已把流量打过来，就会出现大量超时。因此必须在模板中配置就绪探针（readinessProbe），例如 HTTP 探针访问 /healthz，只有返回 200 时，Endpoint 控制器才会把该 Pod 的 IP 加入 Service 的后端列表。下面给出一个基础的 Deployment 示例，其中运行了三个副本并带就绪检查：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 5
periodSeconds: 10
上面的配置虽然写死了三个副本，但已经具备多实例容错能力。若想手动扩缩，只需修改 replicas 或执行 kubectl scale deployment web-app --replicas=5。不过手动方式依赖人盯监控，不适合生产峰值场景，这就需要后面的自动扩缩机制。
基于指标的自动扩缩原理与配置
HorizontalPodAutoscaler（简称 HPA）负责根据观测指标动态调整 Deployment 的副本数。其底层逻辑是：每隔一个同步周期（默认 15 秒），从 Metrics Server 或自定义指标适配器拉取当前 Pod 的平均资源使用率，再对照用户设定的目标值，按“当前副本数 × 当前使用率 ÷ 目标使用率”向上取整算出期望副本数。比如三个 Pod 平均 CPU 用了 80%，目标是 40%，则期望副本为 3×80%÷40%=6。
配置 HPA 最常见的是基于 CPU 利用率。集群需先部署 Metrics Server，使 kubectl top pod 能取到数据。注意 HPA 只能缩放到 spec.replicas 范围之外，但受 minReplicas 与 maxReplicas 约束。以下示例让 web-app 在平均 CPU 超 50% 时扩容，最少 2 个、最多 10 个副本：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
除了 CPU，内存指标也常被使用，写法类似只需把 name 换成 memory。但内存不同于 CPU，下降慢且释放不确定，单纯按内存扩缩容易滞后。更精细的做法是接 Prometheus 适配器，用每秒请求数（QPS）做自定义指标，这样扩缩直接跟随业务压力而非间接资源。无论哪种指标，都要给容器设好 resources.requests，否则 HPA 无法计算使用率百分比。
资源设置与扩缩振荡的避坑实践
很多团队在接入 HPA 后发现副本数反复横跳：刚扩到 8 个，下一周期又缩到 4 个，如此循环既拖慢响应又增加调度开销。根源往往是资源请求设得太低，导致使用率轻微波动就触发阈值；或是没有配置缩容稳定窗口。从 Kubernetes 1.18 起，HPA 行为可用 behavior 字段细调，比如规定缩容时每次最多减少 1 个副本，且缩容前等待 300 秒，能显著抑制抖动。
另一个常见误区是只设限制（limits）不设请求（requests）。若漏了 requests，调度器以为 Pod 占用极小，会把大量副本堆到同一节点，真正来流量时节点资源争抢，Pod 被驱逐反而更不稳定。正确姿势是 requests 贴近真实均值、limits 留一点突发余量。示例如下，在容器里明确声明：
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
最后提醒，多实例应用扩缩不是孤立动作。Service 的会话保持、Pod 优雅终止（preStop 钩子）、以及应用自身无状态化（不写本地磁盘会话）都直接影响扩缩质量。把这些都理顺后，再配合 HPA 的指标与行为调优，才能在 Kubernetes 集群中既跑得稳又花得省。
KubernetesHorizontalPodAutoscalerDeployment修改时间：2026-08-14 01:48:28