8.3. 制限範囲によるリソース消費の制限
デフォルトで、コンテナーは OpenShift Dedicated クラスターのバインドされていないコンピュートリソースで実行されます。制限範囲は、プロジェクト内の特定オブジェクトのリソースの消費を制限できます。
- Pod およびコンテナー: Pod およびそれらのコンテナーの CPU およびメモリーの最小および最大要件を設定できます。
-
イメージストリーム:
ImageStream
オブジェクトのイメージおよびタグの数に制限を設定できます。 - イメージ: 内部レジストリーにプッシュできるイメージのサイズを制限することができます。
- 永続ボリューム要求 (PVC): 要求できる PVC のサイズを制限できます。
Pod が制限範囲で課される制約を満たさない場合、Pod を namespace に作成することはできません。
8.3.1. 制限範囲について
LimitRange
オブジェクトで定義される制限範囲。プロジェクトのリソース消費を制限します。プロジェクトで、Pod、コンテナー、イメージ、イメージストリーム、または永続ボリューム要求 (PVC) の特定のリソース制限を設定できます。
すべてのリソース作成および変更要求は、プロジェクトのそれぞれの LimitRange
オブジェクトに対して評価されます。リソースが列挙される制約のいずれかに違反する場合、そのリソースは拒否されます。
以下は、Pod、コンテナー、イメージ、イメージストリーム、または PVC のすべてのコンポーネントの制限範囲オブジェクトを示しています。同じオブジェクト内のこれらのコンポーネントのいずれかまたはすべての制限を設定できます。リソースを制御するプロジェクトごとに、異なる制限範囲オブジェクトを作成します。
コンテナーの制限オブジェクトのサンプル
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" spec: limits: - type: "Container" max: cpu: "2" memory: "1Gi" min: cpu: "100m" memory: "4Mi" default: cpu: "300m" memory: "200Mi" defaultRequest: cpu: "200m" memory: "100Mi" maxLimitRequestRatio: cpu: "10"
8.3.1.1. コンポーネントの制限について
以下の例は、それぞれのコンポーネントの制限範囲パラメーターを示しています。これらの例は明確にするために使用されます。必要に応じて、いずれかまたはすべてのコンポーネントの単一の LimitRange
オブジェクトを作成できます。
8.3.1.1.1. コンテナーの制限
制限範囲により、Pod の各コンテナーが特定のプロジェクトについて要求できる最小および最大 CPU およびメモリーを指定できます。コンテナーがプロジェクトに作成される場合、Pod
仕様のコンテナー CPU およびメモリー要求は LimitRange
オブジェクトに設定される値に準拠する必要があります。そうでない場合には、Pod は作成されません。
-
コンテナーの CPU またはメモリーの要求および制限は、
LimitRange
オブジェクトで指定されるコンテナーのmin
リソース制約以上である必要があります。 コンテナーの CPU またはメモリーの要求と制限は、
LimitRange
オブジェクトで指定されたコンテナーのmax
リソース制約以下である必要があります。LimitRange
オブジェクトがmax
CPU を定義する場合、Pod
仕様に CPUrequest
値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす CPUlimit
値を指定する必要があります。コンテナー制限の要求に対する比率は、
LimitRange
オブジェクトに指定されるコンテナーのmaxLimitRequestRatio
値以下である必要があります。LimitRange
オブジェクトでmaxLimitRequestRatio
制約を定義する場合、新規コンテナーにはrequest
およびlimit
値の両方が必要になります。OpenShift Dedicated は、limit
をrequest
で除算して制限の要求に対する比率を算出します。この値は、1 より大きい正の整数でなければなりません。たとえば、コンテナーの
limit
値がcpu: 500
で、request
値がcpu: 100
である場合、cpu
の要求に対する制限の比は5
になります。この比率はmaxLimitRequestRatio
より小さいか等しくなければなりません。
Pod
仕様でコンテナーリソースメモリーまたは制限を指定しない場合、制限範囲オブジェクトに指定されるコンテナーの default
または defaultRequest
CPU およびメモリー値はコンテナーに割り当てられます。
コンテナー LimitRange
オブジェクトの定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: "Container" max: cpu: "2" 2 memory: "1Gi" 3 min: cpu: "100m" 4 memory: "4Mi" 5 default: cpu: "300m" 6 memory: "200Mi" 7 defaultRequest: cpu: "200m" 8 memory: "100Mi" 9 maxLimitRequestRatio: cpu: "10" 10
- 1
- LimitRange オブジェクトの名前です。
- 2
- Pod の単一コンテナーが要求できる CPU の最大量です。
- 3
- Pod の単一コンテナーが要求できるメモリーの最大量です。
- 4
- Pod の単一コンテナーが要求できる CPU の最小量です。
- 5
- Pod の単一コンテナーが要求できるメモリーの最小量です。
- 6
- コンテナーが使用できる CPU のデフォルト量 (
Pod
仕様に指定されていない場合)。 - 7
- コンテナーが使用できるメモリーのデフォルト量 (
Pod
仕様に指定されていない場合)。 - 8
- コンテナーが要求できる CPU のデフォルト量 (
Pod
仕様に指定されていない場合)。 - 9
- コンテナーが要求できるメモリーのデフォルト量 (
Pod
仕様に指定されていない場合)。 - 10
- コンテナーの要求に対する制限の最大比率。
8.3.1.1.2. Pod の制限
制限範囲により、所定プロジェクトの Pod 全体でのすべてのコンテナーの CPU およびメモリーの最小および最大の制限を指定できます。コンテナーをプロジェクトに作成するには、Pod
仕様のコンテナー CPU およびメモリー要求は LimitRange
オブジェクトに設定される値に準拠する必要があります。そうでない場合には、Pod は作成されません。
Pod
仕様でコンテナーリソースメモリーまたは制限を指定しない場合、制限範囲オブジェクトに指定されるコンテナーの default
または defaultRequest
CPU およびメモリー値はコンテナーに割り当てられます。
Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。
-
コンテナーの CPU またはメモリーの要求および制限は、
LimitRange
オブジェクトに指定される Pod のmin
リソース制約以上である必要があります。 -
コンテナーの CPU またはメモリーの要求および制限は、
LimitRange
オブジェクトに指定される Pod のmax
リソース制約以下である必要があります。 -
コンテナー制限の要求に対する比率は、
LimitRange
オブジェクトに指定されるmaxLimitRequestRatio
制約以下である必要があります。
Pod LimitRange
オブジェクト定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: "Pod" max: cpu: "2" 2 memory: "1Gi" 3 min: cpu: "200m" 4 memory: "6Mi" 5 maxLimitRequestRatio: cpu: "10" 6
8.3.1.1.3. イメージの制限
LimitRange
オブジェクトを使用すると、OpenShift イメージレジストリーにプッシュできるイメージの最大サイズを指定できます。
OpenShift イメージレジストリーにイメージをプッシュする場合、以下を満たす必要があります。
-
イメージのサイズは、
LimitRange
オブジェクトで指定されるイメージのmax
サイズ以下である必要があります。
イメージ LimitRange
オブジェクトの定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: openshift.io/Image max: storage: 1Gi 2
イメージのサイズは、アップロードされるイメージのマニフェストで常に表示される訳ではありません。これは、とりわけ Docker 1.10 以上で作成され、v2 レジストリーにプッシュされたイメージの場合に該当します。このようなイメージが古い Docker デーモンでプルされると、イメージマニフェストはレジストリーによってスキーマ v1 に変換されますが、この場合サイズ情報が欠落します。イメージに設定されるストレージの制限がこのアップロードを防ぐことはありません。
現在、この問題 への対応が行われています。
8.3.1.1.4. イメージストリームの制限
LimitRange
オブジェクトにより、イメージストリームの制限を指定できます。
各イメージストリームについて、以下が当てはまります。
-
ImageStream
仕様のイメージタグ数は、LimitRange
オブジェクトのopenshift.io/image-tags
制約以下である必要があります。 -
ImageStream
仕様のイメージへの一意の参照数は、制限範囲オブジェクトのopenshift.io/images
制約以下である必要があります。
イメージストリーム LimitRange
オブジェクト定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: openshift.io/ImageStream max: openshift.io/image-tags: 20 2 openshift.io/images: 30 3
openshift.io/image-tags
リソースは、一意のイメージ参照を表します。使用できる参照は、ImageStreamTag
、ImageStreamImage
および DockerImage
になります。タグは、oc tag
および oc import-image
コマンドを使用して作成できます。内部参照か外部参照であるかの区別はありません。ただし、ImageStream
の仕様でタグ付けされる一意の参照はそれぞれ 1 回のみカウントされます。内部コンテナーイメージレジストリーへのプッシュを制限しませんが、タグの制限に役立ちます。
openshift.io/images
リソースは、イメージストリームのステータスに記録される一意のイメージ名を表します。これにより、OpenShift イメージレジストリーにプッシュできるイメージ数を制限できます。内部参照か外部参照であるかの区別はありません。
8.3.1.1.5. 永続ボリューム要求の制限
LimitRange
オブジェクトにより、永続ボリューム要求 (PVC) で要求されるストレージを制限できます。
プロジェクトのすべての永続ボリューム要求において、以下が一致している必要があります。
-
永続ボリューム要求 (PVC) のリソース要求は、
LimitRange
オブジェクトに指定される PVC のmin
制約以上である必要があります。 -
永続ボリューム要求 (PVC) のリソース要求は、
LimitRange
オブジェクトに指定される PVC のmax
制約以下である必要があります。
PVC LimitRange
オブジェクト定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: "PersistentVolumeClaim" min: storage: "2Gi" 2 max: storage: "50Gi" 3
8.3.2. 制限範囲の作成
制限範囲をプロジェクトに適用するには、以下を実行します。
必要な仕様で
LimitRange
オブジェクトを作成します。apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: "Pod" 2 max: cpu: "2" memory: "1Gi" min: cpu: "200m" memory: "6Mi" - type: "Container" 3 max: cpu: "2" memory: "1Gi" min: cpu: "100m" memory: "4Mi" default: 4 cpu: "300m" memory: "200Mi" defaultRequest: 5 cpu: "200m" memory: "100Mi" maxLimitRequestRatio: 6 cpu: "10" - type: openshift.io/Image 7 max: storage: 1Gi - type: openshift.io/ImageStream 8 max: openshift.io/image-tags: 20 openshift.io/images: 30 - type: "PersistentVolumeClaim" 9 min: storage: "2Gi" max: storage: "50Gi"
- 1
LimitRange
オブジェクトの名前を指定します。- 2
- Pod の制限を設定するには、必要に応じて CPU およびメモリーの最小および最大要求を指定します。
- 3
- コンテナーの制限を設定するには、必要に応じて CPU およびメモリーの最小および最大要求を指定します。
- 4
- オプション: コンテナーの場合、
Pod
仕様で指定されていない場合、コンテナーが使用できる CPU またはメモリーのデフォルト量を指定します。 - 5
- オプション: コンテナーの場合、
Pod
仕様で指定されていない場合、コンテナーが要求できる CPU またはメモリーのデフォルト量を指定します。 - 6
- オプション: コンテナーの場合、
Pod
仕様で指定できる要求に対する制限の最大比率を指定します。 - 7
- Image オブジェクトに制限を設定するには、OpenShift イメージレジストリーにプッシュできるイメージの最大サイズを設定します。
- 8
- イメージストリームの制限を設定するには、必要に応じて
ImageStream
オブジェクトファイルにあるイメージタグおよび参照の最大数を設定します。 - 9
- 永続ボリューム要求の制限を設定するには、要求できるストレージの最小および最大量を設定します。
オブジェクトを作成します。
$ oc create -f <limit_range_file> -n <project> 1
- 1
- 作成した YAML ファイルの名前と、制限を適用する必要のあるプロジェクトを指定します。
8.3.3. 制限の表示
Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限を表示できます。
CLI を使用して制限範囲の詳細を表示することもできます。
プロジェクトで定義される
LimitRange
オブジェクトのリストを取得します。たとえば、demoproject というプロジェクトの場合は以下のようになります。$ oc get limits -n demoproject
NAME CREATED AT resource-limits 2020-07-15T17:14:23Z
関連のある
LimitRange
オブジェクトを記述します。 たとえば、resource-limits
制限範囲の場合は以下のようになります。$ oc describe limits resource-limits -n demoproject
Name: resource-limits Namespace: demoproject Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Pod cpu 200m 2 - - - Pod memory 6Mi 1Gi - - - Container cpu 100m 2 200m 300m 10 Container memory 4Mi 1Gi 100Mi 200Mi - openshift.io/Image storage - 1Gi - - - openshift.io/ImageStream openshift.io/image - 12 - - - openshift.io/ImageStream openshift.io/image-tags - 10 - - - PersistentVolumeClaim storage - 50Gi - - -
8.3.4. 制限範囲の削除
プロジェクトで制限を実施しないように有効な LimitRange
オブジェクト削除するには、以下を実行します。
以下のコマンドを実行します。
$ oc delete limits <limit_name>