K3s 資源分析
K3s資源分析
本節(jié)介紹了為確定 K3s 的最低資源需求，而進行的測試結(jié)果。
結(jié)果概述如下：
| 組件 | 處理器 | 最小 CPU | Kine/SQLite 的最小內(nèi)存 | 嵌入式 ETCD 的最小內(nèi)存 |
|---|---|---|---|---|
| 具有工作負載的 K3s server | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz | 10% of a core | 768 M | 896 M |
| 具有單個 agent 的 K3s 集群 | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz | 10% of a core | 512 M | 768 M |
| K3s agent | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz | 5% of a core | 256 M | 256 M |
| 具有工作負載的 K3s server | Pi4B BCM2711, 1.50 GHz | 20% of a core | 768 M | 896 M |
| 具有單個 agent 的 K3s 集群 | Pi4B BCM2711, 1.50 GHz | 20% of a core | 512 M | 768 M |
| K3s agent | Pi4B BCM2711, 1.50 GHz | 10% of a core | 256 M | 256 M |
資源測試的范圍
資源測試的目的是為了解決以下問題：
- 在單節(jié)點集群上，確定運行整個 K3s server 堆棧所應(yīng)預(yù)留的 CPU、內(nèi)存和 IOPs 的合法最小值，假設(shè)真正的工作負載將部署在集群上。
- 在 agent（worker）節(jié)點上，確定應(yīng)該為 Kubernetes 和 K3s 控制平面組件（kubelet 和 k3s agent）預(yù)留的 CPU、內(nèi)存和 IOPs 的合法最小值。
基準測試包含的組件
測試的組件有：
- 已啟用所有打包組件的 K3s 1.19.2
- Prometheus + Grafana 監(jiān)控堆棧
- Kubernetes PHP Guestbook 應(yīng)用示例
這些是一個穩(wěn)定系統(tǒng)的基準數(shù)據(jù)，只使用 K3s 打包的組件（Traefik Ingress，Klipper lb，local-path 存儲），運行一個標準的監(jiān)控棧（Prometheus 和 Grafana）和 Guestbook 示例應(yīng)用程序。
包括 IOPS 在內(nèi)的資源僅適用于 Kubernetes 數(shù)據(jù)存儲和控制平面，不包括系統(tǒng)級管理 agent 或日志記錄、容器鏡像管理或任何特定工作負載要求的開銷。
方法
使用獨立的 Prometheus v2.21.0 實例，通過 apt 安裝的?prometheus-node-exporter?來收集主機 CPU、內(nèi)存和磁盤 IO 統(tǒng)計數(shù)據(jù)。
?systemd-cgtop?用于抽查 systemd cgroup 級別的 CPU 和內(nèi)存利用率。?system.slice/k3s.service?跟蹤 K3s 和 containerd 的資源利用率情況，而單個 pod 則在?kubepods?層次結(jié)構(gòu)下。
使用集成到 server 和 agent 進程中的 kubelet exporter，從 ?process_resident_memory_bytes?和 ?go_memstats_alloc_bytes ?指標中收集了額外的詳細 K3s 內(nèi)存利用率數(shù)據(jù)。
環(huán)境
OS: Ubuntu 20.04 x86_64, aarch64
硬件:
- AWS c5d.xlarge - 4 core, 8 GB RAM, NVME SSD
- Raspberry Pi 4 Model B - 4 core, 8 GB RAM, Class 10 SDHC
基準資源需求
本節(jié)捕獲了確定 K3s agent、帶工作負載的 K3s server 和帶一個 agent 的 K3s server 的最低資源需求的測試結(jié)果。
具有工作負載的 K3s server
這些是對單節(jié)點集群的要求，其中 K3s server 與工作負載共享資源。
對 CPU 的要求是：
| 所需資源 | 測試處理器 |
|---|---|
| 10% of a core | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz |
| 20% of a core | Low-power processor such as Pi4B BCM2711, 1.50 GHz |
IOPS 和內(nèi)存的要求是：
| 測試數(shù)據(jù)存儲 | IOPS | KiB/sec | 延時 | RAM |
|---|---|---|---|---|
| Kine/SQLite | 10 | 500 | < 10 ms | 768 M |
| Embedded etcd | 50 | 250 | < 5 ms | 896 M |
具有單個 agent 的 K3s 集群
這些是 K3s 集群的基本要求，它有一個 K3s server 節(jié)點和一個 K3s agent，但沒有工作負載。
對 CPU 的要求是：
| 所需資源 | 測試處理器 |
|---|---|
| 10% of a core | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz |
| 20% of a core | Pi4B BCM2711, 1.50 GHz |
IOPS 和內(nèi)存的要求是：
| 測試數(shù)據(jù)存儲 | IOPS | KiB/sec | 延時 | RAM |
|---|---|---|---|---|
| Kine/SQLite | 10 | 500 | < 10 ms | 512 M |
| Embedded etcd | 50 | 250 | < 5 ms | 768 M |
K3s Agent
對 CPU 的要求是：
| 所需資源 | 測試處理器 |
|---|---|
| 5% of a core | Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz |
| 10% of a core | Pi4B BCM2711, 1.50 GHz |
需要 256M 的內(nèi)存。
分析
本節(jié)介紹了對 K3s server 和 agent 利用率產(chǎn)生最大影響的因素，以及如何保護集群數(shù)據(jù)存儲免受 agent 和工作負載的干擾。
影響資源利用率的因素
K3s server 的利用率數(shù)據(jù)主要是由支持 Kubernetes 數(shù)據(jù)存儲（kine 或 etcd）、API Server、Controller-Manager 和 Scheduler 控制，以及實現(xiàn)系統(tǒng)狀態(tài)變化所需的任何管理任務(wù)所驅(qū)動。給 Kubernetes 控制平面帶來額外負載的操作，如創(chuàng)建/修改/刪除資源，將導致暫時的利用率上升。使用大量使用 Kubernetes 數(shù)據(jù)存儲的 operators 或應(yīng)用程序（如 Rancher 或其他 operators 類型的應(yīng)用程序）將增加 server 的資源需求。通過添加額外的節(jié)點或創(chuàng)建許多集群資源來擴展集群，將增加 server 的資源需求。
K3s agent 的利用率數(shù)據(jù)主要是由支持容器生命周期管理控制驅(qū)動的。涉及管理鏡像、提供存儲或創(chuàng)建/銷毀容器的操作將導致利用率的暫時上升。拉取鏡像通常會影響 CPU 和 IO，因為它們涉及將鏡像內(nèi)容解壓到磁盤。如果可能的話，工作負載存儲(pod 臨時存儲和卷)應(yīng)該與 agent 組件(/var/lib/rancher/k3s/agent)隔離，以確保不會出現(xiàn)資源沖突。
防止 agent 和工作負載干擾集群數(shù)據(jù)存儲
在 server 節(jié)點運行工作負載 pod 時，應(yīng)確保 agent 和工作負載 IOPS 不干擾數(shù)據(jù)存儲。
最好的辦法是將 server 組件（/var/lib/rancher/k3s/server）與 agent 組件（/var/lib/rancher/k3s/agent）放在不同的存儲介質(zhì)上，后者包括 containerd 鏡像存儲。
工作負載存儲（pod 臨時存儲和卷）也應(yīng)該與數(shù)據(jù)存儲隔離。
如果不能滿足數(shù)據(jù)存儲的吞吐量和延遲要求，可能會導致控制平面的延遲響應(yīng)或控制平面無法維持系統(tǒng)狀態(tài)。
更多建議：