Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第17章 クォータの設定

17.1. 概要

ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。

注記

コンピュートリソースについての詳細は、『Developer Guide』を参照してください。

17.2. クォータで管理されるリソース

以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプについて説明します。

注記

status.phase in (Failed, Succeeded) が true の場合、Pod は終了状態にあります。

表17.1 クォータで管理されるコンピュートリソース

リソース名説明

cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

ephemeral-storage

非終了状態のすべての pod におけるローカルの一時ストレージ要求の合計はこの値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。

requests.cpu

非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。cpu および requests.cpu は同じ値で、交換可能なものとして使用できます。

requests.memory

非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません memory および requests.memory は同じ値で、交換可能なものとして使用できます。

requests.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。ephemeral-storage および requests.ephemeral-storage は同じ値であり、相互に置き換え可能なものとして使用できます。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。

limits.cpu

非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。

limits.memory

非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。

limits.ephemeral-storage

非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。

表17.2 クォータで管理されるストレージリソース

リソース名説明

requests.storage

任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。

persistentvolumeclaims

プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

一致するストレージクラスを持つ、任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

プロジェクトに存在できる、一致するストレージクラスを持つ Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

表17.3 クォータで管理されるオブジェクト数

リソース名説明

pods

プロジェクトに存在できる非終了状態の Pod の合計数です。

replicationcontrollers

プロジェクトに存在できるレプリケーションコントローラーの合計数です。

resourcequotas

プロジェクトに存在できるリソースクォータの合計数です。

services

プロジェクトに存在できるサービスの合計数です。

secrets

プロジェクトに存在できるシークレットの合計数です。

configmaps

プロジェクトに存在できる ConfigMap オブジェクトの合計数です。

persistentvolumeclaims

プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。

openshift.io/imagestreams

プロジェクトに存在できるイメージストリームの合計数です。

クォータの作成時に、count/<resource>.<group> 構文を使用してこれらの標準的な namespace を使用しているリソースタイプのオブジェクトカウントクォータを設定できます。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> 1
1
<resource> はリソースの名前であり、<group> は API グループです (該当する場合)。リソースおよびそれらの関連付けられた API グループの一覧に kubectl api-resources コマンドを使用します。

17.2.1. 拡張リソースのリソースクォータの設定

リソースのオーバーコミットは拡張リソースには許可されません。そのため、クォータで同じ拡張リソースについて requests および limits を指定する必要があります。現時点で、プレフィックス requests. のあるクォータ項目のみが拡張リソースに許可されます。以下は、GPU リソース nvidia.com/gpu のリソースクォータを設定する方法についてのシナリオ例です。

手順

  1. クラスター内のノードで利用可能な GPU の数を判別します。以下は例になります。

    # oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'
                        openshift.com/gpu-accelerator=true
    Capacity:
     nvidia.com/gpu:  2
    Allocatable:
     nvidia.com/gpu:  2
      nvidia.com/gpu  0           0

    この例では、2 つの GPU が利用可能です。

  2. namespace nvidia にクォータを設定します。この例では、クォータは 1 です。

    # cat gpu-quota.yaml
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1
  3. クォータを作成します。

    # oc create -f gpu-quota.yaml
    resourcequota/gpu-quota created
  4. namespace に正しいクォータが設定されていることを確認します。

    # oc describe quota gpu-quota -n nvidia
    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1
  5. 単一 GPU を要求する Pod を実行します。

    # oc create pod gpu-pod.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      generateName: gpu-pod-
      namespace: nvidia
    spec:
      restartPolicy: OnFailure
      containers:
      - name: rhel7-gpu-pod
        image: rhel7
        env:
          - name: NVIDIA_VISIBLE_DEVICES
            value: all
          - name: NVIDIA_DRIVER_CAPABILITIES
            value: "compute,utility"
          - name: NVIDIA_REQUIRE_CUDA
            value: "cuda>=5.0"
    
        command: ["sleep"]
        args: ["infinity"]
    
        resources:
          limits:
            nvidia.com/gpu: 1
  6. Pod が実行されていることを確認します。

    # oc get pods
    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m
  7. クォータ Used のカウンターが正しいことを確認します。

    # oc describe quota gpu-quota -n nvidia
    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1
  8. nvidia namespace で 2 番目の GPU Pod の作成を試行します。2 つの GPU があるので、これをノード上で実行することは可能です。

    # oc create -f gpu-pod.yaml
    Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1

    クォータが 1 GPU であり、この Pod がそのクォータを超える 2 つ目の GPU の割り当てを試行したため、Forbidden エラーメッセージが表示されることが予想されます。

17.3. クォータのスコープ

各クォータには スコープ のセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。

スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。

スコープ説明

Terminating

spec.activeDeadlineSeconds >= 0 の Pod に一致します。

NotTerminating

spec.activeDeadlineSecondsnil の Pod に一致します。

BestEffort

cpu または memory のいずれかの QoS (Quality of Service) が Best Effort の Pod に一致します。コンピュートリソースのコミットについての詳細は、「QoS (Quality of Service) クラス」を参照してください。

NotBestEffort

cpu および memory の QoS (Quality of Service) が Best Effort でない Pod に一致します。

BestEffort スコープは、以下のリソースを制限するようにクォータを制限します。

  • pods

TerminatingNotTerminating、および NotBestEffort スコープは、以下のリソースを追跡するようにクォータを制限します。

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu
  • ephemeral-storage
  • requests.ephemeral-storage
  • limits.ephemeral-storage
注記

一時ストレージ要求と制限は、テクノロジープレビューとして提供されている一時ストレージを有効にした場合にのみ適用されます。この機能はデフォルトでは無効になっています。

17.4. クォータの実施

プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計が計算されるまでクォータ制約の違反を引き起こす可能性のある新規リソースの作成機能を制限します。

クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。

リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。設定可能な時間を指定して、クォータ使用量の統計値を現在確認されるシステム値まで下げるのに必要な時間を決定します。

プロジェクト変更がクォータ使用制限を超える場合、サーバーはそのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージがユーザーに返されます。

17.5. 要求 vs 制限

コンピュートリソースの割り当て時に、各コンテナーは CPU、メモリー、一時ストレージのそれぞれに要求値と制限値を指定できます。クォータはこれらの値を制限できます。

クォータに requests.cpu または requests.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースを明示的に要求することが求められます。クォータに limits.cpu または limits.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースの明示的な制限を指定することが求められます。

17.6. リソースクォータ定義のサンプル

core-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 1
    persistentvolumeclaims: "4" 2
    replicationcontrollers: "20" 3
    secrets: "10" 4
    services: "10" 5

1
プロジェクトに存在できる ConfigMap オブジェクトの合計数です。
2
プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。
3
プロジェクトに存在できるレプリケーションコントローラーの合計数です。
4
プロジェクトに存在できるシークレットの合計数です。
5
プロジェクトに存在できるサービスの合計数です。

openshift-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 1

1
プロジェクトに存在できるイメージストリームの合計数です。

compute-resources.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 1
    requests.cpu: "1" 2
    requests.memory: 1Gi 3
    requests.ephemeral-storage: 2Gi 4
    limits.cpu: "2" 5
    limits.memory: 2Gi 6
    limits.ephemeral-storage: 4Gi 7

1
プロジェクトに存在できる非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 要求の合計は 1 コアを超えることができません。
3
非終了状態のすべての Pod において、メモリー要求の合計は 1 Gi を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ要求の合計は 2 Gi を超えることができません。
5
非終了状態のすべての Pod において、CPU 制限の合計は 2 コアを超えることができません。
6
非終了状態のすべての Pod において、メモリー制限の合計は 2 Gi を超えることができません。
7
非終了状態のすべての Pod において、一時ストレージ制限の合計は 4 Gi を超えることができません。

besteffort.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 1
  scopes:
  - BestEffort 2

1
プロジェクトに存在できる QoS (Quality of Service) が BestEffort の非終了状態の Pod の合計数です
2
クォータを、メモリーまたは CPU のいずれかの QoS (Quality of Service) が BestEffort の一致する Pod のみに制限します。

compute-resources-long-running.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 1
    limits.cpu: "4" 2
    limits.memory: "2Gi" 3
    limits.ephemeral-storage: "4Gi" 4
  scopes:
  - NotTerminating 5

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータをspec.activeDeadlineSecondsnil に設定されている一致する Pod のみに制限します。ビルド Pod は、RestartNever ポリシーが適用されない場合に NotTerminating になります。

compute-resources-time-bound.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 1
    limits.cpu: "1" 2
    limits.memory: "1Gi" 3
    limits.ephemeral-storage: "1Gi" 4
  scopes:
  - Terminating 5

1
非終了状態の Pod の合計数です。
2
非終了状態のすべての Pod において、CPU 制限の合計はこの値を超えることができません。
3
非終了状態のすべての Pod において、メモリー制限の合計はこの値を超えることができません。
4
非終了状態のすべての Pod において、一時ストレージ制限の合計はこの値を超えることができません。
5
クォータをspec.activeDeadlineSeconds >=0 に設定されている一致する Pod のみに制限します。たとえば、このクォータはビルド Pod またはデプロイヤー Pod に影響を与えますが、web サーバーまたはデータベースなどの長時間実行されない Pod には影響を与えません。

storage-consumption.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 1
    requests.storage: "50Gi" 2
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
    bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

1
プロジェクト内の Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。
2
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、要求されるストレージの合計はこの値を超えることができません。
3
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、gold ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
4
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silver ストレージクラスで要求されるストレージの合計はこの値を超えることができません。
5
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、silver ストレージクラスの要求の合計数はこの値を超えることができません。
6
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合、bronze ストレージクラスはストレージを要求できないことを意味します。
7
プロジェクトのすべての Persistent Volume Claim (永続ボリューム要求、PVC) において、bronze ストレージクラスで要求されるストレージの合計はこの値を超えることができません。これが 0 に設定される場合は、bronze ストレージクラスでは要求を作成できないことを意味します。

17.7. クォータの作成

クォータを作成するには、「リソースクォータ定義のサンプル」に示されるように、まずクォータをファイルに定義します。次に、そのファイルを使用してこれをプロジェクトに適用します。

$ oc create -f <resource_quota_definition> [-n <project_name>]

例:

$ oc create -f core-object-counts.yaml -n demoproject

17.7.1. オブジェクトカウントクォータの作成

BuildConfig および DeploymentConfig などの、OpenShift Container Platform の標準的な namespace を使用しているリソースタイプのすべてにオブジェクトカウントクォータ を作成できます。オブジェクトクォータカウントは、定義されたクォータをすべての標準的な namespace を使用しているリソースタイプに設定します。

リソースクォータの使用時に、オブジェクトがサーバーストレージにある場合、そのオブジェクトはクォータに基づいてチャージされます。以下のクォータのタイプはストレージリソースが使い切られることから保護するのに役立ちます。

リソースのオブジェクトカウントクォータを設定するには、以下のコマンドを実行します。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

例:

$ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4
resourcequota "test" created

$ oc describe quota test
Name:                         test
Namespace:                    quota
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  0     2
count/pods                    0     3
count/replicasets.extensions  0     4
count/secrets                 0     4

この例では、一覧表示されたリソースをクラスター内の各プロジェクトのハード制限に制限します。

17.8. クォータの表示

web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計を表示できます。

CLI を使用してクォータの詳細を表示することもできます。

  1. 最初に、プロジェクトで定義されたクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。

    $ oc get quota -n demoproject
    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m
  2. 次に、関連するクォータについて記述します。たとえば、core-object-counts クォータの場合、以下を実行します。

    $ oc describe quota core-object-counts -n demoproject
    Name:			core-object-counts
    Namespace:		demoproject
    Resource		Used	Hard
    --------		----	----
    configmaps		3	10
    persistentvolumeclaims	0	4
    replicationcontrollers	3	20
    secrets			9	10
    services		2	10

17.9. クォータの同期期間の設定

リソースのセットが削除される際に、リソースの同期期間が /etc/origin/master/master-config.yaml ファイルの resource-quota-sync-period 設定によって決定されます。

クォータの使用状況が復元される前に、ユーザーがリソースの再使用を試行すると問題が発生する場合があります。resource-quota-sync-period 設定を変更して、リソースセットの再生成が所定の期間 (秒単位) に実行され、リソースを再度利用可能にすることができます。

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"

変更後に、マスターサービスを再起動してそれらの変更を適用します。

# master-restart api
# master-restart controllers

再生成時間の調整は、リソースの作成および自動化が使用される場合のリソース使用状況の判別に役立ちます。

注記

resource-quota-sync-period 設定は、システムパフォーマンスのバランスを取るように設計されています。同期期間を短縮すると、マスターに大きな負荷がかかる可能性があります。

17.10. デプロイメント設定におけるクォータアカウンティング

クォータがプロジェクトに定義されている場合、デプロイメント設定の考慮事項については、「デプロイメントリソース」を参照してください。

17.11. リソース消費における明示的なクォータの要求

リソースがクォータで管理されていない場合、ユーザーには消費できるリソース量の制限がありません。たとえば、gold ストレージクラスに関連するストレージのクォータがない場合、プロジェクトが作成できる gold ストレージの容量はバインドされません。

高コストのコンピュートまたはストレージリソースの場合、管理者はリソースを消費するための明示的なクォータの付与が必要となるようにする場合があります。たとえば、プロジェクトに gold ストレージクラスに関連するストレージのクォータが明示的に付与されていない場合、そのプロジェクトのユーザーはこのタイプのストレージを作成することができません。

特定リソースの消費における明示的なクォータが必要となるようにするには、以下のスタンザを master-config.yaml に追加する必要があります。

admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims 1
        matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage 2
1
デフォルトで消費が制限されるグループ/リソースです。
2
デフォルトで制限対象となる、グループ/リソースに関連付けられたクォータで追跡されるリソースの名前です。

上記の例では、クォータシステムは PersistentVolumeClaim を作成するか、または更新するすべての操作をインターセプトします。これは、クォータで認識されるリソースが消費されることを確認し、プロジェクトのそれらのリソースのクォータがない場合に要求は拒否されます。この例ではユーザーが gold ストレージクラスに関連付けられたストレージを使用する PersistentVolumeClaim を作成しており、プロジェクトに一致するクォータがない場合には要求が拒否されます。

17.12. 既知の問題

  • 無効なオブジェクトにより、プロジェクトのクォータリソースが使い切られる可能性があります。クォータはリソースの検証前に受付において増分します。その結果、クォータは Pod が最終的に永続しない場合でも増分する可能性があります。この問題は、今後のリリースで解決される予定です。(BZ1485375)