我有一个 GKE Kubernetes 集群和一个部署。
我将部署中的资源节设置为
resources.requests.memory: 4G
resources.requests.cpu: 2
resources.limits.memory: 4G
未设置 CPU 限制
我部署了 pod(一个 Django Web 应用程序)并对其进行了负载测试。当达到饱和状态时,pod 的 CPU 使用率会上升到 1CPU——但基本上不会超过 1CPU
有什么想法我应该在这里解决什么问题吗?
答案1
我没有关闭这个帖子,所以我们就关闭它吧。
在我的具体案例中,瓶颈实际上出在 K8S Pod 的上游,即数据库。postgres 实例根本不够大,并且 CPU 使用率达到 100%,导致下游超时。
我怀疑,但不确定,Pod 上的 CPU 趋于平稳只是因为 Pod 正在等待上游的响应,并且由于没有其他事情可做,所以无法达到 1 CPU 使用率。
此外,Django 实例使用 Django 通道和 ASGI 异步模型,它是单线程的,并且没有与 UWSGI 相同的“子线程”模型;另一个原因 —— 或者可能是实际原因 —— Pod 上的 CPU 使用率最大为 1CPU。
所以我确信正确的做法是
- 垂直扩展 Postgres
- 增加 Pod 的基线数量
- 降低自动扩缩器 (HPA) 的阈值以进行扩缩并添加新的 Pod
编辑:附加信息
这个问题还与应用程序本身的设计方式有关。我们尝试使用 Django Channels 异步 Python 并在 Daphne ASGI 容器中运行 htat;但是,并非所有应用程序都是异步的,显然,这很糟糕。我对这个异步与同步应用程序问题以及由此导致的死锁进行了大量研究,在让开发团队重新设计应用程序的同时,我还重新设计了部署
- 将 uWSGI 服务器添加到部署中
- 将代码库部署到两个 Deployment/Pod 中
- 一个有 ASGI Pod
- 其中一个有 uWSGI Pod
- 将所有 ASGI 端点(只有一个)路由到 Ingress Path 规则中的 ASGI pod
- 将所有 uWSGI 端点路由到 Ingress Path 规则中的同步 Pod
这是可行的;然而我还没有完成完整的负载测试。