リソースプロファイリング
このセクションでは、K3sの最小リソース要件を決定するためのテスト結果を記録します。
Minimum Resource Requirements for 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モニタリングスタック
これらは、K3sパッケージコンポーネント(Traefik Ingress、Klipper lb、local-path storage)のみを使用し、標準のモニタリングスタック(PrometheusとGrafana)およびGuestbook例アプリを実行する安定したシステムのベースライン数値です。
IOPSを含むリソース数値はKubernetesデータストアおよびコントロールプレーンのみのものであり、システムレベルの管理エージェントやログ、コンテナイメージ管理、またはワークロード固有の要件のオーバーヘッドは含まれていません。
方法論
Prometheus v2.43.0のスタンドアロンインスタンスを使用して、prometheus-node-exporter
をapt経由でインストールし、ホストのCPU、メモリ、およびディスクIO統計を収集しました。
systemd-cgtop
を使用して、systemd cgroupレベルのCPUおよびメモリ使用量をスポットチェックしました。system.slice/k3s.service
はK3sおよびcontainerdのリソース使用量を追跡し、個々のポッドはkubepods
階層下にあります。
追加の詳細なK3sメモリ使用量データは、サーバーおよびエージェントプロセスのために統合されたメトリクスサーバーを使用してkubectl top node
から収集しました。
使用量数値は、記述されたワークロードを実行しているノードの定常状態操作からの95パーセンタイルの読み取り値に基づいています。
環境
アーキテクチャ | OS | システム | CPU | RAM | ディスク |
---|---|---|---|---|---|
x86_64 |
Ubuntu 22.04 |
AWS c6id.xlarge |
Intel Xeon Platinum 8375C CPU, 4 Core 2.90 GHz |
8 GB |
NVME SSD |
aarch64 |
Raspberry Pi OS 11 |
Raspberry Pi 4 Model B |
BCM2711, 4 Core 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 ms |
組み込みetcd |
50 |
250 |
< 5 ms |
分析主要なリソース利用ドライバー
K3sサーバーの利用数値は主に、Kubernetesデータストア(kineまたはetcd)、APIサーバー、コントローラーマネージャー、およびスケジューラーのコントロールループのサポートによって駆動されます。また、システムの状態を変更するために必要な管理タスクも含まれます。Kubernetesコントロールプレーンに追加の負荷をかける操作(リソースの作成/変更/削除など)は、一時的な利用のスパイクを引き起こします。Rancherや他のオペレータータイプのアプリケーションなど、Kubernetesデータストアを広範に使用するオペレーターやアプリを使用すると、サーバーのリソース要件が増加します。追加のノードを追加したり、多くのクラスターリソースを作成したりすることで、サーバーのリソース要件が増加します。
K3sエージェントの利用数値は主に、コンテナライフサイクル管理コントロールループのサポートによって駆動されます。イメージの管理、ストレージのプロビジョニング、コンテナの作成/破棄を含む操作は、一時的な利用のスパイクを引き起こします。特にイメージのプルは、イメージコンテンツをディスクに解凍するため、通常は高いCPUおよびIO負荷がかかります。可能であれば、ワークロードストレージ(ポッドの一時ストレージおよびボリューム)は、エージェントコンポーネント(/var/lib/rancher/k3s/agent)から分離して、リソースの競合が発生しないようにするべきです。
エージェントとワークロードがクラスターのデータストアに干渉しないようにする方法
サーバーがワークロードポッドもホストしている環境で実行する場合、エージェントおよびワークロードのIOPSがデータストアに干渉しないように注意する必要があります。
これを最も効果的に達成する方法は、サーバーコンポーネント(/var/lib/rancher/k3s/server)をエージェントコンポーネント(/var/lib/rancher/k3s/agent)とは異なるストレージメディアに配置することです。エージェントコンポーネントにはcontainerdイメージストアが含まれます。
ワークロードストレージ(ポッドの一時ストレージおよびボリューム)もデータストアから分離するべきです。
データストアのスループットおよびレイテンシ要件を満たさない場合、コントロールプレーンの応答が遅延したり、コントロールプレーンがシステム状態を維持できなくなったりする可能性があります。
Server Sizing Requirements for K3s
Environment
-
All agents were t3.medium AWS ec2 instances.
-
A single agent was a c5.4xlarge instance. This hosted the grafana monitoring stack and prevented it from interfering with the control-plane resources.
-
-
The Server was a c5 AWS ec2 instance. As the number of agents increased, the server was upgraded to larger c5 instances.
Methodology
This data was retrieved under specific test conditions. It will vary depending upon environment and workloads. The steps below give an overview of the test that was run to retrieve this. It was last performed on v1.31.0+k3s1. All the machines were provisioned in AWS with standard 20 GiB gp3 volumes. The test was run with the following steps:
-
Monitor resources on grafana using prometheus data source.
-
Deploy workloads in such a way to simulate continuous cluster activity:
-
A basic workload that scales up and down continuously
-
A workload that is deleted and recreated in a loop
-
A constant workload that contains multiple other resources including CRDs.
-
-
Join agent nodes in batches of 50-100 at a time.
-
Stop adding agents when server CPU spikes above 90% utilization on agent joining, or if RAM was above 80% utilization.
Observations
-
When joining agents, server CPU saw spikes of ~20% over baseline.
-
Typically, the limiting factor was CPU, not RAM. For most of the tests, when the CPU hit 90% utilization, RAM utilization was around 60%.
A note on High Availability (HA)
At the end of each test, two additional servers were joined (forming a basic 3 node HA cluster) to observe what effect this had on the original server resources. The effect was:
-
A noticeable drop in CPU utilization, usually 30-50%.
-
RAM utilization remained the same.
While not tested, with CPU utilization as the limiting factor on a single server, it is expected that the number of agents that can be joined would increase by ~50% with a 3 node HA cluster.