前言
本人2017年第一次接觸K8S. 中間斷斷續續學習K8S相關的內容.
但是最近一年,幾乎沒太有學習.
因爲之前學習了四五年, 一直以爲產品馬上要用
結果一直被澆冷水.
去年開始學乖了. 不這麼搞了
但是發現產品要開始用了..
這裏只能臨時抱佛腳. 猜測一下可能影響K8S上面應用性能的要點.
摘要
1. 物理層面的影響
2. 虛擬化層的影響(如果有)
3. OS層的影響(內核參數, 網絡參數等)
4. K8S部署模式的影響
5. K8S網絡組件,服務註冊發現(etcd壓力)的影響.
6. 應用配置的影響(limit request等)
7. POD數量的以及服務出口的影響.
8. 鏡像層數,大小,複雜度對拉取,啓動和運行性能的影響.
9. 容器運行的損耗.
10.K8S的監控,探針對性能的影響.
11.POD遷移,auto scale 等對性能波動的影響.
12.啓動腳本的影響(JVM內存參數優化等)
1. 物理層
1. 物理機器的價格
貴的服務器不一定好, 但是好的服務器一定貴.
2. 物理機器的CPU,主頻,核數.電源模式.
注意 最好是設置最高性能, 避免平衡模式導致性能下降.
3. 空調溫度
舉個例子. 溫度較高時,DDR內存的充電會從64ms充電完成,降低到32ms.
會導致充電頻率增大一倍,將低內存帶寬.
CPU溫度過高也會導致自主降頻保護.
4. 網絡設備.
網卡性能,雙工設置,網線材質,交換機配置,交換機壓力負責.機房機櫃距離.
5. 硬盤類型-raid卡性能.
影響鏡像拉取,有應用服務器的啓動速度.並且如果前端文件較多,會影響響應速度.
6. 機器CPU類型.是否信創. 內存參數等.
2. 虛擬化層的影響
1. 虛擬化大大降低了部署複雜度,提高了部署效率.
但是也會導致一定的性能開銷. 理論上會導致至少15%-25%的性能損失.
2. 虛擬化的超售情況.
虛擬化一般內存超售的比較少(除非是氣泡技術).
CPU可能會超售, 會出現擠佔的情況,影響性能.
3. 虛擬化的類型.
理論上類似於阿里的神龍,騰訊的黑石,是最佳的虛擬化(不完全)實現技術
ESXi的效率理論上比Openstack的KVM要優秀一些.
4. 虛擬化驅動.
不管是硬件和軟件驅動一定要最新.
最新可能有bug,但是舊的一般 性能都不好
3. OS層的影響
1. 內核版本
至少4.18, 太低的版本無法發揮高版本軟件的性能.
2. 內核參數
tcp 文件 進程樹 磁盤文件類型 落盤參數 是否開啓大頁等等.
3. 機器剩餘磁盤空間
影響IO.
4. 是否進行過優化, 是否關閉了不必要的服務.
4. K8S部署模式的影響
1. K8S的版本
不同版本可能有不同的性能表現
2. K8S的部署方式
是源碼部署, 二進制部署, 容器化部署,還是其他部署模式.
理論上經過最優秀編譯參數的源碼部署性能可能最好
但是技術要求最高.難度也最高.
越是簡單的部署,兼容性越高的產品.他越難發揮特定硬件上面的性能.
3. 特定的部署工具
不建議minikube 等方式用於生產.建議選用商業版.
4. K8S使用的容器平臺與操作系統內核是否最佳適配.
建議選用官方文檔裏面測試過最優秀的組合.
5. K8S網絡組件,服務註冊發現(etcd壓力)的影響.
1. 網絡組件
flannel calico cilium 不同網絡組件對網絡性能影響很大.
2. 服務註冊發現的性能
拆分SU的情況下可能用到Kube DNS等的組建, 會有一定的性能損耗.
3. service 去找pod時也需要使用pod - id轉換.可能也有開銷.
4. etcd等的壓力
etcd裏面存儲的內容很多,不僅有網絡等的配置(pod node ip設置.)
還影響產品的部署效率和k8s命令的查詢速度.
6. 應用配置的影響(limit request等)
1. 需要確認好node的配置.一遍進行pod的資源限制.
建議優化好pod的最低配置,避免影響性能.
2. Pod與node的affinity的影響.
不建議pod集中於某一些node. 一方面有爭用.
另外一方面不高可用.
3. pod的配置需要與產品進行驗證.
不建議私自修改參數. 尤其是內存和CPU的參數.
而且需要針對不同的應用類型進行定製話的修改.
比如前端應用可能需要更多的內存緩存, 更好的磁盤讀寫.
後端計算查詢彙總應用可能需要更多的CPU進行計算
7. POD數量的以及服務出口的影響.
1. 建議對產品的容量進行規劃. 定義好pod數量.
每個pod支撐的用戶數量是有限制的, 建議可以進行自動擴展等.
2. 應用出口ingress 面對 service 以及service面對 pod的黏性.
雖然黏性能夠降低部分雲原生的要求
但是建議還是使用黏性來降低必須要分佈式一致性的緩存要求.
3. proxy對服務出口轉發的性能的影響
ingress可能需要對所有的node進行轉發. 裏面的參數和配置也表重要.
8. 鏡像層數,大小,複雜度對拉取,啓動和運行性能的影響.
1. 鏡像儘量要精簡.
一方面是大小,一方面是層數.
太大了拉取和推送性能低.層數多了IO性能會收到影響.
2. 降低複雜度
建議鏡像內複用文件系統的部署模式.減少不必要的兼容性問題.
3. 進行啓動優化.
springboot複雜之後啓動速度太慢了 需要優化.
4. 鏡像存儲路徑的設置
建議要儘量大. 定期清理. IO要好,避免影響部署效率.
9. 容器運行的損耗.
1. 容器層需要關注有調優
避免容器啓動過多,調度出問題. 並且因爲路由表增多後導致路由性能下降.
2. 建議選擇最優的容器層的設置.
建議部署時確認版本, 確認參數(systemd,或者是一些部署參數等.)
3. 容器自己也有網絡棧, 建議選用最佳的網絡棧, 避免不必要的損耗.
10. K8S的監控,探針對性能的影響.
1. cAdviser 等組件的影響.
K8S會自動收集pod等的運行情況, 雖然不會影響POD自身的運行,但是會對整個服務器產生更多的壓力.
2. sideCar模式的影響.
istio等組件,以及安全設置可能對應影響產品的交互性.
3. 監控探針會產生多餘的非產品的流量, 如果產品併發量足夠多,建議能夠拆分不同的物理網卡進行承載.
區分開東西和南北流量.
11.POD遷移,auto scale 等對性能波動的影響.
1. POD遷移等
從容器承載應用開始一般就要求應用服務器是無狀態.
因爲再K8S看來容器都是朝生墓死的. 最開始K8S都是要求不開swap
可以做到fast failure 避免程序在半死不活狀態影響判斷.
但是這就導致了一個問題. pod可能會不聽的啓動遷移.
如果沒有預熱和預加載會導致前幾次響應超級緩慢. 需要優化.
2. 自動擴容等的影響.
與上面一個內容類似. 因爲可以自動或者是人工的擴容, 這一塊必須得進行相關的優化.
不然首次訪問可能存在問題
可能需要預熱和特定腳本進行拉起特定產品的緩存.
12. 啓動腳本的影響(JVM內存參數優化等)
1. JDK_1.8_191開始.java就可以識別自己是在鏡像內了.
但是建議針對不同的應用還是進行JVM內存參數的設置.
比如文檔系統高IO佔用的和流程高CPU佔用的使用相同的JVM參數肯定不合適.
建議需要有最佳時間, 進行比率設置.
2. JAVA版本的選擇.
不建議選用沒有驗證過的java版本跑生產. 建議使用成熟穩定測試過的版本.
3. 不同CPU的處理
華爲鯤鵬社區曾經發文稱,ARM的codecache的要求要比x86的codecache內存要大
因爲RISC的指令集在相同代碼編譯時會產生更大的code cache item.
同樣的產品, 對code cache 方法區緩存的要求會更大.
建議針對不同架構的CPU進行特定的參數設置.
