尽管在Pod模板中指定了限制并请求资源,但是只有一个Pod正在消耗所有计算资源

时间:2019-06-06 12:03:37

标签: python-3.x kubernetes kubernetes-pod

我正在根据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之间。

在此先感谢您的观点/帮助/提示。

1 个答案:

答案 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/