Red Hat Summit8.5. 管理者のクォータ使用量
プロジェクトが定められた制約内に収まるようにするため、管理者によるクォータの使用状況を監視してください。コンピュートリソースとストレージの総消費量を追跡することで、リソースクォータの 制限に達した、または近づいた時期を特定できます。
- クォータの実施
プロジェクトのリソースクォータが最初に作成されると、クォータが最新の使用統計を計算するまで、プロジェクトはクォータ制約に違反する可能性のある新しいリソースを作成する機能を制限します。
クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。
リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。
設定可能な時間によって、クォータクォータが現在のシステム観測値まで減少するまでにかかる時間が決定されます。
プロジェクトの変更がクォータ使用量の上限を超えた場合、サーバーはその操作を拒否し、適切なエラーメッセージをユーザーに返します。エラーメッセージには、違反したクォータ制限と、システムにおける現在の使用統計情報が説明されています。
- リクエストと制限の比較
コンピュートリソースをクォータによって割り当てる場合、各コンテナーは CPU、メモリー、および一時ストレージのそれぞれに対して要求値と制限値を指定できます。クォータはこれらの値のいずれも制限できます。
クォータに
requests.cpuまたはrequests.memoryの値が指定されている場合、そのクォータでは、受信するすべてのコンテナーがこれらのリソースを明示的に要求する必要があります。クォータにlimits.cpuまたはlimits.memoryの値が指定されている場合、クォータでは、受信するすべてのコンテナーがこれらのリソースに対して明示的な制限を指定する必要があります。
8.5.1. リソースクォータ定義の例
クォータ設定を適切に設定するには、これらのサンプル ResourceQuota 定義を参照してください。これらの YAML の例は、プロジェクトがクラスターポリシーに準拠するように、コンピュートリソース、ストレージ、およびオブジェクト数に厳密な制限を指定する方法を示しています。
core-object-counts.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: core-object-counts
spec:
hard:
configmaps: "10"
persistentvolumeclaims: "4"
replicationcontrollers: "20"
secrets: "10"
services: "10"
# ...ここでは、以下のようになります。
configmaps-
プロジェクト内に存在できる
ConfigMapオブジェクトの総数を指定します。 persistentvolumeclaims- プロジェクト内に存在できる永続ボリューム要求 (PVC) の総数を指定します。
replicationcontrollers- プロジェクト内に存在できるレプリケーションコントローラーの総数を指定します。
secrets- プロジェクト内に存在できるシークレットの総数を指定します。
services- プロジェクト内に存在できるサービスの総数を指定します。
openshift-object-counts.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: openshift-object-counts
spec:
hard:
openshift.io/imagestreams: "10"
# ...ここでは、以下のようになります。
openshift.io/imagestreams- プロジェクト内に存在できるイメージストリームの総数を指定します。
compute-resources.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4"
requests.cpu: "1"
requests.memory: 1Gi
requests.ephemeral-storage: 2Gi
limits.cpu: "2"
limits.memory: 2Gi
limits.ephemeral-storage: 4Gi
# ...ここでは、以下のようになります。
pods- プロジェクト内に存在できる、非終端状態にある Pod の総数を指定します。
requests.cpu- 非終端状態にあるすべての Pod において、CPU リクエストの合計が 1 コアを超えてはならないことを指定します。
requests.memory- 非終端状態にあるすべての Pod において、メモリー要求の合計が 1 Gi を超えてはならないことを指定します。
requests.ephemeral-storage- 非終端状態にあるすべての Pod において、一時ストレージ要求の合計が 2 Gi を超えてはならないことを指定します。
limits.cpu- 非終端状態にあるすべての Pod において、CPU 制限の合計が 2 コアを超えてはならないことを指定します。
limits.memory- 非終端状態にあるすべての Pod において、メモリー制限の合計が 2 Gi を超えてはならないことを指定します。
limits.ephemeral-storage- 非終端状態にあるすべての Pod において、一時ストレージ制限の合計が 4 Gi を超えてはならないことを指定します。
besteffort.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: besteffort
spec:
hard:
pods: "1"
scopes:
- BestEffort
# ...ここでは、以下のようになります。
pods-
プロジェクト内に存在できる、
BestEffortサービス品質を持つ非終端状態の Pod の総数を指定します。 scopes-
メモリーまたは CPU のいずれかについて
BestEffort のサービス品質を持つ Pod のみに一致するように、クォータに制限を指定します。
compute-resources-long-running.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources-long-running
spec:
hard:
pods: "4"
limits.cpu: "4"
limits.memory: "2Gi"
limits.ephemeral-storage: "4Gi"
scopes:
- NotTerminating
# ...ここでは、以下のようになります。
pods- 終了状態ではない Pod の総数を指定します。
limits.cpu- 非終端状態にあるすべての Pod において、CPU 制限の合計がこの値を超えてはならないことを指定します。
limits.memory- 非終端状態にあるすべての Pod において、メモリー制限の合計がこの値を超えてはならないことを指定します。
limits.ephemeral-storage- 非終端状態にあるすべての Pod において、一時ストレージ制限の合計がこの値を超えてはならないことを指定します。
scopes-
spec.activeDeadlineSecondsがnilに設定されている Pod のみに一致するクォータの制限を指定します。ビルド Pod は、RestartNeverポリシーが適用されない限りNotTerminatingになります。
compute-resources-time-bound.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources-time-bound
spec:
hard:
pods: "2"
limits.cpu: "1"
limits.memory: "1Gi"
limits.ephemeral-storage: "1Gi"
scopes:
- Terminating
# ...ここでは、以下のようになります。
pods- 終了状態ではない Pod の総数を指定します。
limits.cpu- 非終端状態にあるすべての Pod において、CPU 制限の合計がこの値を超えてはならないことを指定します。
limits.memory- 非終端状態にあるすべての Pod において、メモリー制限の合計がこの値を超えてはならないことを指定します。
limits.ephemeral-storage- 非終端状態にあるすべての Pod において、一時ストレージ制限の合計がこの値を超えてはならないことを指定します。
scopes-
spec.activeDeadlineSeconds>=0の Pod のみに一致するクォータの制限を指定します。たとえば、このクォータではビルド Pod に対して課金されますが、Web サーバーやデータベースなどの長時間実行される Pod に対しては課金されません。
storage-consumption.yaml の例
apiVersion: v1
kind: ResourceQuota
metadata:
name: storage-consumption
spec:
hard:
persistentvolumeclaims: "10"
requests.storage: "50Gi"
gold.storageclass.storage.k8s.io/requests.storage: "10Gi"
silver.storageclass.storage.k8s.io/requests.storage: "20Gi"
silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5"
bronze.storageclass.storage.k8s.io/requests.storage: "0"
bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"
# ...ここでは、以下のようになります。
persistentvolumeclaims- プロジェクト内の PVC の総数を指定します。
requests.storage- プロジェクト内のすべての PVC において、要求されるストレージの合計がこの値を超えてはならないことを指定します。
gold.storageclass.storage.k8s.io/requests.storage- プロジェクト内のすべての PVC において、ゴールドストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。
silver.storageclass.storage.k8s.io/requests.storage- プロジェクト内のすべての PVC において、シルバーストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。
silver.storageclass.storage.k8s.io/persistentvolumeclaims- プロジェクト内の PVC 全体で、銀保管クラスにおける請求の総数がこの値を超えてはならないことを指定します。
bronze.storageclass.storage.k8s.io/requests.storage-
プロジェクト内のすべての PVC において、ブロンズストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。この値を
0に設定すると、ブロンズストレージクラスはストレージを要求できなくなります。 bronze.storageclass.storage.k8s.io/persistentvolumeclaims-
プロジェクト内のすべての PVC において、ブロンズストレージクラスで要求されるストレージの合計がこの値を超えてはならないことを指定します。この値を
0に設定すると、ブロンズストレージクラスはクレームを作成できません。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}