K3s资源分析
本节介绍了为确定 K3s 的最低资源需求，而进行的测试结果。
结果概述如下：
| 组件 | 处理器 | 最小 CPU | Kine/SQLite 的最小内存 | 嵌入式 ETCD 的最小内存 |
|---|---|---|---|---|
| 具有工作负载的 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 |
资源测试的范围#
资源测试的目的是为了解决以下问题：
- 在单节点集群上，确定运行整个 K3s server 堆栈所应预留的 CPU、内存和 IOPs 的合法最小值，假设真正的工作负载将部署在集群上。
- 在 agent（worker）节点上，确定应该为 Kubernetes 和 K3s 控制平面组件（kubelet 和 k3s agent）预留的 CPU、内存和 IOPs 的合法最小值。
基准测试包含的组件#
测试的组件有：
- 已启用所有打包组件的 K3s 1.19.2
- Prometheus + Grafana 监控堆栈
- Kubernetes PHP Guestbook 应用示例
这些是一个稳定系统的基准数据，只使用 K3s 打包的组件（Traefik Ingress，Klipper lb，local-path 存储），运行一个标准的监控栈（Prometheus 和 Grafana）和 Guestbook 示例应用程序。
包括 IOPS 在内的资源仅适用于 Kubernetes 数据存储和控制平面，不包括系统级管理 agent 或日志记录、容器镜像管理或任何特定工作负载要求的开销。
方法#
使用独立的 Prometheus v2.21.0 实例，通过 apt 安装的prometheus-node-exporter来收集主机 CPU、内存和磁盘 IO 统计数据。
systemd-cgtop用于抽查 systemd cgroup 级别的 CPU 和内存利用率。system.slice/k3s.service跟踪 K3s 和 containerd 的资源利用率情况，而单个 pod 则在kubepods层次结构下。
使用集成到 server 和 agent 进程中的 kubelet exporter，从 process_resident_memory_bytes和 go_memstats_alloc_bytes 指标中收集了额外的详细 K3s 内存利用率数据。
环境#
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
基准资源需求#
本节捕获了确定 K3s agent、带工作负载的 K3s server 和带一个 agent 的 K3s server 的最低资源需求的测试结果。
具有工作负载的 K3s server#
这些是对单节点集群的要求，其中 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 和内存的要求是：
| 测试数据存储 | 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 节点和一个 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 和内存的要求是：
| 测试数据存储 | 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 的内存。
分析#
本节介绍了对 K3s server 和 agent 利用率产生最大影响的因素，以及如何保护集群数据存储免受 agent 和工作负载的干扰。
影响资源利用率的因素#
K3s server 的利用率数据主要是由支持 Kubernetes 数据存储（kine 或 etcd）、API Server、Controller-Manager 和 Scheduler 控制，以及实现系统状态变化所需的任何管理任务所驱动。给 Kubernetes 控制平面带来额外负载的操作，如创建/修改/删除资源，将导致暂时的利用率上升。使用大量使用 Kubernetes 数据存储的 operators 或应用程序（如 Rancher 或其他 operators 类型的应用程序）将增加 server 的资源需求。通过添加额外的节点或创建许多集群资源来扩展集群，将增加 server 的资源需求。
K3s agent 的利用率数据主要是由支持容器生命周期管理控制驱动的。涉及管理镜像、提供存储或创建/销毁容器的操作将导致利用率的暂时上升。拉取镜像通常会影响 CPU 和 IO，因为它们涉及将镜像内容解压到磁盘。如果可能的话，工作负载存储(pod 临时存储和卷)应该与 agent 组件(/var/lib/rancher/k3s/agent)隔离，以确保不会出现资源冲突。
防止 agent 和工作负载干扰集群数据存储#
在 server 节点运行工作负载 pod 时，应确保 agent 和工作负载 IOPS 不干扰数据存储。
最好的办法是将 server 组件（/var/lib/rancher/k3s/server）与 agent 组件（/var/lib/rancher/k3s/agent）放在不同的存储介质上，后者包括 containerd 镜像存储。
工作负载存储（pod 临时存储和卷）也应该与数据存储隔离。
如果不能满足数据存储的吞吐量和延迟要求，可能会导致控制平面的延迟响应或控制平面无法维持系统状态。