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

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

テストされたコンポーネントは以下の通りです：

これらは、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パーセンタイルの読み取り値に基づいています。

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

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イメージストアが含まれます。

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

データストアのスループットおよびレイテンシ要件を満たさない場合、コントロールプレーンの応答が遅延したり、コントロールプレーンがシステム状態を維持できなくなったりする可能性があります。