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

Question

我正在根据 CPU 和内存利用率扩展 ML 预测。我使用 HPA 进行 Pod 级别的扩展，其中我们指定了 CPU 和内存指标。在创建部署时，我还指定了请求计算资源和限制。(我已经粘贴了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

我的豆荚模板代码-

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 集群中处理工作负载时运行ipvsadm -ln进行验证，发现有效负载只建立了一个 TCP 连接，这会导致所有工作负载都集中在一个 pod 中，即使其他 pod 可用。

我们的应用程序基于 GRPC，GRPC 使用 HTTP/2。HTTP/2具有创建单个长寿命TCP连接的功能，并且请求在同一TCP连接下多路复用，以最大程度地减少TCP连接管理开销。因此，有一个长期存在的TCP连接连接到单个Pod，并且由于HPA在内存和CPU中达到峰值，因此它可以扩展Pod，但负载不会分布。因此，我们需要一些机制来将负载分配到连接级负载均衡(这是 kubernetes 中的默认负载均衡)旁边的一步，以请求级别的负载均衡。

幸运的是，我们找到了下面的解决方案，我们遵循了这个解决方案，它对我们有用。

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