今天這篇文章是經驗談,由 Intuit 的人來探討管理 200 個不同大小 Kubernetes Cluster 上關於 Scale 的各種經驗。Intuit 同時管理由 AWS EKS 提供的 Kubernetes 服務以及地端自行架設管理的 K8s。
針對 Scale 這個議題,其探討了五個面向帶來的各種挑戰,每個挑戰分成
1. What -> 這個議題要探討什麼
2. How -> 如何做
3. Benefits -> 帶來的好處
4. Leaning -> 學到的經驗
這五個議題分別是
1. Vertical Scale
2. Horizontal Scale
3. Reliability
4. Upgrade
5. Stability
整篇文章算偏長,這邊針對第一個議題進行介紹,對於後續有興趣的人可以在參閱全文
Vertical Scale
What:
目標就是提高應用程式的效能,主要方向是
1) 找到合適的機器規格等級
2) 應用程式根據機器規格能夠最佳化其效能
3) 提升整體的 TPS 數值
How:
1) 針對 GC 的規則調整,提升應用程式效能
2) 節點規格調整,從 Largr -> 4XLarge
3) 確認限定的 CPU/Memory 中可以運行多少個 Pod
4) 使用 HAP 來調整 Pod 的數量
Benefits:
1) TPS 從一開始轉移的 10TPS 提升到最高 10K TPS
Learning:
1) 動態建立節點且將服務部署上去大概需要 5-7 分鐘的時間,事先創好節點的話可以節省時間
2) 團隊需要於 10 分鐘內 scale 超過100以上的資源,這部分預設的 HPA 沒有辦法順利達成,團隊真的問題修改 Scale 的條件
對全文有興趣的可以參考看看,裡面文章滿長的,並不是很容易讀懂全部,需要閱讀多次才好懂。
https://sumitnagal.medium.com/operating-kubernetes-at-scale-65a3e76d74ad
「k8s pod 數量」的推薦目錄:
- 關於k8s pod 數量 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於k8s pod 數量 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於k8s pod 數量 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於k8s pod 數量 在 [Kubernetes] 分配& 管理container 所使用到的計算資源 的評價
- 關於k8s pod 數量 在 kubernetes常用运维命令或脚本.md 的評價
- 關於k8s pod 數量 在 Kubernetes (五) - 實現Pod 的AutoScaling - Tienyu Note 的評價
- 關於k8s pod 數量 在 K3s 设置max-pod - Ksd的博客 的評價
k8s pod 數量 在 矽谷牛的耕田筆記 Facebook 的最佳解答
這是一篇幻想文,幻想如果你可以重新設計 Kubernetes,你會希望有什麼樣的改動。也因為是幻想文,所以以下所提的東西不一定真的可以實作,也沒有考慮實作上可能會有什麼困難。原文非常的長,所以這邊就稍微列出一些內容
# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜,從 MetalLB 的開發經驗來看,幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速,一些不相容的修改也很難除錯,往往導致這些整合應用程式一起壞掉。
此外,作者使用 GKE 的經驗讓他覺得就算是這些k8s專家,也很難大規模環境中平安順利的使用 k8s.
作者認為 k8s 就像是管理平台內的 c++,功能非常強大,什麼都可以做,但是它會一直傷害你,直到你奉獻餘生該領域內。
作者期盼有一天,可以出現一個像是 go 語言的管理平台,簡單,優雅,容易學習
接下來就來看一下如果時光倒流,作者會希望 k8s 有哪些功能
# Mutable Pod
不像其他的資源一樣, Pod 這個資源基本上是不能修改的,有任何的更動都需要先刪除,後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說,我透過 kubectl edit 修改了 Pod Image,然後只要透過 SIGTERM 送給 Runc 底層容器,然後當該 Container 被重啟,就會使用新的設定。這一切的發生都在同一個 Pod 的資源內,而不是重新產生一個新的 Pod
# Version control all the things
當 Pod 可以修正後,下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化
為了實現這個功能,可能每個節點上面也要去紀錄過往的所有 image 版本資訊,並且加上 GC 等概念來清除過期或是太舊的內容
# Replace Deployment with PinnedDeployment
相對於 Deployment, PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。
舉例來說,我今天要將 Nginx 從 1.16 升級到 1.17,我可以透過 PinnedDeployment 去部署 Nginx,其中 1.16 佔了 60% ,而新版本 1.17 佔了 40%。
當一切轉移都沒有問題後,可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。
# IPv6 only, mostly
作者期望能的話,想要把 k8s networking 內的東西全部移除,什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。
k8s 全面配置 IPv6,而且也只有 IPv6,通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6,這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故,所有的存取都採用 Routing 的方式,封裝之類的玩法也不需要了。
文章內還提了很多東西,譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上,可以怎麼做,如何設計 NAT64 等,算是非常有趣的想法
# Security is yes
作者認為安全性方面要最大強化,預設情況下要開啟 AppArmor, seccomp profile 等控管機制,同時也要全面禁止用 Root 來運行容器, 基本上就是用非常嚴格的方式來設定安全性方面的規則。
目前 Kubernetes 內的資源, Pod Security Policy 非常類似作者想要完成的東西,通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。
# gVisor? Firecracker?
從安全性考量出發,是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc,同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境
# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine,也許就會像是將 kubevirt 變成一個內建的功能,讓 kubernetes 更加靈活的使用
除了上面之外,文章內還有許多其他的想法,但是內容都滿長的,如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/
k8s pod 數量 在 矽谷牛的耕田筆記 Facebook 的精選貼文
今天這篇文章作者跟大家分享一些如何加強 Kubernetes 服務穩定的方式,這篇文章這邊做個簡單摘要一下
發生問題:
作者的 k8s 是基於 Google Kubernetes Service (GKE)的叢集,運作過程中有時候會發現部分節點當掉,最後導致部分的服務不能正確使用。這邊作者團隊從兩個角度出發去改善
1. 研究為什麼節點會一直當掉,與 Google Supporte Team 來回信件最後有找到問題點
2. 強化 Kubernetes 服務的韌性,就算有部分節點壞掉也要讓服務能夠繼續運行
,本文主要的一些觀點也都是基於這邊發展
強化方式
1. 修正 Deployment 的數量,並且加上 Anti-Affinity,讓這些 Deployment 的副本能夠散落到不同的節點上,避免所有 Pod 都塞到同個節點,最後該節點出問題導致 Pod 全部出問題。
2. 所有需要被 Service 存取的服務都加上 Readess Probe 來確保這些服務都準備好後才會收到服務,避免一些請求被送過來確又不能正確處理
3. 加入 Pre-Stop 的使用,再裡面透過 sleep 10的方式,讓 Pod 要被刪除能夠將手上的封包請求給處理完畢
(請看註解補充)
註: 我個人認為第三點其實不太需要,比較漂亮的作法應該是實作 Singal Handler 去處理 SIGTERM 的訊號,收到此訊號後就不要再接受任何 Request 並且把剩下的工作處理完畢,當然如果這部份處理的時間過長,超過預設的 GracePeriod (30sec),就會被 SIGKILL 給強制刪除。
要解決這個問題可能就要從應用程式下手去看如何改善,或是透過修改 API server 來增加 GracePeroid 的數值
可以點選下方連結來瞭解更多全文,內容不長
https://medium.com/kudos-engineering/increasing-resilience-in-kubernetes-b6ddc9fecf80
k8s pod 數量 在 kubernetes常用运维命令或脚本.md 的推薦與評價
patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 更新容器的镜像 ... 判断deployment的Pod数量是否为奇数个. kubectl -n prd-php get deploy|awk 'NR ... ... <看更多>
k8s pod 數量 在 Kubernetes (五) - 實現Pod 的AutoScaling - Tienyu Note 的推薦與評價
image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources ... 這時再回來看Deployment 的運行狀況,可以發現Pod 數量也已經降回來了。 ... <看更多>
k8s pod 數量 在 [Kubernetes] 分配& 管理container 所使用到的計算資源 的推薦與評價
由於帶有ephemeral-storage limit,因此k8s 就會持續監控pod 中的 ... 一旦新增了extended resource,kubelet 就會根據pod 已經所消耗的數量,定期匯報 ... ... <看更多>