6.3. 制限範囲によるリソース消費の制限

デフォルトで、コンテナーは OpenShift Container Platform クラスターのバインドされていないコンピュートリソースで実行されます。制限範囲については、プロジェクト内の特定オブジェクトのリソースの消費を制限できます。

  • Pod およびコンテナー: Pod およびそれらのコンテナーの CPU およびメモリーの最小および最大要件を設定できます。
  • イメージストリーム: ImageStream オブジェクトのイメージおよびタグの数に制限を設定できます。
  • イメージ: 内部レジストリーにプッシュできるイメージのサイズを制限することができます。
  • 永続ボリューム要求 (PVC): 要求できる PVC のサイズを制限できます。

Pod が制限範囲で課される制約を満たさない場合、Pod を namespace に作成することはできません。

6.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"

6.3.1.1. コンポーネントの制限について

以下の例は、それぞれのコンポーネントの制限範囲パラメーターを示しています。これらの例は明確にするために使用されます。必要に応じて、いずれかまたはすべてのコンポーネントの単一の LimitRange オブジェクトを作成できます。

6.3.1.1.1. コンテナーの制限

制限範囲により、Pod の各コンテナーが特定のプロジェクトについて要求できる最小および最大 CPU およびメモリーを指定できます。コンテナーがプロジェクトに作成される場合、Pod 仕様のコンテナー CPU およびメモリー要求は LimitRange オブジェクトに設定される値に準拠する必要があります。そうでない場合には、Pod は作成されません。

  • コンテナーの CPU またはメモリーの要求および制限は、LimitRange オブジェクトで指定されるコンテナーの min リソース制約以上である必要があります。

  • コンテナーの CPU またはメモリー要求は、LimitRange オブジェクトで指定されるコンテナーの max リソース制約以下である必要があります。

    LimitRange オブジェクトが max CPU を定義する場合、 Pod 仕様に CPU request 値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす CPU limit 値を指定する必要があります。

  • コンテナー制限の要求に対する比率は、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 の最小量です。min 値を設定しない場合や 0 を設定する場合は無制限になります。これにより、Pod は max CPU 値よりも多くの CPU を消費できるようになります。
5
Pod の単一コンテナーが要求できるメモリーの最小量です。min 値を設定しない場合や 0 を設定する場合は無制限になります。これにより、Pod は max メモリー値よりも多くの CPU を消費できるようになります。
6
コンテナーが使用できる CPU のデフォルト量 (Pod 仕様に指定されていない場合)。
7
コンテナーが使用できるメモリーのデフォルト量 (Pod 仕様に指定されていない場合)。
8
コンテナーが要求できる CPU のデフォルト量 (Pod 仕様に指定されていない場合)。
9
コンテナーが要求できるメモリーのデフォルト量 (Pod 仕様に指定されていない場合)。
10
コンテナーの要求に対する制限の最大比率。
6.3.1.1.2. Pod の制限

制限範囲により、所定プロジェクトの Pod 全体でのすべてのコンテナーの CPU およびメモリーの最小および最大の制限を指定できます。コンテナーをプロジェクトに作成するには、Pod 仕様のコンテナー CPU およびメモリー要求は LimitRange オブジェクトに設定される値に準拠する必要があります。そうでない場合には、Pod は作成されません。

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

1
制限範囲オブジェクトの名前です。
2
すべてのコンテナーにおいて Pod が要求できる CPU の最大量です。
3
すべてのコンテナーにおいて Pod が要求できるメモリーの最大量です。
4
すべてのコンテナーにおいて Pod が要求できる CPU の最小量です。min 値を設定しない場合や 0 を設定する場合は無制限になります。これにより、Pod は max CPU 値よりも多くの CPU を消費できるようになります。
5
すべてのコンテナーにおいて Pod が要求できるメモリーの最小量です。min 値を設定しない場合や 0 を設定する場合は無制限になります。これにより、Pod は max メモリー値よりも多くの CPU を消費できるようになります。
6
コンテナーの要求に対する制限の最大比率。
6.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

1
LimitRange オブジェクトの名前。
2
内部レジストリーにプッシュできるイメージの最大サイズ。
注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。

警告

イメージのサイズは、アップロードされるイメージのマニフェストで常に表示される訳ではありません。これは、とりわけ Docker 1.10 以上で作成され、v2 レジストリーにプッシュされたイメージの場合に該当します。このようなイメージが古い Docker デーモンでプルされると、イメージマニフェストはレジストリーによってスキーマ v1 に変換されますが、この場合サイズ情報が欠落します。イメージに設定されるストレージの制限がこのアップロードを防ぐことはありません。

現在、この問題 への対応が行われています。

6.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

1
LimitRange オブジェクトの名前。
2
イメージストリーム仕様の imagestream.spec.tags パラメーターの一意のイメージタグの最大数。
3
imagestream 仕様の imagestream.status.tags パラメーターの一意のイメージ参照の最大数。

openshift.io/image-tags リソースは、一意のイメージ参照を表します。使用できる参照は、ImageStreamTag、ImageStreamImage および DockerImage になります。タグは、oc tag および oc import-image コマンドを使用して作成できます。内部参照か外部参照であるかの区別はありません。ただし、ImageStream の仕様でタグ付けされる一意の参照はそれぞれ 1 回のみカウントされます。内部コンテナーイメージレジストリーへのプッシュを制限しませんが、タグの制限に役立ちます。

openshift.io/images リソースは、イメージストリームのステータスに記録される一意のイメージ名を表します。これにより、内部レジストリーにプッシュできるイメージ数を制限できます。内部参照か外部参照であるかの区別はありません。

6.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

1
LimitRange オブジェクトの名前。
2
永続ボリューム要求 (PVC) で要求できるストレージの最小量です。
3
永続ボリューム要求 (PVC) で要求できるストレージの最大量です。