Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第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 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
5
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max メモリー値を超える量を消費することができます。
6
Pod の単一コンテナーが要求できる CPU の最大量です。
7
Pod の単一コンテナーが要求できるメモリーの最大量です。
8
Pod の単一コンテナーが要求できる CPU の最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
9
Pod の単一コンテナーが要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果は制限されず、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 値を設定する場合や、min0 に設定すると、結果は制限されず、Pod は max CPU 値を超える量を消費することができます。
8
すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。min 値を設定しない場合や、min0 に設定すると、結果の制限がなく、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 値を設定しない場合や、min0 に設定すると、結果は制限されず、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 制約を定義する場合、新規コンテナーには requestlimit 値の両方が必要になります。さらに OpenShift Container Platform は、limitrequest で除算して、制限の要求に対する比率を算出します。結果は、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 値を設定しない場合や、min0 に設定すると、結果は制限されず、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 リソースは、固有の イメージ参照 を表します。使用可能な参照は、ImageStreamTagImageStreamImage、または 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) で要求できるストレージの最大量です。