python-3.x - 尽管在 pod 模板中指定了限制和请求资源，但只有一个 Pod 正在消耗所有计算资源

Question

我正在根据 CPU 和内存利用率来扩展 ML 预测。我已经将 HPA 用于 pod 级别的扩展，我们指定了 CPU 和内存指标。在创建deployment的时候，我还指定了requests的计算资源和限制。(我已经粘贴了HPA配置和pod模板配置供引用)

我观察到，虽然我们指定了资源限制和请求，但当我检查每个 Pod 消耗的内存和 CPU 时，它显示只有一个 Pod 消耗了所有 CPU 和内存资源，而其他 Pod 消耗的计算资源非常少。根据我的理解，所有 pod 都应该消耗大约等于资源，所以我们可以说它是缩放的，否则就像在单台机器上运行没有 k8s 的代码一样。

注意:我使用 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(根本原因分析)，我们通过运行 ipvsadm -ln 进行了验证在我们的 kubernetes 集群中处理工作负载时，发现有效负载只建立了一个 TCP 连接，这导致所有工作负载都集中在一个 pod 中，即使其他 pod 可用。

我们的应用程序基于 GRPC，GRPC 使用 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/