2.2. コンテナーのリソース要件
タスクと Web コンテナーで、リソース要求の下限 (要求) と上限 (制限) の両方を設定できます。実行環境のコントロールプレーンは、プロジェクトの更新に使用されますが、通常はジョブのデフォルトの実行環境と同じです。
リソースの要求と制限を設定することはベストプラクティスです。なぜなら、両方が定義されているコンテナーには、より高い Quality of Service クラスが指定されるからです。これは、基盤となるノードにリソース制限があり、クラスターが実行中のメモリーやその他の障害を防ぐために Pod をリープする必要がある場合は、コントロールプレーン Pod がリープされる可能性が低いことを意味します。
これらの要求と制限は、Automation Controller のコントロール Pod に適用され、制限が設定されている場合は、インスタンスの 容量 が決まります。デフォルトでは、ジョブの制御には 1 単位の容量が必要です。タスクコンテナーのメモリーと CPU の制限は、コントロールノードの容量を決定するために使用されます。計算方法の詳細は、容量アルゴリズムのリソース決定 を参照してください。
ワーカーノードにスケジュールされたジョブ も参照してください。
名前 | 説明 | デフォルト |
---|---|---|
| Web コンテナーのリソース要件 | requests: {CPU: 100m, memory: 128Mi} |
| タスクコンテナーのリソース要件 | requests: {CPU: 100m, memory: 128Mi} |
| EE コントロールプレーンコンテナーのリソース要件 | requests: {CPU: 100m, memory: 128Mi} |
| Redis コントロールプレーンコンテナーのリソース要件 | requests: {CPU:100m, memory: 128Mi} |
制御ノードを個別の基盤となる Kubernetes ワーカーノードに最大限に分散するには、topology_spread_constraints
を使用することを推奨します。要求と制限の適切なセットは、その合計がノード上の実際のリソースと等しくなる制限です。制限
のみが設定されている場合は、リクエストが制限と等しくなるように自動的に設定されます。ただし、コントロール Pod 内のコンテナー間でリソース使用量の変動が許容されるため、requests
をより低い量 (ノードで使用可能なリソースの 25% など) に設定できます。クラスターに 4 つの CPU と 16GB の RAM が割り当てられたワーカーノードのコンテナーのカスタマイズ例は、以下のとおりです。
spec: ... web_resource_requirements: requests: cpu: 250m memory: 1Gi limits: cpu: 1000m memory: 4Gi task_resource_requirements: requests: cpu: 250m memory: 1Gi limits: cpu: 2000m memory: 4Gi redis_resource_requirements requests: cpu: 250m memory: 1Gi limits: cpu: 1000m memory: 4Gi ee_resource_requirements: requests: cpu: 250m memory: 1Gi limits: cpu: 1000m memory: 4Gi
spec:
...
web_resource_requirements:
requests:
cpu: 250m
memory: 1Gi
limits:
cpu: 1000m
memory: 4Gi
task_resource_requirements:
requests:
cpu: 250m
memory: 1Gi
limits:
cpu: 2000m
memory: 4Gi
redis_resource_requirements
requests:
cpu: 250m
memory: 1Gi
limits:
cpu: 1000m
memory: 4Gi
ee_resource_requirements:
requests:
cpu: 250m
memory: 1Gi
limits:
cpu: 1000m
memory: 4Gi