Kubernetes HPA指标错误? [英] Kubernetes HPA wrong metrics?
问题描述
我已经在Google Cloud上创建了GKE测试集群.它具有3个带有2个vCPU/8 GB RAM的节点.我已经在上面部署了两个Java应用程序
I've created a GKE test cluster on Google Cloud. It has 3 nodes with 2 vCPUs / 8 GB RAM. I've deployed two java apps on it
这是Yaml文件:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapi
spec:
selector:
matchLabels:
app: myapi
strategy:
type: Recreate
template:
metadata:
labels:
app: myapi
spec:
containers:
- image: eu.gcr.io/myproject/my-api:latest
name: myapi
imagePullPolicy: Always
ports:
- containerPort: 8080
name: myapi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: myfrontend
spec:
selector:
matchLabels:
app: myfrontend
strategy:
type: Recreate
template:
metadata:
labels:
app: myfrontend
spec:
containers:
- image: eu.gcr.io/myproject/my-frontend:latest
name: myfrontend
imagePullPolicy: Always
ports:
- containerPort: 8080
name: myfrontend
---
然后,我想添加一个具有以下详细信息的HPA:
Then I wanted to add a HPA with the following details:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: myfrontend
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myfrontend
minReplicas: 2
maxReplicas: 5
targetCPUUtilizationPercentage: 50
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: myapi
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapi
minReplicas: 2
maxReplicas: 4
targetCPUUtilizationPercentage: 80
---
如果我查看kubectl顶部吊舱,它会显示一些非常奇怪的指标:
If I check kubectl top pods it shows some really weird metrics:
NAME CPU(cores) MEMORY(bytes)
myapi-6fcdb94fd9-m5sh7 194m 1074Mi
myapi-6fcdb94fd9-sptbb 193m 1066Mi
myapi-6fcdb94fd9-x6kmf 200m 1108Mi
myapi-6fcdb94fd9-zzwmq 203m 1074Mi
myfrontend-788d48f456-7hxvd 0m 111Mi
myfrontend-788d48f456-hlfrn 0m 113Mi
HPA信息:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
myapi Deployment/myapi 196%/80% 2 4 4 32m
myfrontend Deployment/myfrontend 0%/50% 2 5 2 32m
但是,如果我检查其中一个节点的正常运行时间,则会显示出较低的值:
But If I check uptime on one of the nodes it shows a less lower value:
[myapi@myapi-6fcdb94fd9-sptbb /opt/]$ uptime
09:49:58 up 47 min, 0 users, load average: 0.48, 0.64, 1.23
任何想法为什么它显示出完全不同的东西.为什么hpa显示当前CPU利用率的200%?因此,它也使用空闲状态下的最大副本数.有什么主意吗?
Any idea why it shows a completely different thing. Why hpa shows 200% of current CPU utilization? And because of this it uses the maximum replicas in idle, too. Any idea?
推荐答案
HPA的 targetCPUUtilizationPercentage
是
The targetCPUUtilizationPercentage
of the HPA is a percentage of the CPU requests of the containers of the target Pods. If you don't specify any CPU requests in your Pod specifications, the HPA can't do its calculations.
在您的情况下,似乎HPA假定 100m
作为CPU请求(或者您可能有一个LimitRange将默认的CPU请求设置为 100m
).当前Pod的使用量约为 200m
,这就是HPA显示利用率约为200%的原因.
In your case it seems that the HPA assumes 100m
as the CPU requests (or perhaps you have a LimitRange that sets the default CPU request to 100m
). The current usage of your Pods is about 200m
and that's why the HPA displays a utilisation of about 200%.
要正确设置HPA,您需要为Pod指定CPU请求.像这样:
To set up the HPA correctly, you need to specify CPU requests for your Pods. Something like:
containers:
- image: eu.gcr.io/myproject/my-api:latest
name: myapi
imagePullPolicy: Always
ports:
- containerPort: 8080
name: myapi
resources:
requests:
cpu: 500m
或您的Pod要求的任何值.如果将 targetCPUUtilizationPercentage
设置为80,则HPA将在使用 400m
时触发一次高级操作,因为 500m
的80%是 400m
.
Or whatever value your Pods require. If you set the targetCPUUtilizationPercentage
to 80, the HPA will trigger an upscale operation at 400m
usage, because 80% of 500m
is 400m
.
除此之外,您还使用了过时的HorizontalPodAutoscaler版本:
Besides that, you use an outdated version of HorizontalPodAutoscaler:
在v2beta2版本中,规范看起来有些不同.像这样:
With the v2beta2 version, the specification looks a bit different. Something like:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapi
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapi
minReplicas: 2
maxReplicas: 4
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80
请参见示例.
但是,上述CPU利用率机制仍然适用.
However, the CPU utilisation mechanism described above still applies.
这篇关于Kubernetes HPA指标错误?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!