HPA 是 Kubernetes 提供了一个弹性伸缩的重要功能，简单来说就是支持在应用资源消耗量很大的情况下，根据用户配置的阈值来自动进行扩容，减少人工的介入；在应用资源消耗量很小的情况下，进行缩容，进而减少资源的消耗量，达到节约成本的目的。本文会先从几个方面来讲解 HPA 的功能、使用、扩展及使用，分别为 HPA背景、HPA原理、HPA组件、HPA功能及算法细节、Demo示例、HPA 高级使用、自定义指标、定时扩容、HPA相关项目、HPA源码分析。由于一篇文章写完以上所有章节，会比较多内容，因此这里会分章节说明
一、HPA 背景
HPA 全称是 Horizontal Pod Autoscaler（水平扩缩），是通过 kubernetes HPA Controller(控制器）来实现对 workload(可理解为业务应用）进行自动的扩容和缩容。下面从两个方面来分析一下背景
业务并不是全天候都是高负载情况，但同时为了应对每日或者活动期间的随机高峰流量，业务经常会将应用部署很多副本，很多时候都是负载很低，进而导致资源利用率很低
业务并不能准确评估服务所需的 CPU、内存等资源，一般都设置比较大，进而导致资源利用率低
因此，为了解决业务资源利用率低、评估不准确等问题，需要通过动态调整方式来提高资源的利用率
目前 kubernetes 提供了三种维度的弹性扩缩方案：
Cluster Autoscaler: 自动扩展和收缩 Kubernetes 集群 Node 的扩展，当集群容量不足时，它会自动去 Cloud Provider （支持 GCE、GKE 和 AWS）创建新的 Node，而在 Node 长时间资源利用率很低时自动将其删除以节省开支
Vertical Pod Autoscaler: 用户无需为其pods中的容器设置最新的资源request。配置后，它将根据使用情况自动设置request，从而允许在节点上进行适当的调度，以便为每个pod提供适当的资源量，目前是 beta 状态
Horizontal Pod Autoscaler: 基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 StatefulSet 中的 Pod 数量。除了 CPU 利用率，也可以基于其他应程序提供的 自定义度量指标 来执行自动扩缩
这里我们只针对于 HPA 进行讲解，另外两种组件不展开
二、HPA 原理
HPA 是如何工作的
下面图片描述了HPA的工作流程，HPA 是通过一个控制循环（HPA Controller)来定时对应用进行动态扩缩容的，通过启动k8s时配置 –horizontal-pod-autoscaler-sync-period 参数指定周期（默认值为 15 秒）。
每个周期内，HPA Controller 通过用户定义的 hpa 规则（下面会讲到），比如通过资源度量指标 API（可能是 metrics-server 或者 custom-resource-server 服务提供)来获取相应的CPU、Memory指标数据。
这里需要了解一下 k8s 的 APIServer 扩展API的两种方式：
1、通过 API Aggregation聚合层将外部服务注册到APIServer的特定接口(metrics-server、custom-resource-server）
2、通过 CRD 方式提供服务（这里不涉及）
HPA 提供了三种指标接口，用于不同指标信息的提供：
对于资源指标，将使用 metrics.k8s.io API，一般由 metrics-server 提供
对于自定义指标，将使用 custom.metrics.k8s.io API。 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供（比如 prometheus-adapter)
对于外部指标，将使用 external.metrics.k8s.io API。可能由上面的自定义指标适配器提供。
下图就是 HPA 调用以上注册的接口进行指标获取的流程图
有个更具体的 网易轻舟提供的架构图
HPA 执行步骤：
1、HPA Controller 每隔 15s 进行一次流程，先获取用户定义的 HPA规则，然后通过 aggregator 层，请求 metrics-server 获取 CPU 利用率
2、metrics-server 定时从 kubelet 的接口获取到相应的应用指标情况
3、kubelet 是通过内置的 cadvisor(指标收集组件），本质上是通过读取获取 /sys/cgroup/ 下应用的资源情况
4、根据 metrics-server 获取的 CPU 利用率，根据计算公式（下面会说到），得出新的副本数
5、如果用户当前的副本数与计算出来的不一致，则执行扩容或缩容的流程，最终也是把 deployment 资源的 replica （副本值）修改成计算的值
6、Deployment Controller 通过监控到副本值的变化，最终进行pod的扩缩动作
三、HPA组件
从 HPA 的架构图可以看出，如果需要完整使用 HPA 的全部指标类型，那么提供三个接口所需的服务
metrics-server: 通过 metrics.k8s.io API 提供服务
custome-metrics-server: 通过custom.metrics.k8s.io API 提供服务
external-metrics-server: 通过 external.metrics.k8s.io API 提供服务
并不是一定是三个组件，像 prometheus-adapter, 已经实现了 metrics-server 组件的接口。因此安装了 prometheus-adapter 就不需要额外安装 metrics-server
metrics-server 的安装
安装步骤：
# 使用 yaml 方式在 k8s 集群安装
$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# 使用 helm chart 方式安装(前提是需要先安装 helm)
$ helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
metrics-server 安装完成后， kubectl top 命令就可用，平时需要查看某个pod 的CPU、内存情况，可直接通过该命令查看
验证安装是否成功
# 查看 metrcis-server 是否部署成功
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get pods -n kube-system -l k8s-app=metrics-server
NAME READY STATUS RESTARTS AGE
metrics-server-96bbfd9f5-mz75w 1/1 Running 3 (72m ago) 8d
# 查看 API 是否注册成功
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get apiservice | grep metrics
v1beta1.metrics.k8s.io kube-system/metrics-server True 8d
# 尝试获取节点指标信息
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq
{
"kind": "NodeMetricsList",
"apiVersion": "metrics.k8s.io/v1beta1",
"metadata": {
"selfLink": "/apis/metrics.k8s.io/v1beta1/nodes"
},
"items": [
{
"metadata": {
"name": "minikube",
"selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/minikube",
"creationTimestamp": "2022-04-10T02:46:10Z"
},
"timestamp": "2022-04-10T02:45:49Z",
"window": "30s",
"usage": {
"cpu": "138063026n",
"memory": "1332100Ki"
}
}
]
}
# 使用 kubectl top 查看应用的CPU及内存
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl top pod --all-namespaces
NAMESPACE NAME CPU(cores) MEMORY(bytes)
kube-system coredns-65c54cc984-d9w46 0m 1Mi
kube-system etcd-minikube 0m 0Mi
kube-system kube-apiserver-minikube 0m 0Mi
kube-system kube-controller-manager-minikube 0m 0Mi
kube-system kube-proxy-hbwsc 0m 2Mi
kube-system kube-scheduler-minikube 0m 2Mi
kube-system metrics-server-96bbfd9f5-mz75w 0m 0Mi
kube-system storage-provisioner 0m 3Mi
custom-metrics-server 的安装
因为 custom-metrics-server 有很多开源项目或者公司都提供了自己的实现，这里只介绍promethues-adapter 的使用
安装步骤
# helm 是 k8s 的包管理工具，类似于 mac 的 brew，入门可参考：[https://www.jianshu.com/p/4bd853a8068b(Helm](https://www.jianshu.com/p/4bd853a8068b(Helm) 从入门到实践)`
$ helm repo add prometheus-community https:``//prometheus-community``.github.io``/helm-charts`
$ helm repo update`
$ helm` `install` `--name my-release prometheus-community``/prometheus-adapter`
安装成功验证
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq
{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "custom.metrics.k8s.io/v1beta1",
"resources": []
}
四、HPA功能及算法细节
这章节主要介绍 HPA 提供的功能（各种指标的扩缩）、版本的演化及相关算法细节
HPA 演进历程
目前 HPA 已经支持 autoscaling/v1、autoscaling/v2beta1 和 autoscaling/v2beta2、 autoscaling/v2 共四个版本
autoscaling/v1: 只支持设置 CPU 一个指标进行弹性伸缩
autoscaling/v2beta1: 增加了自定义指标
autoscaling/v2beta2: 支持外部指标（当前使用）
autoscaling/v2： 貌似还没正式发布，只是有接口文档定义，和 v2beta2 没有区别
v1 版本示例
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
v2beta2 版本:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
- type: Pods
pods:
metric:
name: packets-per-second
target:
type: AverageValue
averageValue: 1k
- type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
type: Value
value: 10k
- type: External
external:
metric:
name: queue_messages_ready
selector: "queue=worker_tasks"
target:
type: AverageValue
averageValue: 30
注：最开始 metrics.k8s.io 接口是通过 Heapster 提供指标信息，后续才更新为 metrics-server
HPA 算法细节
Pod 水平自动扩缩控制器根据当前指标和期望指标来计算扩缩比例，后续会单独一章讲解伸缩算法的演进
期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]
举个例子：
# 扩容计算
当前指标： 200m
期望指标： 100m
当前副本数： 1
期望副本数 = ceil(1 * (200 / 100)) = 2
# 缩容计算
当前指标： 50m
期望指标： 100m
当前副本数： 1
期望副本数 = ceil(1 * (50 / 100)) = 0.5 接近 1
注意点：扩缩容还有一个全局设置：horizontal-pod-autoscaler-tolerance，容忍值，默认为 0.1，如果计算出来的副本数在这个范围之内，则不进行扩缩容操作。举个例子，比如 HPA 设置 CPU 使用率超过 50% 就触发扩容，因为容忍值为 0.1, 因此只有当 CPU 使用率大于 50% + 50% * 0.1 = 55% 才会触发扩容动作。
虽然算法是很简单，但是 HPA 在计算时会做很多逻辑判断，来保证 HPA 功能的正常使用
1、通过全局参数控制扩缩容频率
旧版本提供了两个全局参数用于控制扩缩容的频率
horizontal-pod-autoscaler-upscale-delay： 默认值为 3 min, 表示第一次扩容后，需要间隔 3min后才能第二次扩容（目前新版本已经去除该参数，扩容本质上是不需要冷却时间的）
horizontal-pod-autoscaler-downscale-delay： 默认值为 5min, 表示第一次缩容后，需要间隔 5min后才能再次缩容
从 v1.12 版本开始，HPA算法调整后，扩容的冷却时间就不需要设置，缩容冷却时间通过
–horizontal-pod-autoscaler-downscale-stabilization 设置，默认值为 5 min
2、计算时针对Pod 异常的优化
HPA 的计算指标都来自 pod，而因为 deployment 频繁地扩缩容，pod 的数量、状态以及负载情况一直在变化，会导致 HPA 在执行时，获取的指标存在一定的异常,。
比如，
Pod 正在关闭（标记了delete_timestamp) 或者 pod 状态为 failed
Pod 由于业务代码初始化比较久，还没 Running，都会导致 metrcis 指标的缺失（metrcis-server 采集不到这种pod的指标数据）
HPA 将 deployment 的所有 pod 的 metrics 指标分为三种集合
ready pods， Running状态的Pod且能够通过metrics-server(或其它服务）获取的pod指标数据的列表
ignore pods， pending状态的Pod 或者 pod running 并且能够获取到 pod 指标数据，但是pod的启动时间在配置的 initial-readiness-delay和cpu-initialization-period 保护期内
missing pods， 处于running状态的pod（非pending、非failed、非deleted状态）， 但是无法获取到 pod 指标数据的列表
以上三个集合的使用如下：
1、在计算pod的平均metrics值的时候，统一把 ignore pods的metrics设置为最小值0，
2、如果HPA扩缩容的方向是扩容，把missing pods的metrics也设置为最小值0，
3、如果是缩容方向则把missing pods的metrics也设置为最大值（如果是Resouce类型，最大值是Pod的request值，否则最大值就是target value）
这种计算策略比较保守，能够最小程度减少HPA 功能对业务容器的频繁变动
总结：
正在关闭的 pod 或 failed pod 不会参与HPA 计算
Pod 指标信息缺少时，在最后计算扩缩副本数的时候才会参与计算
使用 CPU 指标扩缩容时，未就绪（pending) 和刚就绪的 Pod 也不会参与计算
指标信息缺少的Pod，在缩容时，当成 100% 计算，在扩容时，当成 0% 计算
未就绪和刚就绪的Pod, 默认当成 0% 计算
注：这里列出一下 HPA 所有全局的配置参数
kube-controller-manager中包含了多个跟Pod 水平自动伸缩相关的启动参数：
参数名
参数描述
horizontal-pod-autoscaler-sync-period
controller控制循环的检查周期（默认值为15秒）
horizontal-pod-autoscaler-upscale-delay
上次扩容之后，再次扩容需要等待的时间，默认
horizontal-pod-autoscaler-downscale-stabilization
上次缩容执行结束后，再次执行缩容的间隔，默认5分钟
horizontal-pod-autoscaler-downscale-delay
上次扩容之后，再次扩容需要等待的时间，
horizontal-pod-autoscaler-tolerance
缩放比例的容忍值，默认为0.1，即在0.9~1.1不会触发扩缩容
horizontal-pod-autoscaler-use-rest-clients
使用rest client获取metric数据，支持custom metric时需要使用
horizontal-pod-autoscaler-cpu-initialization-period
pod 的初始化时间， 在此时间内的 pod，CPU 资源指标将不会被采纳
horizontal-pod-autoscaler-initial-readiness-delay
pod 准备时间， 在此时间内的 pod 统统被认为未就绪
五、Demo示例
步骤1：首先需要新增一个 nginx 应用，部署为 deployment （注：该配置是有点小问题的， HPA是不能计算利用率信息）
apiVersion: apps/v1
kind: Deployment
metadata:
name: hpa-demo
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
步骤2：使用 kubectl 命令部署 nginx deployment 和 hpa 对象
# 部署应用
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl apply -f hap-demo.yaml
deployment.apps/hpa-demo created
# 查看应用部署状态
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
hpa-demo 0/1 1 0 31s
my-release-prometheus-adapter 1/1 1 1 9d
# 创建 HPA 对象
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl autoscale deployment hpa-demo --cpu-percent=10 --min=1 --max=10
horizontalpodautoscaler.autoscaling/hpa-demo autoscaled
# 查看 HPA 状态
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hpa-demo Deployment/hpa-demo
# 查看 HPA 详细信息
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl describe hpa hpa-demo
Warning: autoscaling/v2beta2 HorizontalPodAutoscaler is deprecated in v1.23+, unavailable in v1.26+; use autoscaling/v2 HorizontalPodAutoscaler
Name: hpa-demo
Namespace: default
Labels:
Annotations:
CreationTimestamp: Tue, 19 Apr 2022 20:42:29 +0800
Reference: Deployment/hpa-demo
Metrics: ( current / target )
resource cpu on pods (as a percentage of request):
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 0 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute the replica count: failed to get cpu utilization: missing request for cpu
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 5s (x2 over 20s) horizontal-pod-autoscaler failed to get cpu utilization: missing request for cpu
Warning FailedComputeMetricsReplicas 5s (x2 over 20s) horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: missing request for cpu
由上面步骤可以知道，创建 HPA 成功后 ，由于没有设置 request, 导致 HPA Events 出现错误 failed to get cpu utilization: missing request for cpu ，因为 HPA默认是通过实际的利用率/request作为利用率的数值，因此可以检查Pod的Resource字段中是否包含Request字段。
步骤3：将上面的应用的 yaml 修改为如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: hpa-demo
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
resources: # 新增内容
requests:
memory: 50Mi
cpu: 50m
步骤4：然后通过 kubectl 更新 nginx deployment 的配置
# 更新 nginx 应用
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl apply -f hpa.yaml
deployment.apps/hpa-demo configured
# 删除 HPA 对象
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl delete hpa hpa-demo
horizontalpodautoscaler.autoscaling "hpa-demo" deleted
# 重新创建 HPA 对象
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl autoscale deployment hpa-demo --cpu-percent=10 --min=1 --max=10
horizontalpodautoscaler.autoscaling/hpa-demo autoscaled
步骤5：对 nginx 应用进行压测
# 获取 nginx 应用 pod 的 IP
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl get pod -o wide
# 新增压测环境 test-hpa， 在容器内部对 nginx 应用进行压测
╭─guoweikuang@guoweikngdeMBP2 ~
╰─$ kubectl run -it --image busybox test-hpa --restart=Never --rm /bin/sh
If you don't see a command prompt, try pressing enter.
/ # while true; do wget -q -O- http://
步骤6：查看 hpa 扩缩情况
# 查看 pod 的 CPU、内存指标变化
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
hpa-demo-6b4467b546-75dv8 138m 4Mi
test-hpa 471m 0Mi
# 查看 HPA 扩容具体情况，可以通过 Event 看出，当前CPU使用率 264% 远大于设置的10%，因此进行扩容操作
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl describe hpa hpa-demo
Name: hpa-demo
Namespace: default
Labels:
Annotations:
CreationTimestamp: Wed, 20 Apr 2022 00:20:00 +0800
Reference: Deployment/hpa-demo
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): 264% (132m) / 10%
Min replicas: 1
Max replicas: 10
Deployment pods: 1 current / 4 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 4
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited True ScaleUpLimit the desired replica count is increasing faster than the maximum scale rate
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 2m32s horizontal-pod-autoscaler failed to get cpu utilization: did not receive metrics for any ready pods
Warning FailedComputeMetricsReplicas 2m32s horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: did not receive metrics for any ready pods
Normal SuccessfulRescale 32s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
# 扩容因为没有冷却窗口的限制，因此一直扩容达到了 10个
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl describe hpa hpa-demo
Name: hpa-demo
Namespace: default
Labels:
Annotations:
CreationTimestamp: Wed, 20 Apr 2022 00:20:00 +0800
Reference: Deployment/hpa-demo
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): 0% (0) / 10%
Min replicas: 1
Max replicas: 10
Deployment pods: 10 current / 10 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True ScaleDownStabilized recent recommendations were higher than current one, applying the highest recent recommendation
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited True TooManyReplicas the desired replica count is more than the maximum replica count
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 5m8s horizontal-pod-autoscaler failed to get cpu utilization: did not receive metrics for any ready pods
Warning FailedComputeMetricsReplicas 5m8s horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: did not receive metrics for any ready pods
Normal SuccessfulRescale 3m8s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 2m8s horizontal-pod-autoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 68s horizontal-pod-autoscaler New size: 10; reason:
# 查看 pod 的创建情况
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl get pod
NAME READY STATUS RESTARTS AGE
hpa-demo-6b4467b546-22dwf 0/1 ContainerCreating 0 73s
hpa-demo-6b4467b546-4kfbc 0/1 ContainerCreating 0 73s
hpa-demo-6b4467b546-75dv8 1/1 Running 0 6m20s
hpa-demo-6b4467b546-c979v 1/1 Running 0 2m13s
hpa-demo-6b4467b546-cj8tv 0/1 ContainerCreating 0 13s
hpa-demo-6b4467b546-k2gkv 1/1 Running 0 2m13s
hpa-demo-6b4467b546-k8qb7 1/1 Running 0 2m13s
hpa-demo-6b4467b546-rqjm2 0/1 ContainerCreating 0 13s
hpa-demo-6b4467b546-tscgj 0/1 ContainerCreating 0 73s
hpa-demo-6b4467b546-zvzdz 1/1 Running 0 73s
test-hpa 1/1 Running 0 4m18s
步骤7：停止压测，查看HPA情况
# 没有压测后，cpu 使用率很快降下来，HPA 开始执行缩容操作
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl describe hpa
Name: hpa-demo
Namespace: default
Labels:
Annotations:
CreationTimestamp: Wed, 20 Apr 2022 00:20:00 +0800
Reference: Deployment/hpa-demo
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): 0% (0) / 10%
Min replicas: 1
Max replicas: 10
Deployment pods: 10 current / 1 desired
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
ScalingLimited True TooFewReplicas the desired replica count is less than the minimum replica count
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 13m horizontal-pod-autoscaler failed to get cpu utilization: did not receive metrics for any ready pods
Warning FailedComputeMetricsReplicas 13m horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: did not receive metrics for any ready pods
Normal SuccessfulRescale 11m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target
Normal SuccessfulRescale 9m4s horizontal-pod-autoscaler New size: 10; reason:
Warning FailedGetResourceMetric 6m4s horizontal-pod-autoscaler failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Warning FailedComputeMetricsReplicas 6m4s horizontal-pod-autoscaler invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
# 检查缩容后的应用的副本数
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
hpa-demo 1/1 1 1 16m
# 检查 hpa 的相关信息
╭─guoweikuang@guoweikngdeMBP2 ~/hpa
╰─$ kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hpa-demo Deployment/hpa-demo 0%/10% 1 10 1 15m