4.11. OpenShift パイプラインのリソース消費の削減
マルチテナント環境でクラスターを使用する場合、各プロジェクトおよび Kubernetes オブジェクトの CPU、メモリー、およびストレージリソースの使用を制御する必要があります。これにより、1 つのアプリケーションがリソースを過剰に消費し、他のアプリケーションに影響を与えるのを防ぐことができます。
結果として作成される Pod に設定される最終的なリソース制限を定義するために、Red Hat OpenShift Pipelines は、それらが実行されるプロジェクトのリソースクォータの制限および制限範囲を使用します。
プロジェクトのリソース消費を制限するには、以下を実行できます。
- リソースクォータを設定し、管理 して、リソースの総消費量を制限します。
- 制限範囲を使用し、リソース消費を制限 します。この対象は、Pod、イメージ、イメージストリームおよび永続ボリューム要求 (PVC) などの特定のオブジェクトのリソース消費です。
4.11.1. パイプラインでのリソース消費について
各タスクは、Task リソースの steps フィールドで定義された、特定の順序で実行される多数の必須ステップで設定されます。各タスクは Pod として実行され、各ステップは同じ Pod 内のコンテナーとして実行されます。
ステップは一度に 1 つずつ実行されます。タスクを実行する Pod は、タスク内の 1 つのコンテナーイメージ (ステップ) を一度に実行するのに十分なリソースのみを要求するため、タスク内のすべてのステップのリソースは保存されません。
steps 仕様の Resources フィールドは、リソース消費の制限を指定します。デフォルトで、CPU、メモリー、および一時ストレージのリソース要求は、BestEffort (ゼロ) 値またはそのプロジェクトの制限範囲で設定される最小値に設定されます。
ステップのリソース要求および制限の設定例
spec:
steps:
- name: <step_name>
resources:
requests:
memory: 2Gi
cpu: 600m
limits:
memory: 4Gi
cpu: 900m
LimitRange パラメーターおよびコンテナーリソース要求の最小値がパイプラインおよびタスクが実行されるプロジェクトに指定される場合、Red Hat OpenShift Pipelines はプロジェクトのすべての LimitRange 値を確認し、ゼロではなく最小値を使用します。
プロジェクトレベルでの制限範囲パラメーターの設定例
apiVersion: v1
kind: LimitRange
metadata:
name: <limit_container_resource>
spec:
limits:
- max:
cpu: "600m"
memory: "2Gi"
min:
cpu: "200m"
memory: "100Mi"
default:
cpu: "500m"
memory: "800Mi"
defaultRequest:
cpu: "100m"
memory: "100Mi"
type: Container
...
4.11.2. パイプラインでの追加のリソース消費を軽減する
Pod 内のコンテナーにリソース制限を設定する場合、OpenShift Container Platform はすべてのコンテナーが同時に実行される際に要求されるリソース制限を合計します。
呼び出されるタスクで一度に 1 つのステップを実行するために必要なリソースの最小量を消費するために、Red Hat OpenShift Pipelines は、最も多くのリソースを必要とするステップで指定される CPU、メモリー、および一時ストレージの最大値を要求します。これにより、すべてのステップのリソース要件が満たされます。最大値以外の要求はゼロに設定されます。
ただしこの動作により、リソースの使用率が必要以上に高くなる可能性があります。リソースクォータを使用する場合、これにより Pod がスケジュールできなくなる可能性があります。
たとえば、スクリプトを使用する 2 つのステップを含むタスクと、リソース制限および要求を定義しないタスクについて考えてみましょう。作成される Pod には 2 つの init コンテナー (エントリーポイントコピー用に 1 つとスクリプトの作成用に 1 つ) と 2 つのコンテナー (各ステップに 1 つ) があります。
OpenShift Container Platform はプロジェクトに設定された制限範囲を使用して、必要なリソース要求および制限を計算します。この例では、プロジェクトに以下の制限範囲を設定します。
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
spec:
limits:
- max:
memory: 1Gi
min:
memory: 500Mi
type: Containerこのシナリオでは、各 init コンテナーは要求メモリー 1 Gi (制限範囲の上限) を使用し、各コンテナーは 500 Mi の要求メモリーを使用します。そのため、Pod のメモリー要求の合計は 2 Gi になります。
同じ制限範囲が 10 のステップのタスクで使用される場合、最終的なメモリー要求は 5 Gi になります。これは、各ステップで実際に必要とされるサイズ (500 Mi) よりも大きくなります (それぞれのステップは他のステップの後に実行されるためです)。
そのため、リソースによるリソース消費を減らすには、以下を行います。
- スクリプト機能および同じイメージを使用して、複数の異なるステップを 1 つの大きなステップにグループ化し、特定のタスクのステップ数を減らします。これにより、要求される最小リソースを減らすことができます。
- 相互に独立しており、独立して実行できるステップを、単一のタスクではなく、複数のタスクに分散します。これにより、各タスクのステップ数が減り、各タスクの要求が小さくなるため、スケジューラーはリソースが利用可能になるとそれらを実行できます。
