我正在根据CPU和内存利用率扩展ML预测。我已经使用HPA进行Pod级缩放,在此我们同时指定了CPU和内存指标。在创建部署时,我还为请求指定了计算资源和限制(我粘贴了HPA配置和Pod模板配置供参考)
我观察到,尽管我们指定了资源限制和请求,但是当我检查每个Pod消耗的内存和CPU时,它表明只有一个Pod正在消耗所有CPU和内存资源,而其他Pod却消耗了非常少的计算资源。根据我的理解,所有Pod都应消耗大约相等的资源,因此我们可以说它是按比例缩放的,否则就像在单台机器上运行没有k8的代码一样。
注意:我正在使用python k8s客户端创建部署和服务,而不是Yaml。
我尝试通过限制和资源参数进行调整,并发现由于这是ML管道,因此内存和cpu消耗在某个时候呈指数增长。
我的HPA配置:-
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
namespace: default
name: #hpa_name
spec:
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: #deployment_name
minReplicas: 1
maxReplicas: 40
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 80
- type: Resource
resource:
name: memory
targetAverageValue: 5Gi
我的广告连播模板代码-
container = client.V1Container(
ports=[client.V1ContainerPort(container_port=8080)],
env=[client.V1EnvVar(name="ABC", value=12345)],
resources=client.V1ResourceRequirements(
limits={"cpu": "2", "memory": "22Gi"},
requests={"cpu": "1", "memory": "8Gi"},
),
kubectl top pods
的输出
NAME CPU(cores) MEMORY(bytes)
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-77c6ds 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7d5n4l 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7dq6c9 14236m 16721Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7f6nmh 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7fzdc4 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7gvqtj 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7h6ld7 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7j7gv4 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7kxlvh 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7nnn8x 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7pmtnj 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7qflkh 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7s26cj 1m 176Mi
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7st5lt 1m 176Mi
通过上面的输出,很明显,第三荚使用了大部分资源,而其他荚处于不变的内存和CPU消耗中。
我的期望是,每个吊舱应根据吊舱模板请求中指定的限制和资源消耗大致相等的资源。在这种情况下,CPU消耗应该在1个CPU到2个CPU之间,而内存/少于请求的资源却应该在8 Gi到22 Gi之间。
在此先感谢您的观点/帮助/提示。
答案 0 :(得分:2)
根据此问题的RCA(根本原因分析),我们在处理kubernetes集群中的工作负载时运行ipvsadm -ln
进行了验证,发现有效负载仅建立了一个TCP连接,这导致所有工作负载即使有其他豆荚可用,也要集中在一个豆荚中。
我们的应用程序基于GRPC,GRPC使用HTTP / 2。 HTTP / 2具有创建单个长期TCP连接的功能,并且在同一TCP连接下对请求进行多路复用,以最大程度地减少TCP连接管理开销。因此,单个Pod上存在一个长期存在的TCP连接,并且由于HPA会增加内存和CPU的使用量,因此它可以扩展Pod,但不会分散负载。因此,我们需要一种机制来将负载分配到连接级别负载均衡(这是kubernetes中的默认负载均衡)旁边的一个步骤,以请求级别负载均衡。
幸运的是,我们找到了以下解决方案,我们遵循了这一要求,并且对我们有用。
https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/