Skip to main content

K3s资源分析

本节介绍了为确定 K3s 的最低资源需求,而进行的测试结果。

结果概述如下:

组件处理器最小 CPUKine/SQLite 的最小内存嵌入式 ETCD 的最小内存
具有工作负载的 K3s serverIntel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz10% of a core768 M896 M
具有单个 agent 的 K3s 集群Intel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz10% of a core512 M768 M
K3s agentIntel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz5% of a core256 M256 M
具有工作负载的 K3s serverPi4B BCM2711, 1.50 GHz20% of a core768 M896 M
具有单个 agent 的 K3s 集群Pi4B BCM2711, 1.50 GHz20% of a core512 M768 M
K3s agentPi4B BCM2711, 1.50 GHz10% of a core256 M256 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_bytesgo_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 coreIntel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz
20% of a coreLow-power processor such as Pi4B BCM2711, 1.50 GHz

IOPS 和内存的要求是:

测试数据存储IOPSKiB/sec延时RAM
Kine/SQLite10500< 10 ms768 M
Embedded etcd50250< 5 ms896 M

具有单个 agent 的 K3s 集群#

这些是 K3s 集群的基本要求,它有一个 K3s server 节点和一个 K3s agent,但没有工作负载。

对 CPU 的要求是:

所需资源测试处理器
10% of a coreIntel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz
20% of a corePi4B BCM2711, 1.50 GHz

IOPS 和内存的要求是:

测试数据存储IOPSKiB/sec延时RAM
Kine/SQLite10500< 10 ms512 M
Embedded etcd50250< 5 ms768 M

K3s Agent#

对 CPU 的要求是:

所需资源测试处理器
5% of a coreIntel(R) Xeon(R) Platinum 8124M CPU, 3.00 GHz
10% of a corePi4B 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 临时存储和卷)也应该与数据存储隔离。

如果不能满足数据存储的吞吐量和延迟要求,可能会导致控制平面的延迟响应或控制平面无法维持系统状态。

Last updated on by yzeng25