我有一個 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端點路由到入口路徑規則中的同步Pod
這有效;但是,我還沒有完成滿載測試。