logo
Alauda Container Platform
English
简体中文
English
简体中文
logo
Alauda Container Platform
导航

产品概览

架构
发版日志

安装

安装概述

安装准备

前提条件
下载
节点预处理
安装
global 集群灾难恢复

升级

Overview
升级前准备
升级 global 集群
升级业务集群

用户界面

灵雀控制台

概览
访问 Web 控制台
Customizing the Web Console
Customizing the Left Navigation
CLI 工具

配置

功能开关配置

集群

概述
创建本地集群
etcd 加密
自动旋转 Kubernetes 证书

实用指南

为内置注册表添加外部地址
选择容器运行时
更新公共仓库凭证

网络

介绍

架构

理解 Kube-OVN
了解 ALB
了解 MetalLB

核心概念

认证
Ingress-nginx 注解兼容性
TCP/HTTP 保持连接
ModSecurity
不同 Ingress 方式的比较
HTTP 重定向
L4/L7 超时
GatewayAPI
OTel

功能指南

创建服务
创建 Ingress
配置网关
创建 Ingress-Nginx
创建域名
创建证书
创建外部 IP 地址池
创建 BGP Peers
配置子网
配置网络策略
创建 Admin 网络策略
配置集群网络策略

如何操作

为 ALB 部署高可用 VIP
软件数据中心负载均衡方案(Alpha)
准备 Kube-OVN Underlay 物理网络
Underlay 和 Overlay 子网的自动互联
在 ALB 中使用 OAuth Proxy
创建 GatewayAPI Gateway
配置负载均衡器
如何合理分配 CPU 和内存资源
将 IPv6 流量转发到集群内的 IPv4 地址
Calico 网络支持 WireGuard 加密
Kube-OVN Overlay 网络支持 IPsec 加密
ALB 监控
Application Load Balancer (ALB) 中的负载均衡会话亲和策略

故障排除

如何解决 ARM 环境中的节点间通信问题?
查找错误原因

机器配置

概览
使用 MachineConfig 管理节点配置
节点中断策略

存储

介绍

概念

访问模式与卷模式
核心概念
Persistent Volume

功能指南

创建 CephFS 文件存储类型存储类
创建 CephRBD 块存储类
创建 TopoLVM 本地存储类
创建 NFS 共享存储类
部署 Volume Snapshot 组件
创建 PV
创建 PVCs
使用卷快照

实用指南

设置 NFS 共享存储类的子目录命名规则
通用临时卷
使用 emptyDir
第三方存储能力注解指南

故障排除

从 PVC 扩容失败中恢复

存储

Ceph 分布式存储

介绍

安装

创建标准类型集群
创建 Stretch 类型集群
架构

核心概念

核心概念

操作指南

访问存储服务
管理存储池
节点特定组件部署
添加设备/设备类
监控与告警

实用指南

配置专用集群用于分布式存储
清理分布式存储

数据容灾

文件存储灾备
块存储灾难恢复
对象存储灾备
更新优化参数
创建 ceph 对象存储用户

MinIO 对象存储

介绍
安装
架构

核心概念

核心概念

操作指南

添加存储池
Monitoring & Alerts

实用指南

数据灾难恢复

TopoLVM 本地存储

介绍
安装

操作指南

设备管理
监控与告警

实用指南

使用 Velero 备份和恢复 TopoLVM 文件系统 PVC

安全

Alauda Container Security

安全性与合规性

合规

介绍
安装

使用指南

私有镜像仓库访问配置
Image Signature Verification Policy
使用 Secrets 的镜像签名验证策略
镜像仓库验证策略
容器逃逸防护策略
Security Context Enforcement Policy
网络安全策略
Volume Security Policy

API Refiner

介绍
安装

用户与角色

用户

介绍

功能指南

管理用户角色
创建用户
用户管理

用户组

介绍

功能指南

管理用户组角色
创建本地用户组
管理本地用户组成员资格

角色

介绍

功能指南

创建角色
管理自定义角色

IDP

介绍

功能指南

LDAP 管理
OIDC 管理

故障排除

删除用户

用户策略

介绍

多租户(项目)

介绍

功能指南

创建项目
管理项目
管理项目集群
管理项目成员

审计

介绍

遥测

安装

虚拟化

虚拟化

概览

介绍
安装

镜像

介绍

操作指南

添加虚拟机镜像
更新/删除虚拟机镜像
更新/删除镜像凭据

实用指南

使用 KubeVirt 基于 ISO 创建 Windows 镜像
使用 KubeVirt 基于 ISO 创建 Linux 镜像
导出虚拟机镜像
权限说明

虚拟机

介绍

操作指南

创建虚拟机/虚拟机组
虚拟机批量操作
使用 VNC 登录虚拟机
管理密钥对
管理虚拟机
监控与告警
虚拟机快速定位

实用指南

配置 USB 主机直通
虚拟机热迁移
虚拟机恢复
在 KubeVirt 上克隆虚拟机
物理 GPU 直通环境准备
配置虚拟机的高可用性
从现有虚拟机创建虚拟机模板

问题处理

虚拟机节点正常关机下的 Pod 迁移及异常宕机恢复问题
热迁移错误信息及解决方案

网络

介绍

操作指南

配置网络

实用指南

通过网络策略实现虚拟机网络请求控制
配置 SR-IOV
配置虚拟机使用网络绑定模式以支持 IPv6

存储

介绍

操作指南

管理虚拟磁盘

备份和恢复

介绍

操作指南

使用快照

开发者

快速开始

Creating a simple application via image

构建应用

核心概念

应用类型
Custom Applications
Workload Types
理解参数
理解环境变量
理解启动命令
资源单位说明

命名空间

创建命名空间
导入 Namespace
Resource Quota
Limit Range
Pod Security Admission
Overcommit Ratio
管理命名空间成员
更新命名空间
删除/移除命名空间

创建应用

Creating applications from Image
Creating applications from Chart
通过 YAML 创建应用
通过代码创建应用
Creating applications from Operator Backed
通过 CLI 工具创建应用

应用的操作与维护

Application Rollout

安装 Alauda Container Platform Argo Rollouts
Application Blue Green Deployment
Application Canary Deployment
状态说明

KEDA(Kubernetes Event-driven Autoscaling)

KEDA Overview
Installing KEDA

实用指南

Integrating ACP Monitoring with Prometheus Plugin
在 KEDA 中暂停自动扩缩容
配置 HPA
启动和停止原生应用
配置 VerticalPodAutoscaler (VPA)
配置 CronHPA
更新原生应用
导出应用
更新和删除 Chart 应用
应用版本管理
删除原生应用
健康检查

计算组件

Deployments
DaemonSets
StatefulSets
CronJobs
任务
Pods
Containers
使用 Helm charts

配置

Configuring ConfigMap
Configuring Secrets

应用可观测

监控面板
Logs
实时事件

实用指南

设置定时任务触发规则

镜像仓库

介绍

安装

通过 YAML 安装
通过 Web UI 安装

使用指南

Common CLI Command Operations
Using Alauda Container Platform Registry in Kubernetes Clusters

S2I

介绍

安装

Installing Alauda Container Platform Builds

升级

升级 Alauda Container Platform Builds
架构

功能指南

Managing applications created from Code

How To

通过代码创建应用

节点隔离策略

引言
架构

概念

核心概念

功能指南

创建节点隔离策略
权限说明
常见问题

GitOps

介绍

安装

Installing Alauda Build of Argo CD
Installing Alauda Container Platform GitOps

升级

Upgrading Alauda Container Platform GitOps
架构

核心概念

GitOps

Argo CD 核心概念

Argo CD Introduction
Application 概念
ApplicationSet 概念
Tool
Helm 概念
Kustomize 概念
Directory 概念
Sync 概念
Health 概念

Alauda Container Platform GitOps 核心概念

介绍
Alauda Container Platform GitOps 的同步及健康检查

功能指南

创建 GitOps 应用

Creating GitOps Application
Creating GitOps ApplicationSet

GitOps 可观测

Argo CD 组件监控
GitOps 应用运维

实用指南

通过 Argo CD Dashboard 集成代码仓库
通过 Argo CD dashboard 创建 Argo CD Application
通过平台创建 Argo CD Application
如何获取 Argo CD 访问信息
故障排查

扩展

Operator
集群插件

可观测性

概览

监控

介绍
安装

架构

监控模块架构
监控组件选型指南
核心概念

操作指南

指标管理
告警管理
通知管理
监控面板管理
探针管理

实用指南

Prometheus 监控数据的备份与恢复
VictoriaMetrics 监控数据备份与恢复
从自定义命名的网络接口采集网络数据

调用链

介绍
安装
架构
核心概念

操作指南

查询追踪
查询追踪日志

实用指南

Java 应用无侵入方式接入调用链
与 TraceID 相关的业务日志

问题处理

查询不到所需的调用链
调用链数据不完整

日志

介绍
安装

架构

日志模块架构
日志组件选型指南
日志组件容量规划
概念

操作指南

日志

实用指南

如何将日志归档至第三方存储
如何对接外部 ES 存储集群

事件

介绍
Events

巡检

介绍
架构

操作指南

巡检
Component Health Status

硬件加速器

概述

介绍
功能概览
安装

应用开发

介绍

功能指南

CUDA 驱动与运行时兼容性
使用 ConfigMap 添加自定义设备

故障排除

解决 vLLM 中 “float16 is only supported on GPUs with compute capability at least xx” 错误
Paddle Autogrow 内存分配在 GPU-Manager 上的崩溃问题

配置管理

介绍

功能指南

在 GPU 节点上配置硬件加速器

资源监控

介绍

功能指南

GPU 资源监控

Alauda 服务网格

关于 Alauda Service Mesh

Alauda AI

关于 Alauda AI

Alauda DevOps

关于灵雀云 DevOps

Alauda 计量计费

关于 Alauda 成本管理

Alauda 应用服务

概览

介绍
架构
安装
升级

Alauda Database Service for MySQL

关于 Alauda Database Service for MySQL-MGR
关于 Alauda Database Service for MySQL-PXC

Alauda Cache Service for Redis OSS

关于 Alauda Cache Service for Redis OSS

Alauda Streaming Service for Kafka

About Alauda Streaming Service for Kafka

Alauda Streaming Service for RabbitMQ

关于 Alauda Streaming Service for RabbitMQ

Alauda support for PostgreSQL

关于 Alauda support for PostgreSQL

运维管理

介绍

参数模板管理

介绍

功能指南

参数模板管理

备份管理

介绍

功能指南

外部 S3 存储
备份管理

检查管理

介绍

操作指南

创建巡检任务
Exec Inspection Task
更新和删除巡检任务

实用指南

如何设置检查调度?

检查优化建议

MySQL

MySQL IO负载优化
MySQL 内存使用优化
MySQL存储空间优化
MySQL 活动线程计数优化
MySQL 行锁优化

Redis

Redis 大键
Redis中的高CPU使用率
Redis中的高内存使用

Kafka

Kafka 中的高 CPU 利用率
Kafka Rebalance 优化
Kafka内存使用优化
Kafka 存储空间优化

RabbitMQ

RabbitMQ Mnesia 数据库异常处理

警报管理

介绍

操作指南

与平台能力的关系

升级管理

介绍

操作指南

示例升级

API 参考

概览

介绍
Kubernetes API 使用指南

Advanced APIs

Alert APIs

AlertHistories [v1]
AlertHistoryMessages [v1]
AlertStatus [v2]
SilenceStatus [v2]

Event APIs

Search

Log APIs

Aggregation
Archive
Context
Search

Monitoring APIs

Indicators [monitoring.alauda.io/v1beta1]
Metrics [monitoring.alauda.io/v1beta1]
Variables [monitoring.alauda.io/v1beta1]

Kubernetes APIs

Alert APIs

AlertTemplate [alerttemplates.aiops.alauda.io/v1beta1]
PrometheusRule [prometheusrules.monitoring.coreos.com/v1]

Inspection APIs

Inspection [inspections.ait.alauda.io/v1alpha1]

Notification APIs

Notification [notifications.ait.alauda.io/v1beta1]
NotificationGroup [notificationgroups.ait.alauda.io/v1beta1]
NotificationTemplate [notificationtemplates.ait.alauda.io/v1beta1]
📝 在 GitHub 上编辑此页
上一页在 KEDA 中暂停自动扩缩容
下一页启动和停止原生应用

#配置 HPA

HPA(Horizontal Pod Autoscaler,水平 Pod 自动扩缩器)根据预设的策略和指标自动上下调整 Pod 数量,使应用能够应对突发的业务流量高峰,同时在低流量时段优化资源利用率。

#目录

#了解水平 Pod 自动扩缩器

您可以创建一个水平 Pod 自动扩缩器,指定希望运行的 Pod 最小和最大数量,以及 Pod 应达到的 CPU 利用率或内存利用率目标。

创建水平 Pod 自动扩缩器后,平台开始查询 Pod 上的 CPU 和/或内存资源指标。当这些指标可用时,水平 Pod 自动扩缩器计算当前指标利用率与期望指标利用率的比值,并据此进行扩缩容。查询和扩缩容操作以固定间隔执行,但指标可用可能需要一到两分钟。

对于 replication controllers,此扩缩容直接对应 replication controller 的 Replica 数量。对于 deployment configurations,扩缩容直接对应 deployment configuration 的 Replica 数量。注意,自动扩缩容仅适用于处于 Complete 阶段的最新部署。

平台会自动考虑资源情况,避免在资源峰值(如启动期间)时进行不必要的自动扩缩容。处于未就绪状态的 Pod 在扩容时视为 0 CPU 使用率,缩容时会被忽略。没有已知指标的 Pod 在扩容时视为 0% CPU 使用率,缩容时视为 100% CPU 使用率。这有助于 HPA 决策时更稳定。要使用此功能,必须配置 readiness 检查以判断新 Pod 是否已准备好使用。

#HPA 是如何工作的?

水平 Pod 自动扩缩器(HPA)扩展了 Pod 自动扩缩的概念。HPA 允许您创建和管理一组负载均衡的节点。当 CPU 或内存达到设定阈值时,HPA 会自动增加或减少 Pod 数量。

HPA 作为一个控制循环运行,默认同步周期为 15 秒。在此期间,controller manager 会根据 HPA 配置查询 CPU、内存利用率或两者。controller manager 从资源指标 API 获取每个被 HPA 目标的 Pod 的资源利用率指标,如 CPU 或内存。

如果设置了利用率目标,controller 会将利用率值计算为各 Pod 容器请求资源的百分比。然后 controller 计算所有目标 Pod 的平均利用率,并生成一个比例,用于调整期望的 Replica 数量。

#支持的指标

水平 Pod 自动扩缩器支持以下指标:

指标描述
CPU 利用率使用的 CPU 核数。可用于计算 Pod 请求 CPU 的百分比。
内存利用率使用的内存量。可用于计算 Pod 请求内存的百分比。
网络入流量进入 Pod 的网络流量,单位为 KiB/s。
网络出流量从 Pod 发出的网络流量,单位为 KiB/s。
存储读流量从存储读取的数据量,单位为 KiB/s。
存储写流量写入存储的数据量,单位为 KiB/s。

重要提示:对于基于内存的自动扩缩容,内存使用必须与 Replica 数量成比例地增减。一般来说:

  • Replica 数量增加时,每个 Pod 的内存(工作集)使用应整体下降。
  • Replica 数量减少时,每个 Pod 的内存使用应整体上升。
  • 请使用平台检查应用的内存行为,确保应用满足这些要求后再使用基于内存的自动扩缩容。

#前提条件

请确保监控组件已部署在当前集群并正常运行。您可以点击平台右上角 展开 > 平台健康状态,检查监控组件的部署和健康状态。

#创建水平 Pod 自动扩缩器

#使用 CLI

您可以通过命令行界面创建水平 Pod 自动扩缩器,方法是定义一个 YAML 文件并使用 kubectl create 命令。以下示例展示了针对 Deployment 对象的自动扩缩容。初始部署需要 3 个 Pod,HPA 对象将最小值提升到 5。如果 Pod 的 CPU 使用率达到 75%,Pod 数量将增加到 7:

  1. 创建名为 hpa.yaml 的 YAML 文件,内容如下:

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: hpa-demo
      namespace: default
    spec:
      maxReplicas: 7
      minReplicas: 3
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: deployment-demo
      targetCPUUtilizationPercentage: 75
    1. 使用 autoscaling/v2 API。
    2. HPA 资源的名称。
    3. 需要扩缩容的 Deployment 名称。
    4. 最大扩缩容副本数。
    5. 最小维持副本数。
    6. 指定扩缩容对象的 API 版本。
    7. 指定对象类型。对象必须是 Deployment、ReplicaSet 或 StatefulSet。
    8. HPA 作用的目标资源。
    9. 触发扩缩容的目标 CPU 利用率百分比。
  2. 应用 YAML 文件创建 HPA:

    kubectl create -f hpa.yaml

    示例输出:

    horizontalpodautoscaler.autoscaling/hpa-demo created
  3. 创建 HPA 后,可以运行以下命令查看 Deployment 的新状态:

    kubectl get deployment deployment-demo

    示例输出:

    NAME              READY   UP-TO-DATE   AVAILABLE   AGE
    deployment-demo   5/5     5            5           3m
  4. 也可以检查 HPA 的状态:

    kubectl get hpa hpa-demo

    示例输出:

    NAME         REFERENCE                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
    hpa-demo   Deployment/deployment-demo   0%/75%     3         7         3          2m

#使用 Web 控制台

  1. 进入 Container Platform。

  2. 在左侧导航栏点击 Workloads > Deployments。

  3. 点击 Deployment 名称。

  4. 向下滚动到 弹性伸缩 区域,点击右侧的 更新。

  5. 选择 水平伸缩 并完成策略配置。

    参数描述
    Pod 数量部署成功后,需要评估对应已知和常规业务量变化的最小 Pod 数量,以及在高业务压力下命名空间配额可支持的最大 Pod 数量。最大或最小 Pod 数量可在设置后更改,建议先通过性能测试推导更准确的值,并在使用过程中持续调整以满足业务需求。
    触发策略列出对业务变化敏感的指标及其目标阈值,以触发扩容或缩容操作。
    例如,设置 CPU 利用率 = 60%,一旦 CPU 利用率偏离 60%,平台将根据当前部署资源不足或过剩情况自动调整 Pod 数量。
    注意:指标类型包括内置指标和自定义指标。自定义指标仅适用于原生应用中的部署,且需先添加自定义指标。
    扩缩容步长(Alpha)对于有特定扩缩容速率要求的业务,可以通过指定扩容步长或缩容步长逐步适应业务量变化。
    缩容步长可自定义稳定窗口,默认 300 秒,表示执行缩容操作前需等待 300 秒。
  6. 点击 更新。

#使用自定义指标进行 HPA

自定义指标 HPA 扩展了原有的 HorizontalPodAutoscaler,支持除 CPU 和内存利用率外的更多指标。

#要求

  • kube-controller-manager:horizontal-pod-autoscaler-use-rest-clients=true
  • 预先安装 metrics-server
  • Prometheus
  • custom-metrics-api

#传统(核心指标)HPA

传统 HPA 支持 CPU 利用率和内存指标动态调整 Pod 实例数量,示例如下:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-app-nginx
  namespace: test-namespace
spec:
  maxReplicas: 1
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-app-nginx
  targetCPUUtilizationPercentage: 50

该 YAML 中,scaleTargetRef 指定了扩缩容的工作负载对象,targetCPUUtilizationPercentage 指定 CPU 利用率触发指标。

#自定义指标 HPA

使用自定义指标需安装 prometheus-operator 和 custom-metrics-api。安装后,custom-metrics-api 提供大量自定义指标资源:

{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "namespaces/go_memstats_heap_sys_bytes",
      "singularName": "",
      "namespaced": false,
      "kind": "MetricValueList",
      "verbs": ["get"]
    },
    {
      "name": "jobs.batch/go_memstats_last_gc_time_seconds",
      "singularName": "",
      "namespaced": true,
      "kind": "MetricValueList",
      "verbs": ["get"]
    },
    {
      "name": "pods/go_memstats_frees",
      "singularName": "",
      "namespaced": true,
      "kind": "MetricValueList",
      "verbs": ["get"]
    }
  ]
}

这些资源均为 MetricValueList 的子资源。您可以通过 Prometheus 创建规则来创建或维护子资源。自定义指标 HPA 的 YAML 格式与传统 HPA 不同:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: demo
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: demo
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metricName: metric-demo
        targetAverageValue: 10

示例中,scaleTargetRef 指定了工作负载。

#触发条件定义

  • metrics 是数组类型,支持多个指标
  • metric type 可为:Object(描述 k8s 资源)、Pods(描述每个 Pod 的指标)、Resources(内置 k8s 指标:CPU、内存)、External(通常为集群外部指标)
  • 若自定义指标非由 Prometheus 提供,则需通过创建 Prometheus 规则等操作新增指标

指标的主要结构如下:

{
      "describedObject": {  # 描述对象(Pod)
        "kind": "Pod",
        "namespace": "monitoring",
        "name": "nginx-788f78d959-fd6n9",
        "apiVersion": "/v1"
      },
      "metricName": "metric-demo",
      "timestamp": "2020-02-5T04:26:01Z",
      "value": "50"
}

该指标数据由 Prometheus 收集并更新。

#自定义指标 HPA 兼容性

自定义指标 HPA YAML 实际兼容原核心指标(CPU),写法如下:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: nginx
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 80
    - type: Resource
      resource:
        name: memory
        targetAverageValue: 200Mi
  • targetAverageValue 是每个 Pod 获取的平均值
  • targetAverageUtilization 是根据直接值计算的利用率

算法参考为:

replicas = ceil(sum(CurrentPodsCPUUtilization) / Target)

#autoscaling/v2beta2 的更新

autoscaling/v2beta2 支持内存利用率:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - resource:
        name: cpu
        target:
          averageUtilization: 70
          type: Utilization
      type: Resource
    - resource:
        name: memory
        target:
          averageUtilization:
          type: Utilization
      type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx

变化:targetAverageUtilization 和 targetAverageValue 改为 target,并转换为 xxxValue 和 type 的组合:

  • xxxValue:AverageValue(平均值)、AverageUtilization(平均利用率)、Value(直接值)
  • type:Utilization(利用率)、AverageValue(平均值)

注意:

  • 对于 CPU 利用率 和 内存利用率 指标,只有实际值偏离目标阈值 ±10% 范围时才触发自动扩缩容。
  • 缩容可能影响正在进行的业务操作,请谨慎操作。

#计算规则

当业务指标变化时,平台会根据以下规则自动计算匹配业务量的目标 Pod 数量并进行调整。如果业务指标持续波动,数值会被调整到设置的最小 Pod 数量或最大 Pod 数量。

  • 单策略目标 Pod 数量:ceil[(sum(实际指标值)/指标阈值)]。即所有 Pod 的实际指标值之和除以指标阈值后向上取整。例如:当前有 3 个 Pod,CPU 利用率分别为 80%、80%、90%,设置的 CPU 利用率阈值为 60%。根据公式,Pod 数量自动调整为:ceil[(80%+80%+90%)/60%] = ceil 4.1 = 5 个 Pod。

    注意:

    • 如果计算出的目标 Pod 数量超过设置的最大 Pod 数量(例如 4),平台只会扩容到 4 个 Pod。如果调整最大 Pod 数量后指标仍持续偏高,可能需要采用其他扩缩容方式,如增加命名空间 Pod 配额或增加硬件资源。
    • 如果计算出的目标 Pod 数量(如上例的 5)小于根据扩容步长调整后的 Pod 数量(例如 10),平台只会扩容到 5 个 Pod。
  • 多策略目标 Pod 数量:取各策略计算结果中的最大值。