资源分析
本节记录了测试结果，以确定 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 |
资源测试范围
资源测试旨在解决以下问题陈述
- 在单节点集群上，确定为运行整个 K3s 栈服务器栈而应该预留的最小 CPU、内存和 IOPS 数量，假设将在集群上部署实际工作负载。
- 在代理（工作器）节点上，确定应该为 Kubernetes 和 K3s 控制平面组件（kubelet 和 k3s 代理）预留的最小 CPU、内存和 IOPS 数量。
基线测量中包含的组件
测试的组件是
- 启用了所有打包组件的 K3s v1.26.5
- Prometheus + Grafana 监控栈
- Kubernetes 示例 Nginx 部署
这些是使用 K3s 打包组件（Traefik Ingress、Klipper lb、本地路径存储）运行标准监控栈（Prometheus 和 Grafana）以及 Guestbook 示例应用程序的稳定系统的基线数据。
包括 IOPS 的资源数据仅适用于 Kubernetes 数据存储和控制平面，不包括系统级管理代理或日志记录、容器镜像管理或任何工作负载特定要求的开销。
方法
Prometheus v2.43.0 的独立实例用于通过 prometheus-node-exporter 收集主机 CPU、内存和磁盘 IO 统计信息，该统计信息通过 apt 安装。
systemd-cgtop 用于现场检查 systemd cgroup 级别的 CPU 和内存使用情况。system.slice/k3s.service 跟踪 K3s 和 containerd 的资源使用情况，而单个 pod 则位于 kubepods 层次结构下。
其他详细的 K3s 内存使用数据从 kubectl top node 收集，使用服务器和代理进程的集成指标服务器。
使用率数据基于运行描述的工作负载的节点上稳态运行的第 95 个百分位数读数。
环境
| 架构 | 操作系统 | 系统 | CPU | RAM | 磁盘 |
|---|---|---|---|---|---|
| x86_64 | Ubuntu 22.04 | AWS c6id.xlarge | Intel Xeon Platinum 8375C CPU，4 核 2.90 GHz | 8 GB | NVME SSD |
| aarch64 | 树莓派操作系统 11 | 树莓派 4 型 B | BCM2711，4 核 1.50 GHz | 8 GB | UHS-III SDXC |
基线资源需求
本节记录了测试结果，以确定基本 K3s 操作的最低资源需求。
带有工作负载的 K3s 服务器
这些是单节点集群的需求，其中 K3s 服务器与 简单工作负载 共享资源。
CPU 需求是
| 系统 | CPU 核心使用率 |
|---|---|
| Intel 8375C | 核心使用率 6% |
| Pi4B | 核心使用率 30% |
内存需求是
| 测试的数据存储 | 系统 | 内存 |
|---|---|---|
| Kine/SQLite | Intel 8375C | 1596 M |
| Pi4B | 1588 M | |
| 嵌入式 etcd | Intel 8375C | 1606 M |
| Pi4B | 1613 M |
磁盘需求是
| 测试的数据存储 | IOPS | KiB/秒 | 延迟 |
|---|---|---|---|
| Kine/SQLite | 10 | 500 | < 10 毫秒 |
| 嵌入式 etcd | 50 | 250 | < 5 毫秒 |
带有单个代理的 K3s 集群
这些是带有 K3s 服务器节点和 K3s 代理的 K3s 集群的基线需求，但没有工作负载。
K3s 服务器
CPU 需求是
| 系统 | CPU 核心使用率 |
|---|---|
| Intel 8375C | 核心使用率 5% |
| Pi4B | 核心使用率 25% |
内存需求是
| 测试的数据存储 | 系统 | 内存 |
|---|---|---|
| Kine/SQLite | Intel 8375C | 1428 M |
| Pi4B | 1215 M | |
| 嵌入式 etcd | Intel 8375C | 1450 M |
| Pi4B | 1413 M |
K3s 代理
需求是
| 系统 | CPU 核心使用率 | RAM |
|---|---|---|
| Intel 8375C | 核心使用率 3% | 275 M |
| Pi4B | 核心使用率 5% | 268 M |
主要资源利用驱动因素分析
K3s 服务器使用率数据主要由对 Kubernetes 数据存储（kine 或 etcd）、API 服务器、控制器管理器和调度程序控制循环的支持驱动，以及执行对系统状态更改的任何必要管理任务。对 Kubernetes 控制平面施加额外负载的操作（如创建/修改/删除资源）将导致使用率的暂时激增。使用广泛使用 Kubernetes 数据存储的运算符或应用程序（如 Rancher 或其他运算符类型应用程序）将增加服务器的资源需求。通过添加其他节点或创建许多集群资源来扩展集群将增加服务器的资源需求。
K3s 代理使用率数据主要由对容器生命周期管理控制循环的支持驱动。涉及管理镜像、配置存储或创建/销毁容器的操作将导致使用率的暂时激增。特别是镜像拉取通常高度依赖 CPU 和 IO，因为它们涉及将镜像内容解压缩到磁盘。如果可能，工作负载存储（pod 临时存储和卷）应与代理组件（/var/lib/rancher/k3s/agent）隔离，以确保没有资源冲突。
防止代理和工作负载干扰集群数据存储
在服务器也托管工作负载 pod 的环境中运行时，应注意确保代理和工作负载 IOPS 不干扰数据存储。
这可以通过将服务器组件（/var/lib/rancher/k3s/server）放置在与代理组件（/var/lib/rancher/k3s/agent）不同的存储介质上（其中包括 containerd 镜像存储）来最好地实现。
工作负载存储（pod 临时存储和卷）也应与数据存储隔离。
无法满足数据存储吞吐量和延迟要求可能会导致控制平面响应延迟和/或控制平面无法维护系统状态。
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% 时，停止添加代理。
观察结果
- 加入代理时，服务器 CPU 出现峰值约为基线的 20%。
- 通常，限制因素是 CPU，而不是 RAM。在大多数测试中，当 CPU 使用率达到 90% 时，RAM 使用率约为 60%。
关于高可用性 (HA) 的说明
在每个测试结束时，加入两个额外的服务器（形成一个基本的 3 节点 HA 集群），以观察这对原始服务器资源的影响。影响是
- CPU 使用率明显下降，通常为 30-50%。
- RAM 使用率保持不变。
虽然没有进行测试，但由于 CPU 使用率是单服务器的限制因素，预计在 3 节点 HA 集群中，可以加入的代理数量将增加约 50%。