hpa原理详解

本文详细介绍了Kubernetes的Horizontal Pod Autoscaler (HPA)的工作原理,包括HPA的介绍、源码分析、计算过程和实例。通过源码解析,阐述了HPA如何根据CPU或自定义指标自动调整Pod数量,以及在不同场景下的计算逻辑。同时,总结了HPA在设置多个指标时的处理策略和关键参数的作用。

本章重点: 从源码角度分析hpa的计算逻辑

1. hpa介绍

1.1 hpa是什么

hpa指的是 Pod 水平自动扩缩,全名是Horizontal Pod Autoscaler简称HPA。它可以基于 CPU 利用率或其他指标自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。

用处: 用户可以通过设置hpa,实现deploy pod数量的自动扩缩容。比如流量大的时候,pod数量多一些。流量小的时候,Pod数量降下来,避免资源浪费。

1.2 hpa如何用起来

(1)需要一个deploy/svc等,可以参考社区

(2)需要对应的hpa

举例:

(1) 创建1个deploy。这里只有1个副本

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: zx-hpa-test
  name: zx-hpa
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
  replicas: 2
  selector:
    matchLabels:
      app: zx-hpa-test
  template:
    metadata:
      labels:
        app: zx-hpa-test
      name: zx-hpa-test
    spec:
      terminationGracePeriodSeconds: 5
      containers:
        - name: busybox
          image: busybox:latest
          imagePullPolicy: IfNotPresent
          command:
            - sleep
            - "3600"

(2)创建对应的hpa。

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa-zx-1
  annotations:
    metric-containerName: zx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1   // 这里必须指定需要监控那个对象
    kind: Deployment
    name: zx-hpa
  minReplicas: 1          // deploy最小的Pod数量
  maxReplicas: 3          // deploy最大的Pod数量
  metrics:
    - type: Pods
      pods:
        metricName: pod_cpu_1m
        targetAverageValue: 60

hpa是从同命名空间下,找对应的deploy。所以yaml中指定deploy的时候不要指定namespaces。这也就要求,hpa 和deploy必须在同一命名空间。

这里我使用的 pod_cpu_1m这个指标。这是一个自定义指标。接下来就是分析

创建好之后,观察hpa,当deploy的cpu利用率变化时,deploy的副本会随之改变。

2. hpa 源码分析

2.1 启动参数介绍

hpa controller随controller manager的初始化而启动,hpa controller将以下flag添加到controller manager的flag中,通过controller manager的CLI端暴露给用户:

// AddFlags adds flags related to HPAController for controller manager to the specified FlagSet.
func (o *HPAControllerOptions) AddFlags(fs *pflag.FlagSet) {
  if o == nil {
    return
  }
​
  fs.DurationVar(&o.HorizontalPodAutoscalerSyncPeriod.Duration, "horizontal-pod-autoscaler-sync-period", o.HorizontalPodAutoscalerSyncPeriod.Duration, "The period for syncing the number of pods in horizontal pod autoscaler.")
  fs.DurationVar(&o.HorizontalPodAutoscalerUpscaleForbiddenWindow.Duration, "horizontal-pod-autoscaler-upscale-delay", o.HorizontalPodAutoscalerUpscaleForbiddenWindow.Duration, "The period since last upscale, before another upscale can be performed in horizontal pod autoscaler.")
  fs.MarkDeprecated("horizontal-pod-autoscaler-upscale-delay", "This flag is currently no-op and will be deleted.")
  fs.DurationVar(&o.HorizontalPodAutosc
<think>嗯,用户想了解Kubernetes中HPA和VPA的双水线原则。这个问题挺专业的,说明用户应该是有Kubernetes运维经验的工程师或者开发人员。 从用户提问的措辞来看,ta明确提到了"双水线原则",说明对这个概念有一定基础认知,现在需要更深入的原理和应用层面的解释。我需要把水位线的概念和自动扩缩容机制结合起来讲清楚。 首先得区分清楚HPA和VPA的不同作用域:HPA是横向扩缩Pod数量,VPA是纵向调整单个Pod的资源配额。它们的核心都是通过监控指标和水位线触发扩缩容动作,但实现机制完全不同。 水位线设置确实是个技术难点。水位线设得太高会导致资源利用率低下,设得太低又可能引发性能问题。这里需要引入"目标利用率"的概念,比如HPA默认的CPU利用率阈值是80%,这个值就是典型的水位线。 特别要注意VPA的更新策略差异:Auto模式会直接重启Pod,Recreate模式需要重建,Initial只影响新Pod。这些细节对生产环境很重要,必须强调清楚。 用户可能没意识到的是HPA和VPA同时使用的冲突问题。比如VPA给Pod加了内存,HPA可能就会因为单Pod负载降低而减少Pod数量,反而导致总资源不变。这个坑得重点说明。 在应用场景部分,应该用具体例子展示双水线的价值。比如突发流量场景下HPA快速扩容,而周期性批处理任务更适合用VPA调整资源配比。这些实例能帮助用户理解抽象概念。 最后的安全提示也很关键。特别是VPA的Auto模式在生产环境的风险,以及资源限制的注意事项。这些经验性的内容往往是文档里不会写的实战知识。 对了,用户提供的站内引用提到RoCEv2和PFC调优,虽然和Kubernetes无关,但"水线平衡难题"这个表述值得借鉴。可以把网络拥塞控制中的水线概念与K8s的水位线做个类比,帮助理解多级控制系统的共性。</think>以下是Kubernetes中HPA(水平Pod自动扩缩)与VPA(垂直Pod自动扩缩)的**双水线原则**详解: --- ### 一、核心概念 1. **HPA** - **目标**:通过增减Pod副本数应对负载变化 - **水线依据**:监控指标阈值(如CPU利用率 >80%) - **动作**: ```math \text{期望副本数} = \lceil \frac{\text{当前指标值}}{\text{目标指标值}} \times \text{当前副本数} \rceil ``` 2. **VPA** - **目标**:动态调整单个Pod的资源限制(CPU/Memory) - **水线依据**:容器实际资源利用率与请求值的偏差 - **动作**: ```math \text{新资源请求} = \text{历史峰值} \times (1 + \alpha) \quad (\alpha \text{为缓冲系数}) ``` --- ### 二、双水线原则详解 | **维度** | **HPA水线** | **VPA水线** | |----------------|--------------------------------------|--------------------------------------| | **作用对象** | Pod副本数量 | 单Pod资源配额 | | **触发条件** | 跨聚合指标阈值(如CPU均值>80%) | 单容器资源利用率偏差(如内存>120%) | | **调整粒度** | 集群级扩缩 | Pod级资源重置 | | **水线类型** | 动态阈值(可配置容忍区间) | 历史峰值缓冲(防抖动) | > 关键协同逻辑:**VPA优先调整资源配额 → HPA基于新配额重新计算副本需求** > 例:VPA将Pod内存从1Gi升到2Gi后,相同负载下HPA所需副本数可能减半[^1]。 --- ### 三、典型应用场景 1. **突发流量场景** - HPA快速扩容Pod副本 → 应对瞬时高并发 - VPA滞后调整资源 → 避免短时峰值误判 2. **周期性批处理** - VPA根据历史负载预扩容资源(如每日报表生成前) - HPA维持最小副本数降低常态成本 3. **混合负载优化** ```mermaid graph LR A[流量激增] --> B{HPA水线触发} B -->|扩容Pod| C[新Pod创建] D[持续高负载] --> E{VPA水线触发} E -->|升配资源| F[减少HPA所需副本数] ``` --- ### 四、配置实践要点 1. **水线安全缓冲** - HPA容忍区间:`targetUtilization ± 10%` 防振荡 - VPA缓冲系数:`历史峰值 × 1.2` 预留突发余量 2. **更新策略冲突规避** ```yaml vpa: updatePolicy: minReplicas: 2 # 禁止VPA在HPA缩容至1时调整资源 ``` 3. **指标分级监控** | 级别 | HPA监控指标 | VPA监控指标 | |--------|----------------------|----------------------| | 紧急 | 就绪Pod比例 | OOMKill事件 | | 重要 | CPU/内存均值 | 容器P95资源利用率 | --- ### 五、风险控制 1. **HPA扩缩速度限制** ```yaml behavior: scaleDown: stabilizationWindowSeconds: 300 # 缩容冷却5分钟 ``` 2. **VPA资源上限防护** ```yaml vpa: resourcePolicy: containerName: app maxAllowed: cpu: "4" memory: "8Gi" ``` 3. **双水线死锁预防** - 场景:HPA因资源不足无法扩容 → VPA无法获取指标 → 僵局 - 方案:配置`HPA fallback to custom metrics`(如QPS) > **生产建议**:先启用VPA稳定单Pod资源需求,再调优HPA水线提升弹性[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值