検索

第25章 制限範囲の設定

download PDF

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) で要求できるストレージの最大量です。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.