在K8S中，自动扩容机制是什么?

在 Kubernetes 中，自动扩容主要通过两个核心机制实现：

水平 Pod 自动扩缩器： 根据观察到的 CPU 利用率、内存使用率或其他自定义指标自动调整 Pod 的副本数量。
垂直 Pod 自动扩缩器： 自动调整单个 Pod 的资源配置请求（CPU 和内存的 requests 和 limits），使其更符合实际使用需求。

1. 水平 Pod 自动扩缩器

核心功能： 根据设定的目标指标值（如 CPU 平均利用率 70%），自动增加（扩容/scale out）或减少（缩容/scale in）运行中的 Pod 副本数（replicas）。这是最常用和成熟的自动扩缩机制。
工作原理：
1. 监控指标： HPA 控制器定期（默认 15 秒）通过 Metrics API 从资源指标管道（如 metrics-server）或自定义指标管道（如 Prometheus Adapter）获取目标 Pod 的指标数据（如 CPU、内存、QPS、队列深度等）。
2. 计算期望副本数： HPA 控制器使用以下公式计算所需的副本数：
  期望副本数 = ceil[当前副本数 * (当前指标值 / 目标指标值)]
  例如：当前有 4 个 Pod，目标 CPU 利用率是 50%，当前所有 Pod 的平均 CPU 利用率是 90%。期望副本数 = ceil[4 * (90 / 50)] = ceil[4 * 1.8] = ceil[7.2] = 8。
3. 调整副本数： HPA 控制器通过更新关联的 Deployment、StatefulSet 或 ReplicaSet 的 replicas 字段，触发控制器去创建或删除 Pod，以达到期望的副本数。
关键组件：
- metrics-server： 核心集群组件，提供基础的资源指标（Pod/Node 的 CPU 和内存使用率）。HPA 依赖它获取核心资源指标。
- 自定义/外部指标适配器： 如 Prometheus Adapter, Datadog Cluster Agent 等，用于将第三方监控系统（如 Prometheus, Datadog）中的指标暴露给 Kubernetes Metrics API，使 HPA 能够基于应用特定指标（如 HTTP 请求率、消息队列长度）进行扩缩。

配置 (HorizontalPodAutoscaler 资源)：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  namespace: default
spec:
  scaleTargetRef:  # 指定要扩缩的目标对象
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 2   # 最小副本数
  maxReplicas: 10   # 最大副本数
  metrics:         # 定义用于扩缩的指标
  - type: Resource
    resource:
      name: cpu    # 指标类型 (cpu 或 memory)
      target:
        type: Utilization # 目标类型 (Utilization, AverageValue, Value)
        averageUtilization: 50 # 目标 CPU 平均利用率 50%
  # 可以定义多个指标，HPA 会计算每个指标所需的副本数并取最大值
  # - type: Pods / Object / External / ContainerResource (其他指标类型)
  #   ...
  behavior: # (可选) 扩缩行为配置，控制速度
    scaleDown:
      stabilizationWindowSeconds: 300 # 缩容稳定窗口 300 秒
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60 # 每分钟最多缩掉当前副本数的 10%
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15 # 每分钟最多扩容 100%（即翻倍）
      - type: Pods
        value: 4
        periodSeconds: 15 # 每分钟最多增加 4 个 Pod，取两者最大值

适用场景： 应对流量波动、负载变化。当负载增加时增加 Pod 分散压力；负载降低时减少 Pod 节省资源。

2. 垂直 Pod 自动扩缩器

核心功能： 分析 Pod 的历史资源使用情况（CPU、内存），自动调整 Pod 定义中的 requests 和 limits，使资源配置更贴合 Pod 的实际需求，减少资源浪费或避免因资源不足导致的 OOMKill。
工作原理：
1. 监控与建议： VPA 包含三个组件：
  - Recommender： 分析 Pod 的历史资源使用数据（通常来自 Prometheus 或 metrics-server），为每个 Pod 计算推荐的 CPU/Memory requests 和 limits。
  - Updater： 检查 Pod 的当前资源配置是否与推荐值显著不同。如果不同，且 Pod 属于 VPA 配置的 updatePolicy 允许更新的范围（如 Auto, Recreate, Initial），则驱逐（Evict）该 Pod。Pod 被驱逐后，其控制器（Deployment/StatefulSet）会创建一个新的 Pod 来替换它。
  - Admission Controller： 在新 Pod 被调度时，拦截其创建请求，并将 VPA Recommender 计算出的推荐值注入到 Pod 的 requests 和 limits 字段中。
2. 更新 Pod： VPA 通常不会原地更新正在运行的 Pod 的资源限制（cgroups 限制在 Pod 启动时设定）。更新配置的主要方式是通过驱逐旧 Pod 并创建应用了新资源设置的新 Pod（Recreate 模式）。Auto 模式也依赖此机制。

配置 (VerticalPodAutoscaler 资源)：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: myapp-deployment
  updatePolicy:
    updateMode: "Auto" # 模式: Off, Initial, Recreate, Auto
  resourcePolicy:
    containerPolicies:
    - containerName: "*" # 应用到所有容器
      minAllowed: # (可选) 允许设置的最小值
        cpu: "100m"
        memory: "100Mi"
      maxAllowed: # (可选) 允许设置的最大值
        cpu: "2"
        memory: "2Gi"
      controlledResources: ["cpu", "memory"] # 控制哪些资源

适用场景：
- 优化资源利用率，降低云成本。
- 避免因初始 requests 设置过低导致 Pod 因 OOM 被杀或 CPU 饥饿。
- 应对应用资源需求随时间变化的情况（如新版本发布后资源需求改变）。
注意事项：
- Pod 重启： Auto 和 Recreate 模式会驱逐 Pod 导致短暂中断（控制器会重建）。
- 与 HPA 协同： 如果 HPA 基于 CPU/Memory 利用率扩缩，同时使用 VPA 调整 Pod 的 requests 可能会干扰 HPA 的计算（因为 HPA 的目标利用率是基于 requests 计算的）。通常建议：
  - HPA 使用自定义指标（非 CPU/Memory）。
  - 或者让 VPA 只调整 limits。
  - 或者仔细协调目标值。
- StatefulSet 限制： 对 StatefulSet 使用 VPA Auto 模式需谨慎，可能违反有状态应用的稳定性要求。

3. 集群自动扩缩器

核心功能： 观察集群中由于资源不足（CPU、内存、GPU 等）而无法被调度的 Pod（处于 Pending 状态），或者存在利用率过低的节点，自动增加或减少 Kubernetes 集群中的工作节点数量。
工作原理：
1. 检查未调度 Pod： CA 定期检查是否存在因资源不足而无法调度的 Pod。
2. 请求新节点： 如果存在这样的 Pod，并且满足扩展条件（如未超过最大节点数限制），CA 会调用云提供商的 API 向节点池中添加一个新节点。
3. 检查节点利用率： CA 定期检查节点资源利用率（所有 Pod 的 requests 总和占节点可分配资源的比例）。
4. 缩容低利用率节点： 如果节点利用率持续低于设定阈值一段时间，并且该节点上的所有 Pod 都能被调度到其他节点上运行（通过模拟调度检查），CA 会驱逐该节点上的所有 Pod，并调用云提供商 API 移除该节点。
配置： CA 本身是一个独立的 Pod 运行在集群中，其配置通常通过命令行参数或 ConfigMap 设置（如最大/最小节点数、节点组信息、缩容阈值、冷却时间等）。
适用场景： 动态管理整个集群的计算资源池。在 Pod 需要更多资源时自动扩容节点池；在集群整体负载较低时自动缩容节点池以节省成本。
依赖： 需要运行在支持节点池自动伸缩的云平台（如 GKE, EKS, AKS）或本地环境中安装了相应实现（如 cluster-autoscaler 配合特定云提供商或 cluster-api）。

总结与协同工作：

HPA (水平扩缩 Pod 副本数)： 应对应用负载变化，最常用。
VPA (垂直调整 Pod 资源请求/限制)： 优化单个 Pod 的资源分配，节省成本或提高稳定性，使用时需注意其更新机制（驱逐 Pod）以及与 HPA 的潜在冲突。
CA (集群自动扩缩节点)： 管理底层计算资源池，确保有足够的节点资源来运行 Pod（由 HPA 创建或 VPA 更新后的）。

一个完整的弹性伸缩方案通常会结合使用 HPA + CA：

当应用负载增加，HPA 创建更多 Pod。
如果集群资源不足导致新 Pod 无法调度（Pending），CA 检测到后扩容节点。
当应用负载降低，HPA 减少 Pod 数量。
如果节点变得空闲（利用率低），CA 检测到后缩容节点。

VPA 则用于在微观层面持续优化每个 Pod 的资源使用效率，通常独立部署或谨慎地与 HPA (基于非资源指标) 配合使用。

posted @ 2025-08-19 08:56 天道酬勤zjh 阅读(59) 评论(0) 收藏举报

刷新页面返回顶部

在K8S中，自动扩容机制是什么?

公告