|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。 |
资源剖析
本节记录了确定 K3s 最低资源需求的测试结果。
K3s 的最低资源需求
结果总结如下：
| 组件 | 处理器 | 最小 CPU | 使用 Kine/SQLite 的最小 RAM | 使用嵌入式 etcd 的最小 RAM |
|---|---|---|---|---|
带有工作负载的 K3s 服务器 |
Intel 8375C CPU, 2.90 GHz |
6% 的内核 |
1596 M |
1606 M |
带有单个代理的 K3s 集群 |
Intel 8375C CPU, 2.90 GHz |
5% 的内核 |
1428 M |
1450 M |
K3s 代理 |
Intel 8375C CPU, 2.90 GHz |
3% 的内核 |
275 M |
275 M |
带有工作负载的 K3s 服务器 |
Pi4B BCM2711，1.50 GHz |
30% 的内核 |
1588 M |
1613 M |
带有单个代理的 K3s 集群 |
Pi4B BCM2711，1.50 GHz |
25% 的内核 |
1215 M |
1413 M |
K3s 代理 |
Pi4B BCM2711，1.50 GHz |
10% 的内核 |
268 M |
268 M |
资源测试范围
资源测试旨在解决以下问题：
-
在单节点集群上，确定应预留的合法最小 CPU、内存和 IOPs 以运行整个 K3s 堆栈服务器堆栈，假设集群上将部署真实工作负载。
-
在代理（工作）节点上，确定应预留的合法最小 CPU、内存和 IOPs 以支持 Kubernetes 和 K3s 控制平面组件（kubelet 和 k3s 代理）。
基准测量中包含的组件
测试的组件包括：
-
启用所有打包组件的 K3s v1.26.5
-
Prometheus + Grafana 监控堆栈
这些是仅使用 K3s 打包组件（Traefik Ingress、Klipper lb、local-path 存储）运行标准监控堆栈（Prometheus 和 Grafana）以及 Guestbook 示例 APP 的稳定系统的基准数据。
包括 IOPS 的资源数据仅适用于 Kubernetes 数据存储和控制平面，不包括系统级管理代理或日志记录、容器镜像管理或任何特定工作负载要求的开销。
方法
使用 prometheus-node-exporter 通过 apt 安装的 收集主机 CPU、内存和磁盘 IO 统计信息的独立 Prometheus v2.43.0 实例。
使用 systemd-cgtop 检查 systemd cgroup 级别的 CPU 和内存利用率。system.slice/k3s.service 跟踪 K3s 和 containerd 的资源利用率，而单个 pod 则位于 kubepods 层级下。
利用集成的 metrics-server，从 kubectl top node 收集了针对服务器和代理进程的额外详细 K3s 内存利用率数据。
利用率数据基于在运行所述工作负载的节点上进行的稳态操作的第95百分位数读数。
环境
| 架构 | OS | 系统 | CPU | RAM | 磁盘 |
|---|---|---|---|---|---|
x86_64 |
Ubuntu 22.04 |
AWS c6id.xlarge |
英特尔至强铂金8375C CPU，4核 2.90 GHz |
8 GB |
NVME SSD |
aarch64 |
Raspberry Pi OS 11 |
Raspberry Pi 4 Model B |
BCM2711，4核 1.50 GHz |
8 GB |
UHS-III SDXC |
基线资源要求
本节记录了确定基本K3s操作的最低资源要求的测试结果。
带有工作负载的 K3s 服务器
这些是单节点集群的要求，其中 K3s 服务器与 简单工作负载 共享资源。
CPU要求为：
| 系统 | CPU核心使用情况 |
|---|---|
英特尔8375C |
6% 的内核 |
Pi4B |
30% 的内核 |
内存要求为：
| 测试的数据存储 | 系统 | 内存 |
|---|---|---|
Kine/SQLite |
英特尔8375C |
1596 M |
Pi4B |
1588 M |
|
嵌入式etcd |
英特尔8375C |
1606 M |
Pi4B |
1613 M |
磁盘要求为：
| 测试的数据存储 | IOPS | KiB/sec | 延迟 |
|---|---|---|---|
Kine/SQLite |
10 |
500 |
< 10 ms |
嵌入式etcd |
50 |
250 |
< 5 ms |
主要资源利用驱动因素分析
K3s 服务器的利用率主要受 Kubernetes 数据存储（kine 或 etcd）、API 服务器、控制器管理器和调度程序控制循环的支持驱动，以及进行系统状态更改所需的任何管理任务。对 Kubernetes 控制平面施加额外负载的操作，例如创建/修改/删除资源，将导致利用率的暂时峰值。使用广泛利用 Kubernetes 数据存储的操作员或 APP（如 Rancher 或其他操作员类型的 APP）将增加服务器的资源要求。通过添加额外节点或创建许多集群资源来扩展集群将增加服务器的资源要求。
K3s 代理的利用率主要受容器生命周期管理控制循环的支持驱动。涉及管理镜像、配置存储或创建/销毁容器的操作将导致利用率的暂时峰值。特别是镜像拉取通常高度依赖 CPU 和 IO，因为它们涉及将镜像内容解压到磁盘。如果可能，工作负载存储（pod 瞬态存储和卷）应与代理组件（/var/lib/rancher/k3s/agent）隔离，以确保没有资源冲突。
K3s 的服务器规格要求
环境
-
所有代理都是 t3.medium 的 AWS EC2 实例。
-
单个代理是 c5.4xlarge 实例。这托管了 grafana 监控堆栈，并防止其干扰控制平面的资源。
-
-
服务器是 c5 的 AWS EC2 实例。随着代理数量的增加，服务器升级为更大的 c5 实例。
方法
这些数据是在特定测试条件下检索的。这将根据环境和工作负载而有所不同。以下步骤概述了为检索此数据而进行的测试。最后一次在 v1.31.0+k3s1 上执行。所有机器均在 AWS 中配置，使用标准的 20 GiB gp3 卷。测试按照以下步骤进行：
-
使用 prometheus 数据源在 grafana 上监控资源。
-
以模拟持续集群活动的方式部署工作负载：
-
一个基本的工作负载，持续地扩展和缩减
-
一个在循环中被删除和重新创建的工作负载
-
一个包含多个其他资源（包括 CRD）的恒定工作负载。
-
-
以每次 50-100 个的批次加入代理节点。
-
当服务器 CPU 在加入代理时的利用率超过 90% 或 RAM 利用率超过 80% 时，停止添加代理。