Search
關鍵字: GKE, CPU Limit, CPU throttling
影響: 服務出現高延遲性，甚至出現錯誤
總結: 作者推薦關閉 Kubernetes 內任何 CPU Limit 的功能(或是從 kubelet 關閉 CFS quota)直到節點上的系統都已經修復 CFS 的相關問題，這個問題會導致不必要的 CPU throttling 並可能導致應用程式短暫時間卡住不回應。
這篇文章內容非常豐富，開頭介紹 container & kubernetes 的基本概念，接下來探討到底 CPU request/limit 是如何實作的，並且透過一個範例來介紹為什麼 kernel bug 會導致整個應用程式卡住
原文下方還有列出各種相關連結，包含 kernel 內的相關文件以及 kubernetes 內探討這個問題的 issue。
https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718
想必大家一定都有使用過 CPU Limit 的經驗，透過這個機制能夠確保每個 Container 使用的 CPU 資源量，也可以保證每個節點上面會有足夠 CPU 供 Kubernetes 原生服務 (kubelet) 使用。
然而本篇文章就要來跟大家分享一個設定 CPU Limit 反而造成效能更差的故事，故事中當 CPU 設定為 800ms 的時候，卻發現實際運行的 Container 最高大概就只有 200ms 左右，這一切的一切都是因為 Liniux Kernel 的臭蟲導致!
一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit，作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。
這個臭蟲於 Linux Kernel 4.19 後已經修復，但是要注意你使用的發行版本是否有有包含這個修復，作者列出一些已知的發行版本修復狀況
Debian: The latest version buster has the fix, it looks quite recent (august 2020). Some previous version might have get patched.
Ubuntu: The latest version Ubuntu Focal Fosa 20.04 has the fix.
EKS has the fix since December 2019, Upgrade your AMI if necessary.
kops: Since June 2020, kops 1.18+ will start using Ubuntu 20.04 as the default host image.
GKE: THe kernel fix was merged in January 2020. But it does looks like throttling are still happening.
有興趣的歡迎點選原文閱讀更多
https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/
