第25章制限範囲の設定

25.1. 制限範囲の目的

LimitRange オブジェクトで定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および Persistent Volume Claim (永続ボリューム要求、PVC) のレベルでプロジェクトのコンピュートリソース制約を列挙し、Pod、コンテナー、イメージ、イメージストリームまたは Persistent Volume Claim (永続ボリューム要求、PVC) で消費できるリソースの量を指定します。

すべてのリソース作成および変更要求は、プロジェクトのそれぞれの LimitRange オブジェクトに対して評価されます。リソースが列挙される制約のいずれかに違反する場合、そのリソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。

CPU とメモリーの制限について、最大値を指定しても最小値を指定しない場合、リソースは最大値よりも多くの CPU とメモリーリソースを消費する可能性があります。

一時ストレージのテクノロジープレビューを使用して一時ストレージの制限と要求を指定できます。この機能はデフォルトでは無効になっています。この機能を有効にするには、configuring for ephemeral storage を参照してください。

コア Limit Range オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" 1
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" 2
        memory: "1Gi" 3
      min:
        cpu: "200m" 4
        memory: "6Mi" 5
    - type: "Container"
      max:
        cpu: "2" 6
        memory: "1Gi" 7
      min:
        cpu: "100m" 8
        memory: "4Mi" 9
      default:
        cpu: "300m" 10
        memory: "200Mi" 11
      defaultRequest:
        cpu: "200m" 12
        memory: "100Mi" 13
      maxLimitRequestRatio:
        cpu: "10" 14

1: 制限範囲オブジェクトの名前です。
2: すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
3: すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
4: すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
5: すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
6: Pod の単一コンテナーが要求できる CPU の最大量です。
7: Pod の単一コンテナーが要求できるメモリーの最大量です。
8: Pod の単一コンテナーが要求できる CPU の最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
9: Pod の単一コンテナーが要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
10: Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトの CPU 制限。
11: Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトのメモリー制限。
12: Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトの CPU 要求。
13: Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトのメモリー要求。
14: コンテナーの要求に対する制限の最大比率。

CPU およびメモリーの測定方法についての詳細は、コンピュートリソースを参照してください。

OpenShift Container Platform の Limit Range オブジェクトの定義

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi 1
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20 2
        openshift.io/images: 30 3
    - type: "Pod"
      max:
        cpu: "2" 4
        memory: "1Gi" 5
        ephemeral-storage: "1Gi" 6
     max:
        cpu: "1" 7
        memory: "1Gi" 8

1: 内部レジストリーにプッシュできるイメージの最大サイズ。
2: イメージストリームの仕様で定義される一意のイメージタグの最大数。
3: イメージストリームのステータスについて仕様で定義される一意のイメージ参照の最大数。
4: すべてのコンテナーにおいて Pod がノードで要求できる CPU の最大量です。
5: すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最大量です。
6: 一時ストレージのテクノロジープレビュー機能が有効にされる場合に、すべてのコンテナーにおいて Pod がノードで要求できる一時ストレージの最大量です。
7: すべてのコンテナーにおいて Pod がノードで要求できる CPU の最小量です。min 値を設定する場合や、min を 0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
8: すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min を 0 に設定すると、結果の制限がなく、Pod は max メモリー値を超える量を消費することができます。

コアおよび OpenShift Container Platform リソースの両方を 1 つの制限範囲オブジェクトで指定できます。これらは、明確にするために 2 つの例に個別に示します。

25.1.1. コンテナーの制限

サポートされるリソース:

CPU
メモリー

サポートされる制約:

コンテナーごとに設定されます。指定される場合、以下を満たしている必要があります。

表25.1 コンテナー
制約	動作
`Min`	`Min[resource]`: `container.resources.requests[resource]` (必須) または `container/resources.limits[resource]` (オプション) 以下設定で `min` CPU を定義している場合、要求値はその CPU 値よりも大きくなければなりません。`min` 値を設定しない場合や、`min` を `0` に設定すると、結果は制限されず、Pod は `max` 値よりも多くのリソースを消費できます。
`Max`	`container.resources.limits[resource]` (必須): `Max[resource]` 以下設定で `max` CPU を定義している場合、CPU 要求値を定義する必要はありません。ただし、制限範囲で指定される最大 CPU 制約を満たす制限を設定する必要があります。
`MaxLimitRequestRatio`	`MaxLimitRequestRatio[resource]` は (`container.resources.limits[resource]` / `container.resources.requests[resource]`) 以下です。制限範囲で `maxLimitRequestRatio` 制約を定義する場合、新規コンテナーには `request` と `limit` 値の両方が必要になります。さらに OpenShift Container Platform は、`limit` を `request` で除算して、制限の要求に対する比率を算出します。結果は、1 を超える整数である必要があります。たとえば、コンテナーの `limit` 値が `cpu: 500` で、`request` 値が `cpu: 100` である場合、`cpu` の要求に対する制限の比は `5` になります。この比率は `maxLimitRequestRatio` より小さいか等しくなければなりません。

サポートされるデフォルト:

Default[resource]: 指定がない場合は container.resources.limit[resource] を所定の値にデフォルト設定します。
Default Requests[resource]: 指定がない場合は、container.resources.requests[resource] を所定の値にデフォルト設定します。

25.1.2. Pod の制限

サポートされるリソース:

CPU
メモリー

サポートされる制約:

Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。

表25.2 Pod
制約	実施される動作
`Min`	`Min[resource]`: `container.resources.requests[resource]` (必須) 以下または `container.resources.limits[resource]` 以下`min` 値を設定しない場合や、`min` を `0` に設定すると、結果は制限されず、Pod は `max` 値よりも多くのリソースを消費できます。
`Max`	`container.resources.limits[resource]` (必須): `Max[resource]` 以下
`MaxLimitRequestRatio`	`MaxLimitRequestRatio[resource]` は (`container.resources.limits[resource]` / `container.resources.requests[resource]`) 以下です。

25.1.3. イメージの制限

サポートされるリソース:

ストレージ

リソースタイプ名:

openshift.io/Image

イメージごとに設定されます。指定される場合、以下が一致している必要があります。

表25.3 イメージ
制約	動作
`Max`	`image.dockerimagemetadata.size`: `Max[resource]` より小さいか等しい

注記

制限を超える Blob がレジストリーにアップロードされないようにするために、クォータを実施するようレジストリーを設定する必要があります。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 環境変数を true に設定する必要があります。デフォルトでは、新規デプロイメントでは、環境変数は true に設定されます。

警告

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

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

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

サポートされるリソース:

openshift.io/image-tags
openshift.io/images

リソースタイプ名:

openshift.io/ImageStream

イメージストリームごとに設定されます。指定される場合、以下が一致している必要があります。

表25.4 ImageStream
制約	動作
`Max[openshift.io/image-tags]`	`length( uniqueimagetags( imagestream.spec.tags ) )`: `Max[openshift.io/image-tags]` より小さいか等しい `uniqueimagetags` は、指定された仕様タグのイメージへの一意の参照を返します。
`Max[openshift.io/images]`	`length( uniqueimages( imagestream.status.tags ) )`: `Max[openshift.io/images]` より小さいか等しい `uniqueimages` はステータスタグにある一意のイメージ名を返します。名前はイメージのダイジェストと等しくなります。

25.1.4.1. イメージ参照の数

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

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

25.1.5. PersistentVolumeClaim の制限

サポートされるリソース:

ストレージ

サポートされる制約:

プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、以下が一致している必要があります。

表25.5 Pod
制約	実施される動作
`Min`	Min[resource] <= claim.spec.resources.requests[resource] (必須)
`Max`	claim.spec.resources.requests[resource] (必須) <= Max[resource]

Limit Range オブジェクトの定義

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" 1
  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" 2
        },
        "max": {
          "storage": "50Gi" 3
        }
      }
    ]
  }
}

1: 制限範囲オブジェクトの名前です。
2: Persistent Volume Claim (永続ボリューム要求、PVC) で要求できるストレージの最小量です。
3: 永続ボリューム要求 (PVC) で要求できるストレージの最大量です。

第25章制限範囲の設定

25.1. 制限範囲の目的

25.1.1. コンテナーの制限

25.1.2. Pod の制限

25.1.3. イメージの制限

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

25.1.4.1. イメージ参照の数

25.1.5. PersistentVolumeClaim の制限

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第25章 制限範囲の設定

25.1. 制限範囲の目的

25.1.1. コンテナーの制限

25.1.2. Pod の制限

25.1.3. イメージの制限

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

25.1.4.1. イメージ参照の数

25.1.5. PersistentVolumeClaim の制限

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第25章制限範囲の設定