本文由 網易雲 發佈。
概述
隨着容器技術的發展，容器服務已經成爲行業主流，然而想要在生產環境中成功部署和操做容器，關鍵仍是容器編排技術。市場上有各類各樣的容器編排工具，如Docker原生的Swarm、Mesos、Kubernetes等，其中Google開發的Kubernetes由於業界各大巨頭的加入和開源社區的全力支撐，成爲了容器編排的首選。node
簡單來說，Kubernetes是容器集羣管理系統，爲容器化的應用提供資源調度、部署運行、滾動升級、擴容縮容等功能。容器集羣管理給業務帶來了便利，可是隨着業務的不斷增加，應用數量可能會發生爆發式的增加。那在這種狀況下，Kubernetes可否快速地完成擴容、擴容到大規模時Kubernetes管理能力是否穩定成了挑戰。api
所以，結合近期對社區Kubernetes性能測試的調研和咱們平時進行的kubernetes性能測試實踐，和你們探討下Kubernetes性能測試的一些要點，不足之處還望你們多多指正！緩存
測試目的
如上Kubernetes架構圖所示，不管外部客戶端，仍是Kubernetes集羣內部組件，其通訊都須要通過Kubernetes的apiserver，API的響應性決定着集羣性能的好壞。安全
其次，對於外部客戶而言，他只關注建立容器服務所用的時間，所以，pod的啓動時間也是影響集羣性能的另一個因素。服務器
目前，業內廣泛採用的性能標準是：網絡
- API響應性：99%的API調用響應時間小於1s。
- Pod啓動時間：99%的pods（已經拉取好鏡像）啓動時間在5s之內。
「pod啓動時間」包括了ReplicationController的建立，RC依次建立pod，調度器調度pod，Kubernetes爲pod設置網絡，啓動容器，等待容器成功響應健康檢查，並最終等待容器將其狀態上報回API服務器，最後API服務器將pod的狀態報告給正在監聽中的客戶端。架構
除此以外，網絡吞吐量、鏡像大小（須要拉取）都會影響Kubernetes的總體性能。併發
測試要點
1、社區測試Kubernetes性能的關鍵點異步
- 當集羣資源使用率是X%（50%、90% 、99%等不一樣規模下）的時候，建立新的pod所需的時間（這種場景須要提早鋪底，而後在鋪底基礎上用不一樣的併發梯度建立pod，測試pod建立耗時，評估集羣性能）。在測試kubernetes新版本時，通常是以老版本穩定水位（node、pod等）鋪底，而後梯度增長進行測試。
- 當集羣使用率高於90%時，容器啓動時延的增大（系統會經歷一個異常的減速）還有etcd測試的線性性質和「模型創建」的因素。調優方法是：調研etcd新版本是否有解決該問題。
- 測試的過程當中要找出集羣的一個最高點，低於和高於這個閾值點，集羣性能都不是最優的。
- 組件負載會消耗master節點的資源，資源消耗所產生的不穩定性和性能問題，會致使集羣不可用。因此，在測試過程當中要時刻關注資源狀況。
- 客戶端建立資源對象的格式 —— API服務對編碼和解碼JSON對象也須要花費大量的時間 —— 這也能夠做爲一個優化點。
2、網易雲容器服務Kubernetes集羣性能測試關鍵點總結工具
集羣總體
- 不一樣的集羣使用水位線（0%，50%， 90%）上，pod/deployment(rs 等資源)建立、擴縮容等核心操做的性能。能夠經過預先建立出一批dp（副本數默認設置爲3）來填充集羣，達到預期的水位，即鋪底。
- 不一樣水位對系統性能的影響——安全水位，極限水位
- 容器有無掛載數據盤對容器建立性能的影響。例如，掛載數據盤增長了kubelet掛載磁盤的耗時，會增長pod的啓動時長。
測試kubernetes集羣的性能時，重點關注在不一樣水位、不一樣併發數下，長時間執行壓力測試時，系統的穩定性，包括：
- 系統性能表現，在較長時間範圍內的變化趨勢
- 系統資源使用狀況，在較長時間範圍內的變化趨勢
- 各個服務組件的TPS、響應時間、錯誤率
- 內部模塊間訪問次數、耗時、錯誤率等內部性能數據
- 各個模塊資源使用狀況
- 各個服務端組件長時間運行時，是否出現進程意外退出、重啓等狀況
- 服務端日誌是否有未知錯誤
- 系統日誌是否報錯
apiserver
- 關注api的響應時間。數據寫到etcd便可，而後根據狀況關注異步操做是否真正執行完成。
- 關注apiserver緩存的存儲設備對性能的影響。例如，master端節點的磁盤io。
- 流控對系統、系統性能的影響。
- apiserver 日誌中的錯誤響應碼。
- apiserver 重啓恢復的時間。須要考慮該時間用戶是否可接受，重啓後請求或者資源使用是否有異常。
- 關注apiserver在壓力測試狀況下，響應時間和資源使用狀況。
scheduler
- 壓測scheduler處理能力
- 併發建立大量pod，測試各個pod被調度器調度的耗時（從Pod建立到其被bind到host）
- 不斷加大新建的pod數量來增長調度器的負載
- 關注不一樣pod數量級下，調度器的平均耗時、最大時間、最大QPS（吞吐量）
2. scheduler 重啓恢復的時間（從重啓開始到重啓後系統恢復穩定）。須要考慮該時間用戶是否可接受，重啓後請求或者資源使用是否有異常。
3. 關注scheduler日誌中的錯誤信息。
controller
- 壓測 deployment controller處理能力
- 併發建立大量rc（1.3 之後是deployment，單副本），測試各個deployment被空感知並建立對應rs的耗時
- 觀察rs controller建立對應pod的耗時
- 擴容、縮容（縮容到0副本）的耗時
- 不斷加大新建deployment的數，測試在不一樣deployment數量級下，控制器處理deployment的平均耗時、最大時間、最大QPS（吞吐量）和控制器負載等狀況
2. controller 重啓恢復的時間（從重啓開始到重啓後系統恢復穩定）。須要考慮該時間用戶是否可接受，重啓後請求或者資源使用是否有異常。
3. 關注controller日誌中的錯誤信息。
kubelet
- node心跳對系統性能的影響。
- kubelet重啓恢復的時間（從重啓開始到重啓後系統恢復穩定）。須要考慮該時間用戶是否可接受，重啓後請求或者資源使用是否有異常。
- 關注kubelet日誌中的錯誤信息。
etcd
- 關注etcd 的寫入性能
- 寫最大併發數
- 寫入性能瓶頸，這個主要是按期持久化snapshot操做的性能
2. etcd 的存儲設備對性能的影響。例如，寫etcd的io。
3. watcher hub 數對kubernetes系統性能的影響。
做者：張文娟，網易測試工程師
瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/