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


LimitRange オブジェクトを作成または編集する際に、各コンポーネントの制限範囲パラメーターを理解するために、以下の例を確認してください。

これらの例は明確にするために使用されます。必要に応じて、いずれかまたはすべてのコンポーネントの単一の LimitRange オブジェクトを作成できます。

コンテナーの制限

制限範囲により、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 は、limitrequest で除算して制限の要求に対する比率を算出します。この値は、1 より大きい正の整数でなければなりません。

    たとえば、コンテナーの limit 値が cpu: 500 で、request 値が cpu: 100 である場合、cpu の要求に対する制限の比は 5 になります。この比率は maxLimitRequestRatio より小さいか等しくなければなりません。

Pod 仕様でコンテナーリソースメモリーまたは制限を指定しない場合、制限範囲オブジェクトに指定されるコンテナーの default または defaultRequest CPU およびメモリー値はコンテナーに割り当てられます。

コンテナー LimitRange オブジェクトの定義

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"

ここでは、以下のようになります。

metadata.name
制限範囲オブジェクトの名前を指定します。
仕様制限最大 CPU
Pod 内の単一コンテナーが要求できる最大 CPU 量を指定します。
仕様制限最大メモリー
Pod 内の単一コンテナーが要求できる最大メモリー量を指定します。
仕様制限最小 CPU
Pod 内の単一コンテナーが要求できる最小 CPU 量を指定します。
仕様制限最小メモリー
Pod 内の単一コンテナーが要求できる最小メモリー量を指定します。
spec.limit.default.cpu
Pod 仕様で指定されていない場合に、コンテナーが使用できるデフォルトの CPU 量を指定します。
仕様制限デフォルトメモリー
Pod 仕様で指定されていない場合に、コンテナーが使用できるデフォルトのメモリー量を指定します。
spec.limit.defaultRequest.cpu
Pod 仕様で指定されていない場合に、コンテナーが要求できるデフォルトの CPU 量を指定します。
spec.limit.defaultRequest.memory
Pod 仕様で指定されていない場合に、コンテナーが要求できるデフォルトのメモリー量を指定します。
spec.limit.maxLimitRequestRatio.cpu
コンテナーの最大制限対リクエスト比率を指定します。
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"
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2"
        memory: "1Gi"
      min:
        cpu: "200m"
        memory: "6Mi"
      maxLimitRequestRatio:
        cpu: "10"

ここでは、以下のようになります。

metadata.name
制限範囲オブジェクトの名前を指定します。
仕様制限最大 CPU
Pod がすべてのコンテナーで要求できる最大 CPU 量を指定します。
仕様制限最大メモリー
Pod がすべてのコンテナー全体で要求できる最大メモリー量を指定します。
仕様制限最小 CPU
Pod がすべてのコンテナーで要求できる最小 CPU 量を指定します。
仕様制限最小メモリー
Pod がすべてのコンテナーで要求できる最小メモリー量を指定します。
spec.limit.maxLimitRequestRatio.cpu
コンテナーの最大制限対リクエスト比率を指定します。
イメージの制限

制限範囲を使用すると、OpenShift イメージレジストリーにプッシュできるイメージの最大サイズを指定できます。

OpenShift イメージレジストリーにイメージをプッシュする場合、以下の要件を満たす必要があります。

  • イメージのサイズは、LimitRange オブジェクトで指定されるイメージの max サイズ以下である必要があります。

イメージ LimitRange オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi

ここでは、以下のようになります。

metadata.name
制限範囲オブジェクトの名前を指定します。
仕様制限最大ストレージ
OpenShift イメージレジストリーにプッシュできるイメージの最大サイズを指定します。
注記

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

警告

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

この問題は現在対処中です。

イメージストリームの制限

制限の範囲により、イメージストリームの制限を指定できます。

各イメージストリームについて、以下の要件を満たす必要があります。

  • ImageStream 仕様のイメージタグ数は、LimitRange オブジェクトの openshift.io/image-tags 制約以下である必要があります。
  • ImageStream 仕様のイメージへの一意の参照数は、制限範囲オブジェクトの openshift.io/images 制約以下である必要があります。

イメージストリーム LimitRange オブジェクト定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "resource-limits"
spec:
  limits:
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20
        openshift.io/images: 30

以下は、

metadata.name
LimitRange オブジェクトの名前を指定します。
spec.limit.max.openshift.io/image-tags
imagestream 仕様の imagestream.spec.tags パラメーターで、一意のイメージタグの最大数を指定します。
spec.limit.max.openshift.io/images
imagestream 仕様の imagestream.status.tags パラメーターで、一意のイメージ参照の最大数を指定します。

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

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

永続ボリューム要求の制限

制限の範囲により、Persistent Volume Claim(永続ボリューム要求、PVC) で要求されるストレージを制限できます。

プロジェクト内のすべての永続的なボリューム要求において、以下の要件が満たされている必要があります。

  • 永続ボリューム要求 (PVC) のリソース要求は、LimitRange オブジェクトに指定される PVC の min 制約以上である必要があります。
  • 永続ボリューム要求 (PVC) のリソース要求は、LimitRange オブジェクトに指定される PVC の max 制約以下である必要があります。

PVC LimitRange オブジェクト定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "resource-limits"
spec:
  limits:
    - type: "PersistentVolumeClaim"
      min:
        storage: "2Gi"
      max:
        storage: "50Gi"

ここでは、以下のようになります。

metadata.name
LimitRange オブジェクトの名前を指定します。
仕様制限最小ストレージ
永続ボリューム要求で要求できる最小ストレージ容量を指定します。
仕様制限最大ストレージ
永続ボリューム要求で要求できるストレージの最大容量を指定します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る