第14章 クォータおよび制限範囲
14.1. 概要
クォータおよび制限範囲を使用して、クラスター管理者はプロジェクトで使用されるオブジェクトの数やコンピュートリソースの量を制限するための制約を設定することができます。これは、管理者がすべてのプロジェクトでリソースの効果的な管理および割り当てを実行し、いずれのプロジェクトでの使用量がクラスターサイズに対して適切な量を超えることのないようにするのに役立ちます。
開発者は Pod およびコンテナーのレベルでコンピュートリソースの要求および制限を設定することもできます。
以下のセクションは、クォータおよび制限範囲の設定を確認し、それらの制約対象や、独自の Pod およびコンテナーでコンピュートリソースを要求し、制限する方法について理解するのに役立ちます。
14.2. クォータ
ResourceQuota オブジェクトで定義されるリソースクォータは、プロジェクトごとにリソース消費量の総計を制限する制約を指定します。これは、タイプ別にプロジェクトで作成できるオブジェクトの数量を制限すると共に、そのプロジェクトのリソースが消費できるコンピュートリソースおよびストレージの合計量を制限することができます。
クォータはクラスター管理者によって設定され、所定プロジェクトにスコープが設定されます。
14.2.1. クォータの表示
web コンソールでプロジェクトの Quota ページに移動し、プロジェクトのクォータで定義されるハード制限に関連する使用状況の統計を表示できます。
CLI を使用してクォータの詳細を表示することもできます。
最初に、プロジェクトで定義されたクォータの一覧を取得します。たとえば、demoproject というプロジェクトの場合、以下を実行します。
$ oc get quota -n demoproject NAME AGE besteffort 11m compute-resources 2m core-object-counts 29m
次に、関連するクォータについて記述します。たとえば、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
詳細のクォータ定義は、オブジェクトで oc get --export を実行して表示できます。以下は、クォータ定義のサンプルを示しています。
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
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
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
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 ストレージクラスでは要求を作成できないことを意味します。
14.2.2. クォータで管理されるリソース
以下では、クォータで管理できる一連のコンピュートリソースとオブジェクトタイプについて説明します。
status.phase in (Failed, Succeeded) が true の場合、Pod は終了状態にあります。
表14.1 クォータで管理されるコンピュートリソース
| リソース名 | 説明 |
|---|---|
|
|
非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません |
|
|
非終了状態のすべての pod におけるローカルの一時ストレージ要求の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod での CPU 要求の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod でのメモリー要求の合計はこの値を超えることができません |
|
|
非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod での CPU 制限の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod でのメモリー制限の合計はこの値を超えることができません。 |
|
|
非終了状態のすべての Pod における一時ストレージ要求の合計はこの値を超えることができません。このリソースは、一時ストレージのテクノロジープレビュー機能が有効にされている場合にのみ利用できます。この機能はデフォルトでは無効になっています。 |
表14.2 クォータで管理されるストレージリソース
| リソース名 | 説明 |
|---|---|
|
|
任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。 |
|
|
プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。 |
|
|
一致するストレージクラスを持つ、任意の状態のすべての Persistent Volume Claim (永続ボリューム要求、PVC) でのストレージ要求の合計はこの値を超えることができません。 |
|
|
プロジェクトに存在できる、一致するストレージクラスを持つ Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。 |
表14.3 クォータで管理されるオブジェクト数
| リソース名 | 説明 |
|---|---|
|
|
プロジェクトに存在できる非終了状態の Pod の合計数です。 |
|
|
プロジェクトに存在できるレプリケーションコントローラーの合計数です。 |
|
|
プロジェクトに存在できるリソースクォータの合計数です。 |
|
|
プロジェクトに存在できるサービスの合計数です。 |
|
|
プロジェクトに存在できるシークレットの合計数です。 |
|
|
プロジェクトに存在できる |
|
|
プロジェクトに存在できる Persistent Volume Claim (永続ボリューム要求、PVC) の合計数です。 |
|
|
プロジェクトに存在できるイメージストリームの合計数です。 |
14.2.3. クォータのスコープ
各クォータには スコープ のセットが関連付けられます。クォータは、列挙されたスコープの交差部分に一致する場合にのみリソースの使用状況を測定します。
スコープをクォータに追加すると、クォータが適用されるリソースのセットを制限できます。許可されるセット以外のリソースを設定すると、検証エラーが発生します。
| スコープ | 説明 |
|---|---|
|
Terminating |
|
|
NotTerminating |
|
|
BestEffort |
|
|
NotBestEffort |
|
BestEffort スコープは、以下のリソースを制限するようにクォータを制限します。
-
pods
Terminating、NotTerminating、および NotBestEffort スコープは、以下のリソースを追跡するようにクォータを制限します。
-
pods -
memory -
requests.memory -
limits.memory -
cpu -
requests.cpu -
limits.cpu -
ephemeral-storage -
requests.ephemeral-storage -
limits.ephemeral-storage
一時ストレージ要求と制限は、テクノロジープレビューとして提供されている一時ストレージを有効にした場合にのみ適用されます。この機能はデフォルトでは無効になっています。
14.2.4. クォータの実施
プロジェクトのリソースクォータが最初に作成されると、プロジェクトは、更新された使用状況の統計が計算されるまでクォータ制約の違反を引き起こす可能性のある新規リソースの作成機能を制限します。
クォータが作成され、使用状況の統計が更新されると、プロジェクトは新規コンテンツの作成を許可します。リソースを作成または変更する場合、クォータの使用量はリソースの作成または変更要求があるとすぐに増分します。
リソースを削除する場合、クォータの使用量は、プロジェクトのクォータ統計の次回の完全な再計算時に減分されます。プロジェクトの変更がクォータ使用制限を超える場合、サーバーはこのアクションを拒否し、クォータ制約を違反していること、およびシステムで現在確認される使用量の統計値を示す適切なエラーメッセージが返されます。
14.2.5. 要求 vs 制限
コンピュートリソースの割り当て時に、各コンテナーは CPU、メモリー、一時ストレージそれぞれに要求値と制限値を指定できます。クォータはこれらの値のいずれも制限できます。
クォータに requests.cpu または requests.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースを明示的に要求することが求められます。クォータに limits.cpu または limits.memory の値が指定されている場合、すべての着信コンテナーがそれらのリソースの明示的な制限を指定することが求められます。
Pod およびコンテナーに要求および制限を設定する方法についての詳細は、「コンピュートリソース」を参照してください。
14.3. 制限範囲
LimitRange オブジェクトで定義される制限範囲は、Pod、コンテナー、イメージ、イメージストリーム、および Persistent Volume Claim (永続ボリューム要求、PVC) のレベルでプロジェクトのコンピュートリソース制約を列挙し、Pod、コンテナー、イメージ、イメージストリームまたは Persistent Volume Claim (永続ボリューム要求、PVC) で消費できるリソースの量を指定します。
すべてのリソース作成および変更要求は、プロジェクトの各 LimitRange オブジェクトに対して評価されます。リソースが列挙される制約に違反する場合、そのリソースは拒否されます。リソースが明示的な値を指定しない場合で、制約がデフォルト値をサポートする場合は、デフォルト値がリソースに適用されます。
CPU とメモリーの制限について、最大値を指定しても最小値を指定しない場合、リソースは最大値よりも多くの CPU とメモリーリソースを消費する可能性があります。
一時ストレージのテクノロジープレビューを使用して一時ストレージの制限と要求を指定できます。この機能は、デフォルトでは無効になっています。この機能を有効にするには、「configuring for ephemeral storage」を参照してください。
制限範囲はクラスター管理者によって設定され、所定プロジェクトにスコープが設定されます。
14.3.1. 制限範囲の表示
Web コンソールでプロジェクトの Quota ページに移動し、プロジェクトで定義される制限範囲を表示できます。
以下の手順を実行して、CLI を使用して制限範囲の詳細を表示することもできます。
プロジェクトで定義される制限範囲オブジェクトの一覧を取得します。たとえば、demoproject というプロジェクトの場合は以下のようになります。
$ oc get limits -n demoproject
Example Output
NAME AGE resource-limits 6d
制限範囲を記述します。たとえば、resource-limits 制限範囲の場合は以下のようになります。
$ oc describe limits resource-limits -n demoproject
Example Output
Name: resource-limits Namespace: demoproject Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Pod cpu 200m 2 - - - Pod memory 6Mi 1Gi - - - Container cpu 100m 2 200m 300m 10 Container memory 4Mi 1Gi 100Mi 200Mi - openshift.io/Image storage - 1Gi - - - openshift.io/ImageStream openshift.io/image - 12 - - - openshift.io/ImageStream openshift.io/image-tags - 10 - - -
詳細の制限範囲の定義は、オブジェクトで oc get --export を実行して表示できます。以下は、制限範囲の定義例を示しています。
コア 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値を設定しないか、または0を設定する場合は無制限となり、Pod はmax値を超える量を消費できます。 - 5
- すべてのコンテナーにおいて Pod がノードで要求できるメモリーの最小量です。
min値を設定しないか、または0を設定する場合は無制限となり、Pod はmax値を超える量を消費できます。 - 6
- Pod の単一コンテナーが要求できる CPU の最大量です。
- 7
- Pod の単一コンテナーが要求できるメモリーの最大量です。
- 8
- Pod の単一コンテナーが要求できる CPU の最小量です。
min値を設定しないか、またはminを0に設定する場合は無制限となり、Pod はmax値を超える量を消費できます。 - 9
- Pod の単一コンテナーが要求できるメモリーの最小量です。
min値を設定しないか、またはminを0に設定する場合は無制限となり、Pod はmax値を超える量を消費できます。 - 10
- Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトの CPU 制限。
- 11
- Pod 仕様で制限を指定しない場合の、コンテナーのデフォルトのメモリー制限。
- 12
- Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトの CPU 要求。
- 13
- Pod 仕様で要求を指定しない場合の、コンテナーのデフォルトのメモリー要求。
- 14
- コンテナーの最大制限対要求比率。
CPU およびメモリーの測定方法についての詳細は、「コンピュートリソース」を参照してください。
14.3.2. コンテナーの制限
サポートされるリソース:
- CPU
- メモリー
サポートされる制約:
コンテナーごとに設定されます。指定される場合、以下を満たしている必要があります。
表14.4 コンテナー
| 制約 | 動作 |
|---|---|
|
|
設定で |
|
|
設定で |
|
|
設定で
たとえば、コンテナーの |
サポートされるデフォルト:
Default[resource]-
指定がない場合は
container.resources.limit[resource]を所定の値にデフォルト設定します。 Default Requests[resource]-
指定がない場合は、
container.resources.requests[resource]を所定の値にデフォルト設定します。
14.3.3. Pod の制限
サポートされるリソース:
- CPU
- メモリー
サポートされる制約:
Pod のすべてのコンテナーにおいて、以下を満たしている必要があります。
表14.5 Pod
| 制約 | 実施される動作 |
|---|---|
|
|
|
|
|
|
|
|
|
14.4. コンピュートリソース
ノードで実行される各コンテナーはコンピュートリソースを消費します。コンピュートリソースは要求し、割り当て、消費できる数量を測定できるリソースです。
Pod 設定ファイルの作成時に、クラスター内の Pod のスケジューリングを改善し、満足のいくパフォーマンスを確保できるように、各コンテナーが必要とする CPU、メモリー (RAM)、ローカルの一時ストレージ (管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合) をオプションで指定できます。
CPU は millicore という単位で測定されます。クラスター内の各ノードはオペレーティングシステムを検査して、ノード上の CPU コアの量を判別し、その値を 1000 で乗算して合計容量を表します。たとえば、ノードに 2 コアある場合に、ノードの CPU 容量は 2000m として表されます。単一コアの 1/10 を使用する場合には、100m として表されます。
メモリーおよび一時ストレージはバイト単位で測定されます。さらに、これには SI サフィックス (E、P、T、G、M、 K) または、相当する 2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を指定できます。
apiVersion: v1
kind: Pod
spec:
containers:
- image: openshift/hello-openshift
name: hello-openshift
resources:
requests:
cpu: 100m 1
memory: 200Mi 2
ephemeral-storage: 1Gi 3
limits:
cpu: 200m 4
memory: 400Mi 5
ephemeral-storage: 2Gi 614.4.1. CPU 要求
Pod の各コンテナーはノードで要求する CPU の量を指定できます。スケジューラーは CPU 要求を使用してコンテナーに適したノードを検索します。
CPU 要求はコンテナーが消費できる CPU の最小量を表しますが、CPU の競合がない場合、ノード上の利用可能なすべての CPU を使用できます。ノードに CPU の競合がある場合、CPU 要求はシステム上のすべてのコンテナーに対し、コンテナーで使用可能な CPU 時間についての相対的な重みを指定します。
ノード上でこの動作を実施するために CPU 要求がカーネル CFS 共有にマップされます。
14.4.2. コンピュートリソースの表示
Pod のコンピュートリソースを表示するには、以下を実行します。
$ oc describe pod ruby-hello-world-tfjxt
Name: ruby-hello-world-tfjxt
Namespace: default
Image(s): ruby-hello-world
Node: /
Labels: run=ruby-hello-world
Status: Pending
Reason:
Message:
IP:
Replication Controllers: ruby-hello-world (1/1 replicas created)
Containers:
ruby-hello-world:
Container ID:
Image ID:
Image: ruby-hello-world
QoS Tier:
cpu: Burstable
memory: Burstable
Limits:
cpu: 200m
memory: 400Mi
ephemeral-storage: 1Gi
Requests:
cpu: 100m
memory: 200Mi
ephemeral-storage: 2Gi
State: Waiting
Ready: False
Restart Count: 0
Environment Variables:14.4.3. CPU 制限
Pod の各コンテナーはノードで使用を制限する CPU 量を指定できます。CPU 制限はコンテナーがノードの競合の有無とは関係なく使用できる CPU の最大量を制御します。コンテナーが指定の制限を以上を使用しようとする場合には、システムによりコンテナーの使用量が調節されます。これにより、コンテナーがノードにスケジュールされる Pod 数とは関係なく一貫したサービスレベルを維持することができます。
14.4.4. メモリー要求
デフォルトで、コンテナーはノード上の可能な限り多くのメモリーを使用できます。クラスター内での Pod の配置を改善するには、コンテナーの実行に必要なメモリーの量を指定します。スケジューラーは Pod をノードにバインドする前にノードの利用可能なメモリー容量を考慮に入れます。コンテナーは、要求を指定する場合も依然として可能な限り多くのメモリーを消費することができます。
14.4.5. 一時ストレージの要求
以下のトピックは、管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合にのみ該当します。
デフォルトでは、コンテナーは、利用可能な分だけノード上のローカルの一時ストレージを消費できます。クラスターで Pod をより効果的に配置するには、実行するコンテナーに必要なローカルの一時ストレージ量を指定します。スケジューラーは、Pod をノードにバインドする前に、利用可能なノードのローカルストレージの容量を考慮します。コンテナーは、要求の指定時にもノード上のローカル一時ストレージをできる限り消費できます。
14.4.6. メモリー制限
メモリー制限を指定する場合、コンテナーが使用できるメモリーの量を制限できます。たとえば 200Mi の制限を指定する場合、コンテナーの使用はノード上のそのメモリー量に制限されます。コンテナーが指定されるメモリー制限を超える場合、コンテナーは終了します。その後はコンテナーの再起動ポリシーによって再起動する可能性もあります。
14.4.7. 一時ストレージの制限
以下のトピックは、管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合にのみ該当します。
一時ストレージの制限を指定する場合には、コンテナーが使用可能な一時ストレージの量を制限することができます。たとえば、2 Gi の制限を指定した場合には、コンテナーは、ノード上でその分の一時ストレージ量だけに使用が制限されます。コンテナーが指定したメモリー制限を超過した場合には中断し、コンテナーの再起動ポリシーに従って再起動される可能性があります。
14.4.8. QoS (Quality of Service) 層
作成後、コンピュートリソースは quality of service (QoS) で分類されます。これは、リソースごとに指定される要求および制限値に基づいて 3 つの層に分類されます。
| Quality of Service | 説明 |
|---|---|
|
BestEffort |
要求および制限が指定されない場合に指定されます。 |
|
Burstable |
要求がオプションで指定される制限よりも小さい値に指定される場合に指定されます。 |
|
Guaranteed |
制限がオプションで指定される要求に等しい値に指定される場合に指定されます。 |
コンテナーに各コンピュートリソースに異なる QoS を生じさせる要求および制限セットが含まれる場合、これは Burstable として分類されます。
QoS は、リソースが圧縮可能であるかどうかによって各種のリソースにそれぞれ異なる影響を与えます。CPU は圧縮可能なリソースですが、メモリーは圧縮できないリソースです。
- CPU リソースの場合:
- BestEffort CPU コンテナーはノードで利用可能な CPU を消費できますが、最も低い優先順位で実行されます。
- Burstable CPU コンテナーは要求される CPU の最小量を取得することが保証されますが、追加の CPU 時間を取得できる場合もあればできない場合もあります。追加の CPU リソースはノード上のすべてのコンテナーで要求される量に基づいて分配されます。
- Guaranteed CPU コンテナーは、追加の CPU サイクルが利用可能な場合でも要求される量のみを取得することが保証されます。これにより、ノード上の他のアクティビティーとは関係なく一定のパフォーマンスレベルを確保できます。
- メモリーリソースの場合:
- BestEffort メモリー コンテナーはノード上で利用可能なメモリーを消費できますが、スケジューラーがコンテナーを、その必要を満たすのに十分なメモリーを持つノードに配置する保証はありません。さらにノードで OOM (Out of Memory) イベントが発生する場合、BestEffort コンテナーが強制終了される可能性が最も高くなります。
- Burstable メモリー コンテナーは要求されるメモリー量を取得できるようノードにスケジュールされますが、それ以上の量を消費する可能性があります。ノード上で OOM イベントが発生する場合、Burstable コンテナーはメモリー回復の試行時に BestEffort コンテナーの次に強制終了されます。
- Guaranteed メモリー コンテナーは、要求されるメモリー量のみを取得します。OOM イベントが発生する場合は、システム上に他の BestEffort または Burstable コンテナーがない場合にのみ強制終了されます。
14.4.9. CLI でのコンピュートリソースの指定
CLI でコンピュートリソースを指定するには、以下を実行します。
$ oc run ruby-hello-world --image=ruby-hello-world --limits=cpu=200m,memory=400Mi --requests=cpu=100m,memory=200Mi
一時ストレージは、管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合にのみ適用されます。
14.5. プロジェクトごとのリソース制限
クラスター管理者はリソース制限をプロジェクトごとに設定することができます。開発者にはこれらの制限を作成し、編集し、削除することができませんが、アクセス可能なプロジェクトのリソース制限を表示することができます。