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
limits:
cpu: 200m 3
memory: 400Mi 414.4.1. CPU 要求
Pod の各コンテナーはノードで要求する CPU の量を指定できます。スケジューラーは CPU 要求を使用してコンテナーに適したノードを検索します。
CPU 要求はコンテナーが消費できる CPU の最小量を表しますが、CPU の競合がない場合、ノード上の利用可能なすべての CPU を使用できます。ノードに CPU の競合がある場合、CPU 要求はシステム上のすべてのコンテナーに対し、コンテナーで使用可能な CPU 時間についての相対的な重みを指定します。
ノード上でこの動作を実施するために CPU 要求がカーネル CFS 共有にマップされます。
OpenShift Online では、CPU 要求は指定されたメモリー制限に基づいて自動的に設定されます。メモリー制限を指定しないと、60m の CPU 要求が設定されます。
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
Requests:
cpu: 100m
memory: 200Mi
State: Waiting
Ready: False
Restart Count: 0
Environment Variables:14.4.3. CPU 制限
Pod の各コンテナーはノードで使用を制限する CPU 量を指定できます。CPU 制限はコンテナーがノードの競合の有無とは関係なく使用できる CPU の最大量を制御します。コンテナーが指定の制限を以上を使用しようとする場合には、システムによりコンテナーの使用量が調節されます。これにより、コンテナーがノードにスケジュールされる Pod 数とは関係なく一貫したサービスレベルを維持することができます。
OpenShift Online では、CPU 制限は指定されたメモリー制限に基づいて自動的に設定されます。メモリー制限を指定しないと、1 コアの CPU 制限が設定されます。
14.4.4. メモリー要求
デフォルトで、コンテナーはノード上の可能な限り多くのメモリーを使用できます。クラスター内での Pod の配置を改善するには、コンテナーの実行に必要なメモリーの量を指定します。スケジューラーは Pod をノードにバインドする前にノードの利用可能なメモリー容量を考慮に入れます。コンテナーは、要求を指定する場合も依然として可能な限り多くのメモリーを消費することができます。
OpenShift Online では、メモリー要求は指定されたメモリー制限に基づいて自動的に設定されます。メモリー制限を指定しないと、メモリー要求 307Mi が想定されます。
14.4.5. メモリー制限
メモリー制限を指定する場合、コンテナーが使用できるメモリーの量を制限できます。たとえば 200Mi の制限を指定する場合、コンテナーの使用はノード上のそのメモリー量に制限されます。コンテナーが指定されるメモリー制限を超える場合、コンテナーは終了します。 その後はコンテナーの再起動ポリシーによって再起動する可能性もあります。
OpenShift Online では、メモリー要求、CPU 要求、および CPU 制限は自動的に判断され、指定されたメモリー制限に基づいて適切に設定されます。メモリー制限を指定しないと、メモリー制限 512Mi が想定されます。
14.4.6. QoS (Quality of Service) 層
作成後、コンピュートリソースは quality of service (QoS) で分類されます。これは、リソースごとに指定される要求および制限値に基づいて 3 つの層に分類されます。
| QoS (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.7. CLI でのコンピュートリソースの指定
CLI でコンピュートリソースを指定するには、以下を実行します。
$ oc run ruby-hello-world --image=ruby-hello-world --limits=memory=400Mi
