7.3. 制限範囲によるリソース消費の制限
デフォルトで、コンテナーは OpenShift Container Platform クラスターのバインドされていないコンピュートリソースで実行されます。制限範囲については、プロジェクト内の特定オブジェクトのリソースの消費を制限できます。
- Pod およびコンテナー: Pod およびそれらのコンテナーの CPU およびメモリーの最小および最大要件を設定できます。
-
イメージストリーム:
ImageStream
オブジェクトのイメージおよびタグの数に制限を設定できます。 - イメージ: 内部レジストリーにプッシュできるイメージのサイズを制限することができます。
- 永続ボリューム要求 (PVC): 要求できる PVC のサイズを制限できます。
Pod が制限範囲で課される制約を満たさない場合、Pod を namespace に作成することはできません。
7.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"
7.3.1.1. コンポーネントの制限について
以下の例は、それぞれのコンポーネントの制限範囲パラメーターを示しています。これらの例は明確にするために使用されます。必要に応じて、いずれかまたはすべてのコンポーネントの単一の LimitRange
オブジェクトを作成できます。
7.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 Container Platform は、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
- 制限範囲オブジェクトの名前です。
- 2
- Pod の単一コンテナーが要求できる CPU の最大量です。
- 3
- Pod の単一コンテナーが要求できるメモリーの最大量です。
- 4
- Pod の単一コンテナーが要求できる CPU の最小量です。
- 5
- Pod の単一コンテナーが要求できるメモリーの最小量です。
- 6
- コンテナーが使用できる CPU のデフォルト量 (
Pod
仕様に指定されていない場合)。 - 7
- コンテナーが使用できるメモリーのデフォルト量 (
Pod
仕様に指定されていない場合)。 - 8
- コンテナーが要求できる CPU のデフォルト量 (
Pod
仕様に指定されていない場合)。 - 9
- コンテナーが要求できるメモリーのデフォルト量 (
Pod
仕様に指定されていない場合)。 - 10
- コンテナーの要求に対する制限の最大比率。
7.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
7.3.1.1.3. イメージの制限
LimitRange
オブジェクトにより、内部レジストリーにプッシュできるイメージの最大サイズを指定できます。
イメージを内部レジストリーにプッシュする場合には、以下が当てはまります。
-
イメージのサイズは、
LimitRange
オブジェクトで指定されるイメージのmax
サイズ以下である必要があります。
イメージ LimitRange
オブジェクトの定義
apiVersion: "v1" kind: "LimitRange" metadata: name: "resource-limits" 1 spec: limits: - type: openshift.io/Image max: storage: 1Gi 2
制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。
イメージのサイズは、アップロードされるイメージのマニフェストで常に表示される訳ではありません。これは、とりわけ Docker 1.10 以上で作成され、v2 レジストリーにプッシュされたイメージの場合に該当します。このようなイメージが古い Docker デーモンでプルされると、イメージマニフェストはレジストリーによってスキーマ v1 に変換されますが、この場合サイズ情報が欠落します。イメージに設定されるストレージの制限がこのアップロードを防ぐことはありません。
現在、この問題 への対応が行われています。
7.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
リソースは、イメージストリームのステータスに記録される一意のイメージ名を表します。これにより、内部レジストリーにプッシュできるイメージ数を制限できます。内部参照か外部参照であるかの区別はありません。
7.3.1.1.5. 永続ボリューム要求 (PVC) の制限
LimitRange
オブジェクトにより、永続ボリューム要求 (PVC) で要求されるストレージを制限できます。
プロジェクトのすべての永続ボリューム要求 (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