水平自动扩缩容（HPA）
HPA是Kubernetes中的水平自动扩缩器，通过增减Pod副本数来应对工作负载变化。
HPA的工作原理
HPA通过监控目标Pod的某些指标（如CPU使用率、内存使用率或自定义指标）来决定是否需要增加或减少Pod的数量。其基本工作流程如下：
监控指标收集：依赖 Kubernetes Metrics Server（或 Prometheus 等后端）收集Pod的指标数据。
指标分析：HPA控制器定期查询这些指标，并根据预设的目标利用率（如CPU利用率目标设为50%）计算所需的Pod数量。
Pod数量调整：如果当前Pod的平均指标利用率高于或低于目标值，HPA将触发Pod的扩展或缩减操作，通过调整ReplicaSet或Deployment的副本数来实现。
示例
#deployment
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-test
name: nginx-test
spec:
replicas: 2
selector:
matchLabels:
app: nginx-test
template:
metadata:
labels:
app: nginx-test
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
resources:
requests:
cpu: 100m
memory: 50Mi
---
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-svc
name: nginx-svc
spec:
ports:
- name: 80-80
nodePort: 30020
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx-test
type: NodePort
#HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
namespace: default
spec:
scaleTargetRef: #控制的目标资源
apiVersion: apps/v1 #目标资源的API版本
kind: Deployment #目标资源的类型
name: nginx #目标资源的名称（必须与Deployment名称一致）
minReplicas: 3 #最少保留的Pod数量
maxReplicas: 100 #最多允许的Pod数量
metrics: #依据哪些指标进行扩缩容决策
- type: Resource #资源指标
resource:
name: cpu #监控CPU
target:
type: Utilization #平均利用率
averageUtilization: 50 #当平均CPU利用率超过50%时触发扩容
- type: Resource
resource:
name: memory #监控内存
target:
type: AverageValue #平均使用值
averageValue: 200Mi #当平均内存利用值超过200Mi时触发扩容
满足任意一个指标，就会触发hpa自动扩容
#压测前的状态
[root@master01 yaml]# kubectl get hpa,pod
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-test cpu: 0%/50%, memory: 4814848/200Mi 3 100 3 6s
NAME READY STATUS RESTARTS AGE
pod/nginx-test-5496f4c54d-d6j5s 1/1 Running 0 2m45s
pod/nginx-test-5496f4c54d-g69zr 1/1 Running 0 20s
pod/nginx-test-5496f4c54d-jqln4 1/1 Running 0 2m45s
#进行压测
[root@master01 yaml]# ab -c 1000 -n 1000000 http://192.168.135.150:30020/
-c 并发数
-n 请求总数
#从3个直接扩容到了11个
[root@master01 yaml]# kubectl get pod,hpa
NAME READY STATUS RESTARTS AGE
pod/nginx-test-5496f4c54d-8pc92 1/1 Running 0 3m40s
pod/nginx-test-5496f4c54d-d6j5s 1/1 Running 0 7m20s
pod/nginx-test-5496f4c54d-g69zr 1/1 Running 0 4m55s
pod/nginx-test-5496f4c54d-jqln4 1/1 Running 0 7m20s
pod/nginx-test-5496f4c54d-kxpnj 1/1 Running 0 3m40s
pod/nginx-test-5496f4c54d-n8k8m 1/1 Running 0 3m25s
pod/nginx-test-5496f4c54d-ndsk2 1/1 Running 0 3m40s
pod/nginx-test-5496f4c54d-sb4zj 1/1 Running 0 3m40s
pod/nginx-test-5496f4c54d-sq7sb 1/1 Running 0 3m25s
pod/nginx-test-5496f4c54d-tq989 1/1 Running 0 3m25s
pod/nginx-test-5496f4c54d-wqsp4 1/1 Running 0 3m25s
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-test cpu: 23%/50%, memory: 5290542545m/200Mi 3 100 11 4m41s
#停止压测后缩容到3个
Behavior行为策略
在Kubernetes中，HPA（Horizontal Pod Autoscaler）是一个用于根据资源使用情况自动调整Pod副本数量的工具。HPA的Behavior字段允许我们对扩缩容行为进行更精细的控制，尤其是在scaleUp（扩容）和scaleDown（缩容）策略的配置上。
Behavior字段是在Kubernetes 1.18版本中引入的，它可以定义HPA在执行扩缩容时的行为策略。Behavior字段包含两个主要部分：scaleUp和scaleDown，分别用于控制扩容和缩容的行为。通过配置这些策略，可以调整HPA的反应速度、稳定性以及对资源变化的敏感性。
scaleUp策略配置
scaleUp部分定义了HPA在需要扩容时的行为。以下是scaleUp策略的核心配置项：
policies（策略） 这是用来定义扩容行为的规则列表。每个策略包含两个参数：
type： 策略类型，可以是Pods或Percent。Pods表示每次扩容固定的Pod数量，而Percent表示每次扩容当前Pod数量的百分比。
value： 策略的值，即每次扩容的Pod数量或百分比。
selectPolicy（选择策略） 它决定了如何从多个策略中选择执行。可选值为：
Max： 选择扩容量最大的策略。
Min： 选择扩容量最小的策略。
Disabled： 完全禁用扩容。
stabilizationWindowSeconds（稳定时间窗口） 这段时间内，HPA会观察资源使用情况，避免频繁扩容。默认情况下，Kubernetes会基于历史数据自动调整这个值。
scaleDown策略配置
scaleDown部分用于定义HPA在需要缩容时的行为。与scaleUp类似，scaleDown也有以下几个核心配置项：
policies（策略） 定义缩容行为的规则列表。每个策略同样包含type和value参数。
selectPolicy（选择策略） 决定如何从多个策略中选择执行。可选值与scaleUp相同。
stabilizationWindowSeconds（稳定时间窗口） 这段时间内，HPA会观察资源使用情况，避免频繁缩容。缩容的默认稳定时间窗口为5分钟。
示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
namespace: default
spec:
scaleTargetRef: #控制的目标资源
apiVersion: apps/v1 #目标资源的API版本
kind: Deployment #目标资源的类型
name: nginx #目标资源的名称（必须与Deployment名称一致）
minReplicas: 3 #最少保留的Pod数量
maxReplicas: 100 #最多允许的Pod数量
metrics: #依据哪些指标进行扩缩容决策
- type: Resource #资源指标
resource:
name: cpu #监控CPU
target:
type: Utilization #平均利用率
averageUtilization: 50 #当平均CPU利用率超过50%时触发扩容
- type: Resource
resource:
name: memory #监控内存
target:
type: AverageValue #平均使用值
averageValue: 200Mi #当平均内存利用值超过200Mi时触发扩容
behavior: #扩缩容行为策略（定义 HPA 如何调整副本数）
scaleUp: #扩容策略配置
policies: #扩容规则列表
- type: Pods #规则类型（按Pod数量）
value: 4 #每次最多增加 4 个 Pod
periodSeconds: 15 #每 15 秒执行一次该策略（执行周期）
- type: Percent #规则类型（按百分比）
value: 10 #规则值（每次最多增加当前副本数的 10%）
periodSeconds: 60 #执行周期（每 60 秒执行一次该策略）
selectPolicy: Max #选择策略
stabilizationWindowSeconds: 0 #稳定窗口期（扩容时为 0 秒，即立即执行）默认为0秒
在这个示例中，HPA会在前15秒内尝试一次扩容4个Pod，而在60秒内尝试扩容当前Pod数量的10%。最终，HPA会选择扩容量更大的策略。
也就是说，HPA 每 15 秒最多允许增加 4 个 Pod；每 60 秒最多允许增加当前副本数的 10%。HPA会选择扩容数量最大的策略来执行。
scaleDown: #缩容策略配置
policies: #缩容规则列表
- type: Percent #规则类型（按百分比）
value: 10 #规则值（每次最多减少当前副本数的 10%）
periodSeconds: 60 #执行周期（每 60 秒执行一次该策略）
- type: Pods #规则类型（按 Pod 数量）
value: 2 #规则值（每次最多减少 2 个Pod）
periodSeconds: 120 #执行周期（每 120 秒执行一次该策略）
selectPolicy: Min #选择策略
stabilizationWindowSeconds: 300 #稳定窗口期（缩容时为 300 秒，防止在流量波动时频繁缩容）默认为300秒
在这个示例中，HPA会在60秒内尝试缩容当前Pod数量的10%，或在120秒内尝试缩容2个Pod。最终，HPA会选择缩容量更小的策略。
#压测前的状态
[root@master01 yaml]# kubectl get hpa,pod
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-test cpu: 0%/50%, memory: 5278378666m/200Mi 3 100 3 31s
NAME READY STATUS RESTARTS AGE
pod/nginx-test-5496f4c54d-d6j5s 1/1 Running 0 38m
pod/nginx-test-5496f4c54d-ndsk2 1/1 Running 0 34m
pod/nginx-test-5496f4c54d-sq7sb 1/1 Running 0 34m
#进行压测
[root@master01 yaml]# ab -c 1000 -n 1000000 http://192.168.135.150:30020/
#由3个扩到了7个
[root@master01 yaml]# kubectl get hpa,pod
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-test cpu: 130%/50%, memory: 6703786666m/200Mi 3 100 7 105s
NAME READY STATUS RESTARTS AGE
pod/nginx-test-5496f4c54d-d6j5s 1/1 Running 0 39m
pod/nginx-test-5496f4c54d-l2ffh 1/1 Running 0 14s
pod/nginx-test-5496f4c54d-ndsk2 1/1 Running 0 36m
pod/nginx-test-5496f4c54d-rv4xr 1/1 Running 0 15s
pod/nginx-test-5496f4c54d-sq7sb 1/1 Running 0 35m
pod/nginx-test-5496f4c54d-v9d6h 1/1 Running 0 14s
pod/nginx-test-5496f4c54d-zf82m 1/1 Running 0 15s
#再由7个扩到了12个
[root@master01 yaml]# kubectl get hpa,pod
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-test cpu: 14%/50%, memory: 5154816/200Mi 3 100 12 4m3s
NAME READY STATUS RESTARTS AGE
pod/nginx-test-5496f4c54d-7ztfm 1/1 Running 0 2m17s
pod/nginx-test-5496f4c54d-clvtq 1/1 Running 0 92s
pod/nginx-test-5496f4c54d-d6j5s 1/1 Running 0 42m
pod/nginx-test-5496f4c54d-f72v9 1/1 Running 0 92s
pod/nginx-test-5496f4c54d-l2ffh 1/1 Running 0 2m32s
pod/nginx-test-5496f4c54d-ndsk2 1/1 Running 0 38m
pod/nginx-test-5496f4c54d-q88jp 1/1 Running 0 2m17s
pod/nginx-test-5496f4c54d-rv4xr 1/1 Running 0 2m33s
pod/nginx-test-5496f4c54d-sq7sb 1/1 Running 0 38m
pod/nginx-test-5496f4c54d-v9d6h 1/1 Running 0 2m32s
pod/nginx-test-5496f4c54d-w5qdh 1/1 Running 0 2m17s
pod/nginx-test-5496f4c54d-zf82m 1/1 Running 0 2m33s
#停止压测后缩容到3个
加入behavior 行为策略后，HPA是如何工作的：
假设你的应用当前有 10 个 Pod，突然流量暴增，HPA 计算出理论上需要扩容到 20 个 Pod（即需要增加 10 个 Pod）。
此时，behavior 策略会介入，限制这个“一步到位”的冲动：
1. 检查策略一：Pods策略
规则：- type: Pods, value: 4, periodSeconds: 15
含义：在任意连续的 15 秒内，最多只能扩容 4 个 Pod。
计算：理论上要加 10 个，但该策略限制最多只能加 4 个。所以这条策略建议扩容 4 个。
2. 检查策略二：Percent策略
规则：- type: Percent, value: 10, periodSeconds: 60
含义：在任意连续的 60 秒内，最多只能扩容当前副本数（10个）的 10%，也就是 1 个 Pod。
计算：理论上要加 10 个，但该策略限制最多只能加 1 个。所以这条策略建议扩容 1 个。
3. 决策：selectPolicy: Max
逻辑：既然有两个限制，那么需要选择哪一个？Max 表示选择限制最宽松（即允许扩容数量更多）的那个。
结果：策略一允许加 4 个，策略二允许加 1 个。HPA 选择 4 个。
注意事项
Metrics Server 必须正常运行，HPA需要实时监控 Pod 的资源使用情况来决定是否扩容或缩容。这个数据是通过 Kubernetes 的 Metrics API 提供的。
HPA 的核心定位是 “自动扩缩容控制器”，作用是根据监控指标（如 CPU、内存、自定义指标）动态调整“工作负载控制器”的 Pod 副本数，它本身不直接管理 Pod，而是“控制工作负载控制器的 replicas 字段”。
不可以在DaemonSet使用，因为HPA根据指标（CPU、内存或自定义指标）动态调整 Pod 副本数，DaemonSet需要 确保每个符合条件的节点上运行且只运行一个 Pod副本，它的副本数是由集群中的节点数量决定的，而不是由负载决定的。
垂直自动扩缩容（VPA）
VPA（Vertical Pod Autoscaler）是 Kubernetes 中一个垂直自动扩缩容工具，用于自动调整Pod的资源请求和限制，可以根据容器的CPU和内存使用率自动调整其资源请求。如果某个容器当前的CPU或内存使用率较低，VPA可以减小其资源请求，从而释放不必要的资源；反之，如果某个容器当前的CPU或内存使用率较高，VPA可以增加其资源请求，以满足应用的性能需求。这种自动调整机制能够在满足应用需求的同时，最大限度地提高资源利用率。
可以调整所有能通过控制器（如 Deployment、StatefulSet、DaemonSet、Job 等）生成 Pod 的工作负载资源。
VPA 的工作原理
VPA 通过监控目标 Pod 的资源使用情况（如 CPU 和内存的实际占用），自动调整 Pod 的 resources.requests配置，从而让 Pod 获得更合适的计算资源。
1. 监控指标收集
与 HPA 类似，VPA 同样依赖 Kubernetes Metrics Server（或 Prometheus 等后端）来收集 Pod 的实时资源使用指标。它重点关注 Pod 的 CPU 和内存实际使用量，并结合历史数据（包括 OOM 事件）进行分析。
2. 资源推荐计算
VPA Recommender（推荐引擎）组件会定期分析收集到的指标数据。它会计算出一个“理想”的资源请求值（Requests）：
如果当前 Pod 经常跑满 CPU 或内存，Recommender 会建议增加资源请求。
如果当前 Pod 资源申请了很多（Requests很高）但实际用得很少，Recommender 会建议减少资源请求。
3. Pod 资源调整
这是 VPA 与 HPA 最大的区别所在。Kubernetes 不允许直接修改正在运行的 Pod 的资源限制，因此 VPA 的调整策略通常涉及 Pod 的重建：
驱逐（Eviction）：VPA Updater（更新器） 组件发现推荐值与当前 Pod 的资源配置差异较大时，会向 API Server 发出请求，驱逐（删除） 该 Pod。
重建（Recreation）：Pod 的控制器（如 Deployment）检测到 Pod 被删除后，会立即创建一个新的 Pod。
注入（Injection）：在新 Pod 创建的瞬间，VPA Admission Controller（准入控制器） 会拦截创建请求，并将 Recommender 计算出的最新资源推荐值“注入”到新 Pod 的定义中。
主要组件
Recommender
分析Pod历史资源使用情况
计算资源推荐值
基于历史数据和配置策略（如安全边界）提供建议
Updater
检查Pod是否需要调整资源
驱逐需要更新的Pod（触发重启）
仅在Auto工作模式下活跃
Admission Controller
拦截Pod创建请求
应用Initial模式的推荐值
修改Pod的资源规格
VPA的更新策略
VPA会根据Pod的实际使用情况，动态调整其CPU和内存的requests和limits避免资源过度分配或不足
四种工作模式：
Inittial
仅在Pod创建时修改资源请求，以后都不修改
Auto
默认策略，在Pod创建和更新时都会修改资源请求，并且在Pod更新时也会修改
Recreate
不仅会在Pod创建时应用推荐值，也会在运行时自动驱逐并重建Pod以应用新推荐，与Auto类似，但它比Auto模式更加直接
Off
不改变Pod的资源请求，不过会在VPA中设置资源的推荐值
Auto与Recreate的区别：
Auto：优先原地改，改不了再重建，Pod的IP地址可能会保留
Recreate：只要推荐值变了就重建，Pod的IP地址一定发生变化
安装VPA组件
#克隆代码
[root@master01 ~]# git clone https://github.com/kubernetes/autoscaler.git
#切换目录
[root@master01 ~]# cd autoscaler/vertical-pod-autoscaler/deploy/
#修改镜像的拉取策略和拉取地址
[root@master01 deploy]# sed -i 's/imagePullPolicy: Always/imagePullPolicy: IfNotPresent/g' ./*
[root@master01 deploy]# sed -i "s/registry.k8s.io\/autoscaling/uhub.service.ucloud.cn\/zgs_k8s/g" ./*
#切换目录
[root@master01 deploy]# cd ../hack/
#运行脚本启动容器
[root@master01 hack]# ./vpa-up.sh示例
#部署一个deployment
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx-test
name: nginx-test
spec:
replicas: 2 #副本数建议大于1
selector:
matchLabels:
app: nginx-test
template:
metadata:
labels:
app: nginx-test
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
resources: #VPA主要调整requests，limits可以独立设置
requests:
cpu: 100m
memory: 50Mi
---
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx-svc
name: nginx-svc
spec:
ports:
- name: 80-80
nodePort: 30020
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx-test
type: NodePort
#部署VPA
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: nginx-vpa-off
namespace: default
spec:
targetRef: #指定VPA要管理的目标工作负载
apiVersion: "apps/v1" #负载的API版本
kind: Deployment #负载的类型
name: nginx-test #目标Deployment的名称
updatePolicy: #定义VPA的工作模式
updateMode: "Off" #工作模式为Off，仅监控不会自动调整，但是会给出推荐值
#minReplicas: 2 #保持至少2个副本可用
resourcePolicy: #定义资源调整的策略和限制
containerPolicies: #策略配置
- containerName: "nginx" #指定要应用策略的容器名称，必须与Pod中容器名匹配
#controlledResources: ["cpu", "memory"] #同时调整CPU和内存（也就是控制调整哪些资源）
#controlledValues: "RequestsAndLimits" #控制调整什么值，指的是Pod中的resources
#RequestsOnly 只调整requests，不改变limits
#RequestsAndLimits requests和limits同时调整
#LimitsOnly 只调整limits
minAllowed: #允许的最小资源限制，VPA不会推荐低于此值的资源
cpu: "250m" #最小CPU限制
memory: "100Mi" #最小内存限制
maxAllowed: #允许的最大资源限制
cpu: "2000m" #最大CPU限制
memory: "2048Mi" #最大内存限制
注意：
在Kubernetes中，当容器使用的内存超过其limits限制时，会被杀死，所以不建议使用“LimitsOnly”，但是容器使用的CPU超过limits限制时是不会被杀死的，而是响应速度会变慢
#查看VPA状态
[root@master01 yaml]# kubectl get vpa
NAME MODE CPU MEM PROVIDED AGE
nginx-vpa-off Off 250m 250Mi True 15s
NAME： nginx-vpa-off VPA资源的名称
MODE： Off 工作模式为"仅监控"，不会自动调整
CPU： 250m 当前推荐的CPU值（250毫核，0.25个核心）
MEM： 250Mi 当前推荐的内存值（250兆字节）
PROVIDED： True VPA已为Pod提供了资源推荐
AGE： 15s VPA创建了15秒
#进行压测
[root@master01 ~]# ab -c 1000 -n 1000000 http://192.168.135.150:30020/
#查看VPA和POD的状态
[root@master01 ~]# kubectl top pod
NAME CPU(cores) MEMORY(bytes)
nginx-test-5496f4c54d-wsmt2 362m 12Mi
#VPA的CPU推荐值发生变化，但是Pod没有重启
[root@master01 yaml]# kubectl get vpa
NAME MODE CPU MEM PROVIDED AGE
nginx-vpa-off Off 442m 250Mi True 19m
#pod资源状况
[root@master01 yaml]# kubectl describe pod nginx-test-5496f4c54d-wsmt2 | grep -A 2 -i requests
Requests:
cpu: 100m
memory: 50Mi
#Auto模式
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: nginx-vpa-auto
namespace: default
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: nginx-test
updatePolicy:
updateMode: "Auto" #改为Auto
resourcePolicy:
containerPolicies:
- containerName: "nginx"
minAllowed:
cpu: "250m"
memory: "100Mi"
maxAllowed:
cpu: "2000m"
memory: "2048Mi"
#压测之前Pod的IP为173.28.243.202和173.28.243.201，CPU为100m，内存为50Mi
[root@master01 yaml]# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-test-5496f4c54d-dx2jh 1/1 Running 0 3s 173.16.0.202 node02.example.com <none> <none>
nginx-test-5496f4c54d-n6bcr 1/1 Running 0 3s 173.28.243.201 node01.example.com <none> <none>
[root@master01 yaml]# kubectl describe pod nginx-test-5496f4c54d-dx2jh nginx-test-5496f4c54d-n6bcr | grep -A 2 -i requests
Requests:
cpu: 100m
memory: 50Mi
--
Requests:
cpu: 100m
memory: 50Mi
#进行压测
[root@master01 ~]# ab -c 1000 -n 1000000 http://192.168.135.150:30020/
#IP和名称发生改变，说明Pod被驱逐重建
[root@master01 yaml]# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-test-5496f4c54d-d85m6 1/1 Running 0 95s 173.16.0.203 node02.example.com <none> <none>
nginx-test-5496f4c54d-ljj45 1/1 Running 0 34s 173.28.243.202 node01.example.com <none> <none>
#查看资源，CPU从100m扩容到了476m，内存扩容到了250Mi
[root@master01 yaml]# kubectl describe pod nginx-test-5496f4c54d-d85m6 nginx-test-5496f4c54d-ljj45 | grep -A 2 -i requests
Requests:
cpu: 476m
memory: 250Mi
--
Requests:
cpu: 476m
memory: 250Mi注意事项
VPA 在 Auto 模式下工作时，需要驱逐旧的 Pod 来强制应用新的资源配置，为了防止集群服务中断，VPA 组件内部有一个默认的安全检查机制。
如果工作负载的副本数 小于 2（也就是只有 1 个副本），VPA 默认会拒绝执行驱逐操作，或者仅仅停留在推荐阶段而不实际修改 Pod。这是因为 VPA 遵循“滚动更新”的原则：比如你有两个副本，杀掉一个 Pod 进行垂直扩容/缩容时，另一个 Pod 还能继续提供服务。
VPA 的推荐值可能会超出可用资源（例如CPU\内存可用大小、可用配额）并导致Pod 处于挂起状态。