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

Question

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

我的pod模板代码-

 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           

通过以上输出，很明显，第三个pod利用了大部分资源，而其他pod则处于恒定的内存和CPU消耗，这非常少。

我的期望是每个pod应该消耗大约等于基于pod模板请求中指定的限制和资源的资源。在这种情况下，CPU消耗应该在1个CPU到2个CPU之间，内存应该在8 Gi到22 Gi之间/少于请求的资源，但不超过定义的限制。

提前感谢任何积分/帮助/提示。

Answer 1

根据此问题的RCA(根本原因分析),我们在处理我们的kubernetes集群中的工作负载时通过运行< code>ipvsadm -ln进行了验证，发现只有一个TCP连接是由有效负载建立的，这导致所有工作负载都集中在一个pod中，即使其他pod可用。

我们的应用程序基于遗传资源，而我国的准则第一标准使用HTTP/2。HTTP/2 具有创建单个长期 TCP 连接的功能，并且请求在同一 TCP 连接下进行多路复用，以最大程度地减少 TCP 连接管理开销。因此，有一个长期存在的TCP连接连接到单个Pod，并且由于内存和CPU的HPA峰值，它可以缩放Pod，但负载不会分布。因此，我们需要一些机制来分配负载，仅次于连接级负载平衡（这是 kubernetes 中的默认负载平衡）以请求级负载平衡。

幸运的是，我们找到了下面的解决方案，我们遵循了这一点，它对我们很有效。

https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/