Kubernetes性能測試實踐

4 人贊了文章

本文由網易雲 發布

概述

隨著容器技術的發展，容器服務已經成為行業主流，然而想要在生產環境中成功部署和操作容器，關鍵還是容器編排技術。市場上有各種各樣的容器編排工具，如Docker原生的Swarm、Mesos、Kubernetes等，其中Google開發的Kubernetes因為業界各大巨頭的加入和開源社區的全力支撐，成為了容器編排的首選。

簡單來講，Kubernetes是容器集群管理系統，為容器化的應用提供資源調度、部署運行、滾動升級、擴容縮容等功能。容器集群管理給業務帶來了便利，但是隨著業務的不斷增長，應用數量可能會發生爆髮式的增長。那在這種情況下，Kubernetes能否快速地完成擴容、擴容到大規模時Kubernetes管理能力是否穩定成了挑戰。

因此，結合近期對社區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的整體性能。

測試要點

一、社區測試Kubernetes性能的關鍵點

1. 當集群資源使用率是X%（50%、90% 、99%等不同規模下）的時候，創建新的pod所需的時間（這種場景需要提前鋪底，然後在鋪底基礎上用不同的並發梯度創建pod，測試pod創建耗時，評估集群性能）。在測試kubernetes新版本時，一般是以老版本穩定水位（node、pod等）鋪底，然後梯度增加進行測試。
2. 當集群使用率高於90%時，容器啟動時延的增大（系統會經歷一個異常的減速）還有etcd測試的線性性質和「模型建立」的因素。調優方法是：調研etcd新版本是否有解決該問題。
3. 測試的過程中要找出集群的一個最高點，低於和高於這個閾值點，集群性能都不是最優的。
4. 組件負載會消耗master節點的資源，資源消耗所產生的不穩定性和性能問題，會導致集群不可用。所以，在測試過程中要時刻關注資源情況。
5. 客戶端創建資源對象的格式 —— API服務對編碼和解碼JSON對象也需要花費大量的時間 —— 這也可以作為一個優化點。

二、網易雲容器服務Kubernetes集群性能測試關鍵點總結

集群整體

1. 不同的集群使用水位線（0%，50%， 90%）上，pod/deployment(rs 等資源)創建、擴縮容等核心操作的性能。可以通過預先創建出一批dp（副本數默認設置為3）來填充集群，達到預期的水位，即鋪底。
2. 不同水位對系統性能的影響——安全水位，極限水位
3. 容器有無掛載數據盤對容器創建性能的影響。例如，掛載數據盤增加了kubelet掛載磁碟的耗時，會增加pod的啟動時長。

測試kubernetes集群的性能時，重點關注在不同水位、不同並發數下，長時間執行壓力測試時，系統的穩定性，包括：

• 系統性能表現，在較長時間範圍內的變化趨勢
• 系統資源使用情況，在較長時間範圍內的變化趨勢
• 各個服務組件的TPS、響應時間、錯誤率
• 內部模塊間訪問次數、耗時、錯誤率等內部性能數據
• 各個模塊資源使用情況
• 各個服務端組件長時間運行時，是否出現進程意外退出、重啟等情況
• 服務端日誌是否有未知錯誤
• 系統日誌是否報錯

apiserver

1. 關注api的響應時間。數據寫到etcd即可，然後根據情況關注非同步操作是否真正執行完成。
2. 關注apiserver緩存的存儲設備對性能的影響。例如，master端節點的磁碟io。
3. 流控對系統、系統性能的影響。
4. apiserver 日誌中的錯誤響應碼。
5. apiserver 重啟恢復的時間。需要考慮該時間用戶是否可接受，重啟後請求或者資源使用是否有異常。
6. 關注apiserver在壓力測試情況下，響應時間和資源使用情況。

scheduler

1. 壓測scheduler處理能力

• 並發創建大量pod，測試各個pod被調度器調度的耗時（從Pod創建到其被bind到host）
• 不斷加大新建的pod數量來增加調度器的負載
• 關注不同pod數量級下，調度器的平均耗時、最大時間、最大QPS（吞吐量）

2. scheduler 重啟恢復的時間（從重啟開始到重啟後系統恢復穩定）。需要考慮該時間用戶是否可接受，重啟後請求或者資源使用是否有異常。

3. 關注scheduler日誌中的錯誤信息。

controller

1. 壓測 deployment controller處理能力

• 並發創建大量rc（1.3 以後是deployment，單副本），測試各個deployment被空感知並創建對應rs的耗時
• 觀察rs controller創建對應pod的耗時
• 擴容、縮容（縮容到0副本）的耗時
• 不斷加大新建deployment的數，測試在不同deployment數量級下，控制器處理deployment的平均耗時、最大時間、最大QPS（吞吐量）和控制器負載等情況

2. controller 重啟恢復的時間（從重啟開始到重啟後系統恢復穩定）。需要考慮該時間用戶是否可接受，重啟後請求或者資源使用是否有異常。

3. 關注controller日誌中的錯誤信息。

kubelet

1. node心跳對系統性能的影響。
2. kubelet重啟恢復的時間（從重啟開始到重啟後系統恢復穩定）。需要考慮該時間用戶是否可接受，重啟後請求或者資源使用是否有異常。
3. 關注kubelet日誌中的錯誤信息。

etcd

1. 關注etcd 的寫入性能

• 寫最大並發數
• 寫入性能瓶頸，這個主要是定期持久化snapshot操作的性能

2. etcd 的存儲設備對性能的影響。例如，寫etcd的io。

3. watcher hub 數對kubernetes系統性能的影響。

作者：張文娟，網易測試工程師

網易雲計算基礎服務為您提供容器服務，歡迎點擊免費試用。

了解 網易雲 ：

網易雲官網：https://www.163yun.com/

新用戶大禮包：https://www.163yun.com/gift

網易雲社區：https://sq.163yun.com/