リソースプロファイリング

リソーステストは以下の問題点に対処することを目的としていました：

テストされたコンポーネントは次のとおりです：

これらは、標準の監視スタック（PrometheusおよびGrafana）とGuestbookのサンプルアプリを実行するK3sパッケージ済みコンポーネント（Traefik Ingress、Klipper lb、local-pathストレージ）のみを使用した安定したシステムのベースライン数値です。

リソース数値（IOPSを含む）はKubernetesデータストアおよびコントロールプレーンのみに関するものであり、システムレベルの管理エージェントやログ記録、コンテナイメージ管理、または特定のワークロード要件のオーバーヘッドは含まれていません。

Prometheus v2.43.0のスタンドアロンインスタンスを使用して、apt経由でインストールされた`prometheus-node-exporter`を使用してホストのCPU、メモリ、およびディスクIO統計を収集しました。

`systemd-cgtop`を使用して、systemd cgroupレベルのCPUおよびメモリ使用率をスポットチェックしました。`system.slice/k3s.service`は、K3sとcontainerdの両方のリソース使用状況を追跡し、個々のポッドは`kubepods`階層に属しています。

追加の詳細なK3sメモリ使用状況データは、サーバーおよびエージェントプロセス用の統合メトリクスサーバーを使用して`kubectl top node`から収集されました。

使用状況の数値は、記載されたワークロードを実行しているノードの定常状態運転における95パーセンタイルの読み取り値に基づいています。

このセクションでは、基本的なK3s運用のための最小リソース要件を決定するためのテスト結果を記録します。

K3sサーバの利用状況は、主にKubernetesデータストア（kineまたはetcd）、APIサーバ、コントローラーマネージャ、スケジューラ制御ループのサポート、およびシステムの状態に変更を加えるために必要な管理タスクによって推進されます。リソースの作成/変更/削除など、Kubernetes制御プレーンに追加の負荷をかける操作は、一時的な利用状況のスパイクを引き起こします。Kubernetesデータストア（Rancherや他のオペレータータイプのアプリケーションなど）を広範に使用するオペレーターやアプリを使用すると、サーバーのリソース要件が増加します。追加のノードを追加したり、多くのクラスターリソースを作成したりすることでクラスターをスケールアップすると、サーバーのリソース要件が増加します。

K3sエージェントの利用状況は、主にコンテナライフサイクル管理制御ループのサポートによって推進されています。イメージの管理、ストレージのプロビジョニング、またはコンテナの作成/削除を含む操作は、一時的な利用状況の急増を引き起こします。特にイメージのプルは、イメージコンテンツをディスクに解凍するため、通常はCPUとIOに強く依存します。可能であれば、ワークロードストレージ（ポッドの一時ストレージとボリューム）は、エージェントコンポーネント（/var/lib/rancher/k3s/agent）から隔離され、リソースの競合がないことを確認する必要があります。

サーバーがワークロードポッドもホストしている環境で実行する場合、エージェントとワークロードのIOPSがデータストアに干渉しないように注意する必要があります。

これは、サーバーコンポーネント（/var/lib/rancher/k3s/server）をエージェントコンポーネント（/var/lib/rancher/k3s/agent、containerdイメージストアを含む）とは異なるストレージメディアに配置することで最も効果的に達成できます。

ワークロードストレージ（ポッドの一時ストレージとボリューム）もデータストアから隔離されるべきです。

データストアのスループットとレイテンシ要件を満たさない場合、制御プレーンからの応答が遅れる可能性があり、または制御プレーンがシステム状態を維持できなくなるエラーが発生する可能性があります。

このデータは特定のテスト条件下で取得されました。環境やワークロードによって異なる場合があります。以下の手順は、これを取得するために実行されたテストの概要を示しています。これはv1.31.0+k3s1で最後に実行されました。すべてのマシンは、標準の20 GiB gp3ボリュームでAWSにプロビジョニングされました。テストは以下の手順で実施されました：