CKA [Networking] – VPA的使用

VPA和HPA一样，只是HPA是水平扩展而VPA是纵向扩展。使用VPA之前必须确保Kubernetes安装了metric server。在 Kubernetes里HPA是默认就安装了的，而VPA并不是 Kubernetes 核心的一部分，它是一个独立的附加组件。要使用 VPA就需要另外安装。

VPA Github连接：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

VPA 为什么需要？

  1. 资源利用率优化
    • 传统做法是人为预估，为了保险往往会给容器配置较高的 requests/limits，导致浪费。
    • VPA 能基于实时监控数据，动态推荐或调整资源，既能保证性能，也能降低资源浪费。
  2. 自动调整，减少运维成本
    • 应用运行中的负载可能随时间波动，手工调优成本高且易出错。
    • VPA 可持续监控，并在推荐（或自动）调整资源时，免去频繁手动修改配置的麻烦。
  3. 配合 HPA，提升弹性
    • HPA 只能在水平扩缩容时起作用（Pod 数量）。当应用本身无法或不宜水平扩展时（例如有状态服务、单副本服务），VPA 提供了另一种伸缩手段。

根据下图的案例是，worker node 是资源是3Core和3GB RAM如果一个pod request了相同多的资源，那么整个worker node就资源就被霸占满了，导致了新的pod就无法被部署的到这台worker node当中。Kubernetes的request只是请求资源，kubernetes会保留请求的额度，避免同一样机器资源争夺。但是确实是如果request设太高的话，实际上可能用不到那么多资源，会造成资源浪费。

3种VPA的updateMode

  • Off（仅推荐，不自动更新）
  • Recreate（非自动模式下，删除 Pod 再重建）
  • Auto（自动根据推荐值删除并重建 Pod）

节点自动伸缩（Cluster-Autoscaler / Karpenter）

  • 当 HPA/VPA 导致 Pod 数量或调度资源请求超出现有节点容量时，如果想要集群自动新增或删除节点，就必须额外安装：
    • Cluster-Autoscaler（CA）：官方比较经典的组件，直接跟云厂商的 API 打交道，基于 Pending Pod 情况增删节点。
    • Karpenter：AWS 开源的下一代节点自动伸缩器，逻辑更灵活、反应更快，也能基于 Pod 的实际需求动态选择实例类型。
  • 二者只能选一来用，且都要单独部署。

使用案例

1. 安装VPA

git clone https://github.com/kubernetes/autoscaler.git

cd autoscaler/vertical-pod-autoscaler/

./hack/vpa-up.sh

【检查是否安装成功了】
kubectl get vpa

2. 创建nginx deployment, 在这里的例子，cpu是一点over provision了，而ram是一点under provision

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "50m"
            memory: "50Mi"

3. 创建VPA , updateMode是OFF的，意思就是说建议，而不会帮你执行更改deployment的request配置

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       nginx-deployment
  updatePolicy:
    updateMode: "Off"

刚刚创建了deployment的话，需要等多一下才能看到VPA的建议，以下是查看VPA的建议

以下的命令是查看VPA内容

kubectl descripe vpa nginx-vpa

4. 更改VPA的updateMode从Off改成Auto

Terminal 1 观察pod的变化

kubectl get pods -w

Terminal 2 更改VPA配置

kubectl edit vpa nginx-vpa

更改updateMode之后，等多一下子就会看到旧的pod的删除，然后创建新的pod，新的pod有新的自动化配置的cpu和ram

VPA和HPA是否能够同时使用？

可以，但要非常小心两者对“资源请求”（requests）和“指标”是如何交互的：

原理冲突

  • HPA（Horizontal Pod Autoscaler）是基于 Pod 的资源请求（requests）和使用率（CPU/内存百分比）来决定副本数的。
  • VPA（Vertical Pod Autoscaler）会动态调整 Pod 的资源请求值。
如果同时开启，VPA 每次更新了 requests，就会改变 HPA 计算的基准（例如原来每个 Pod 请求 200 m CPU，使用 100 m（50%）；VPA 调到 400 m，再用 100 m 就变成 25%）。这样 HPA 很容易“看不懂”真实负载，导致不断增减副本，形成抖动。

  1. 官方建议的做法
    • 不推荐同时对同一指标（CPU/内存）都使用 HPA 和 VPA。
    • 如果一定要一起用，通常的模式是：
      1. VPA 负责“初始化”：使用 VPA 的 Initial 模式，在 Pod 第一次创建时注入推荐的 requests，但之后不再调整。
      2. HPA 负责“运行时伸缩”：HPA 仅基于 CPU 或自定义指标做副本伸缩，不受 VPA 后续调整干扰。
  2. 实战配置示例
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    # 只在首次创建注入建议值
    updateMode: Initial
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  metrics:
    # 如果你只想要基于自定义业务指标伸缩，这里也可以放 Prometheus Adapter
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  minReplicas: 2
  maxReplicas: 10
  • 这样 VPA 在第 1 次创建 Pod 时，给出合理的 CPU/内存 requests；
  • HPA 则根据实际运行时的 CPU 利用率在 2–10 之间扩缩容。

3. 替代方案

  • 如果你想要全程垂直伸缩，只用 VPA 的 Auto 模式，但这样不会新增副本，只会重建 Pod、改变大小，不能应对短期突发流量。
  • 如果你想要全程水平伸缩，只用 HPA，搭配自定义指标（Prometheus、外部指标）即可。

总结：

  • 理论上 HPA 和 VPA 可以同时挂在同一个 Deployment 上；
  • 但 两者同时调整资源请求（CPU/内存）会相互干扰，导致不稳定；
  • 推荐做法：让 VPA 只在初始化阶段注入请求（updateMode: Initial），由 HPA 负责运行时伸缩，或者干脆分别只用水平或只用垂直伸缩。

Loading

Facebook评论

Related Posts