リソース
リソース要求
すべてのコンテナには、定義済みのリソース要求値が含まれています。デフォルトではリソース制限を設けていません。ノードに過剰なメモリ容量がない場合、メモリ制限を適用することも1つの選択肢ですが、メモリ(またはノード)を追加することが望ましいでしょう。(Kubernetesノードのいずれかがメモリ不足になることは避けたいものです。Linuxカーネルのメモリ不足マネージャが必要不可欠なKubeプロセスを終了させてしまう可能性があるためです)。
デフォルトのリクエスト値を考え出すために、アプリケーションを実行し、各サービスに対して様々なレベルの負荷を生成する方法を考え出します。サービスを監視し、最適なデフォルト値を決定します。
測定します:
-
アイドル負荷- デフォルトはこれらの値以下であるべきではありませんが、アイドルプロセスは有用ではないため、通常はこの値に基づいてデフォルトを設定することはありません。
-
Minimal Load(最小負荷) - 最も基本的な有用な作業量を行うために必要な値。通常、CPU の場合はこれをデフォルトとして使用しますが、メモリの要求にはカーネルがプロセスを刈り取るリスクが伴うため、メモリのデフォルトとして使用するのは避けます。
-
平均負荷- 何を平均とみなすかはインストールによって大きく異なります。(使用した負荷をリストアップします)。サービスにポッドオートスケーラーがある場合、通常はこれらに基づいてスケーリング目標値を設定しようとします。また、デフォルトのメモリ要求も設定します。
-
ストレスフルなタスク- サービスが実行すべき最もストレスフルなタスクの使用量を測定します。(負荷時は不要)。リソース制限を適用する場合は、この値と平均負荷の値より上に制限を設定してみてください。
-
高負荷- サービスのストレステストを考え、それに必要なリソース使用量を測定します。現在、デフォルトではこれらの値を使用していませんが、ユーザーは平均負荷/ストレスタスクとこの値の間のどこかにリソース制限を設定したいと思うでしょう。
GitLab シェル
負荷のテストには、nohup git clone <project> <random-path-name>
を呼び出す Bash ループを使い、ある程度の並行性を持たせました。今後のテストでは、持続的な並行負荷を含めるようにします。
-
アイドル値
- 0タスク、2ポッド
- CPU: 0
- メモリ
5M
- 0タスク、2ポッド
-
最小負荷
- タスク1個(空のクローン1個)、ポッド2個
- CPU: 0
- メモリ
5M
- タスク1個(空のクローン1個)、ポッド2個
-
平均負荷
- 同時クローン5台、ポッド2台
- cpu:
100m
- メモリ
5M
- cpu:
- 20同時クローン、2ポッド
- cpu:
80m
- メモリ
6M
- cpu:
- 同時クローン5台、ポッド2台
-
ストレスフルなタスク
- LinuxカーネルのSSHクローン(17MB/s)
- cpu:
280m
- メモリ
17M
- cpu:
- SSHでLinuxカーネルをプッシュ(2MB/秒)
- cpu:
140m
- メモリ
13M
- アップロード接続の速度は、私たちのテスト中に要因の可能性があります。
- cpu:
- LinuxカーネルのSSHクローン(17MB/s)
-
高負荷
- 100同時クローン、4ポッド
- cpu:
110m
- メモリ
7M
- cpu:
- 100同時クローン、4ポッド
-
デフォルトのリクエスト
- cpu: 0 (最小負荷から)
- メモリ:
6M
(平均負荷から) - ターゲットCPU平均:
100m
(平均負荷より)
-
推奨リミット
- CPU: >
300m
(ストレスタスクより大きい) - メモリ>
20M
(ストレスタスクより大きい)
- CPU: >
gitlab.gitlab-shell.resources.limits.memory
が低く設定されすぎている場合に起こる可能性のある現象の詳細については、トラブルシューティングのドキュメントを確認してください。
ウェブサービス
Webservice リソースは10k リファレンスアーキテクチャのテスト中に分析されました。注釈はWebservice リソースのドキュメントにあります。
Sidekiq
Sidekiqリソースは、10kリファレンスアーキテクチャでのテスト中に解析されました。注記は、Sidekiqリソースのドキュメントに記載されています。
KAS
ユーザーのニーズがもっとわかるまで、私たちはユーザーがKASを次のように使うことを期待しています。
-
アイドル値
- エージェント接続数 0、ポッド数 2
- cpu:
10m
- メモリ
55M
- cpu:
- エージェント接続数 0、ポッド数 2
-
最小負荷:
- 1エージェント接続、2ポッド
- cpu:
10m
- メモリ
55M
- cpu:
- 1エージェント接続、2ポッド
-
平均負荷: 1エージェントがクラスターに接続されています。
- 5エージェント接続、2ポッド
- cpu:
10m
- メモリ
65M
- cpu:
- 5エージェント接続、2ポッド
-
ストレスの多い課題:
- 20エージェント接続、2ポッド
- cpu:
30m
- メモリ
95M
- cpu:
- 20エージェント接続、2ポッド
-
重負荷:
- 50エージェント接続、2ポッド
- cpu:
40m
- メモリ
150M
- cpu:
- 50エージェント接続、2ポッド
-
超重負荷:
- 200エージェント接続、2ポッド
- cpu:
50m
- メモリ
315M
- cpu:
- 200エージェント接続、2ポッド
このChartで設定されているKASリソースのデフォルトは、50エージェントのシナリオを処理するのに十分なものです。もし、私たちがエクストラヘビーロード(Extra Heavy Load)と考えている負荷に到達する予定があるのであれば、デフォルトを微調整してスケールアップすることを検討すべきです。
-
デフォルト: 2ポッド、各ポッドに
- cpu:
100m
- メモリ
100M
- cpu:
これらの数値の算出方法については、イシューのディスカッションをご覧ください。