第28章 Out of Resource (リソース不足) エラーの処理

このトピックでは、OpenShift Container Platform がメモリー不足 (OOM) やディスク領域不足の状況を防ぐためのベストエフォートの取り組みについて説明します。

ノードは、利用可能なコンピュートリソースが少ない場合に安定性を維持する必要があります。これは、メモリーやディスクなどの圧縮不可能なリソースを扱う場合にとくに重要になります。どちらかのリソースが消費されると、ノードは不安定になります。

管理者は、エビクションポリシーを使用してノードをプロアクティブにモニターし、ノードでコンピュートリソースおよびメモリーリソースが不足する状況を防ぐことができます。

このトピックでは、OpenShift Container Platform がリソース不足の状況に対処する方法についての情報を提供し、シナリオ例や推奨される対策について説明します。

エビクションポリシー により、ノードが利用可能なリソースが少ない状況で実行されている場合に 1 つ以上の Pod が失敗することを許可します。Pod の失敗により、ノードは必要なリソースを回収できます。

エビクションポリシーは、エビクションシグナルと、ノード設定ファイルまたはコマンドラインで設定される特定のエビクションしきい値の組み合わせです。エビクションは、 ノードがしきい値を超える Pod に対して即時のアクションを実行するハードエビクションか、またはノードがアクションを実行する前の猶予期間を許可するソフトエビクションのどちらかになります。

適切に設定されたエビクションポリシーを使用することで、ノードは、プロアクティブにモニターし、コンピュートリソースを完全に使い切る事態を防ぐことができます。

ノードは、以下のようにディスクの不足状態を検出する際に nodefs および imagefs ファイルシステムのパーティションをサポートします。

nodefs または rootfs は、ノードがローカルディスクボリューム、デーモンログ、emptyDir など (/ を指定するファイルシステムなど) に使用するファイルシステムです。rootfs には、openshift.local.volumes (デフォルトは /var/lib/origin/openshift.local.volumes) が含まれます。

imagefs は、コンテナーランタイムがイメージおよび個別のコンテナーの書き込み可能な層を保存するために使用するファイルシステムです。エビクションのしきい値は、imagefs については 85% になります。imagefs ファイルシステムはランタイムによって異なり、Docker の場合は使用しているストレージドライバーに応じます。

kubeletArguments:
  eviction-hard: 1
  - memory.available<500Mi2
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi

kubeletArguments:
  eviction-soft: 1
  - memory.available<500Mi 2
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi
  eviction-soft-grace-period:3
  - memory.available=1m30s
  - nodefs.available=1m30s
  - nodefs.inodesFree=1m30s
  - imagefs.available=1m30s
  - imagefs.inodesFree=1m30s

curl <certificate details> \
  https://<master>/api/v1/nodes/<node>/proxy/stats/summary

<eviction_signal><operator><quantity>

memory.available<1Gi
memory.available<10%

kubeletArguments:
  eviction-hard:
  - memory.available<500Mi
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi

...
kubeletArguments:
  eviction-hard:
  - memory.available<100Mi
  - nodefs.available<10%
  - nodefs.inodesFree<5%
  - imagefs.available<15%
...

kubeletArguments:
  eviction-soft:
  - memory.available<500Mi
  - nodefs.available<500Mi
  - nodefs.inodesFree<100Mi
  - imagefs.available<100Mi
  - imagefs.inodesFree<100Mi
  eviction-soft-grace-period:
  - memory.available=1m30s
  - nodefs.available=1m30s
  - nodefs.inodesFree=1m30s
  - imagefs.available=1m30s
  - imagefs.inodesFree=1m30s

スケジューラーがノードを完全に割り当て、エビクションを防止できるようにするために、スケジューリングで利用できるノードリソースの数量を制御できます。

system-reserved を、Pod のデプロイおよび system-daemon 用にスケジューラーで利用可能にするリソース量と等しくなるようにします。エビクションは、Pod が割り当て可能なリソースの要求量よりも多くのリソースを使用する場合に生じます。

ノードは 2 つの値を報告します。

割り当て可能なリソースの量を設定するには、以下を実行します。

ノードがソフトエビクトしきい値の上下で変動しているものの、関連付けられた猶予期間を超えていない場合、対応するノード状態は true と false の間で変動します。これにより、スケジュールの問題が生じる場合があります。

この変動を防ぐには、eviction-pressure-transition-period パラメーターを設定して、ノードが不足状態からの切り換え前に待機する期間を制御します。

kubeletArguments:
  eviction-pressure-transition-period="5m"

+ ノードは、指定期間の指定された不足状態についてエビクションしきい値に達していないことを確認する場合に状態を false に戻します。

+

エビクション条件が満たされる場合、ノードはシグナルが定義されたしきい値を下回るまで、不足状態にあるリソースを回収するプロセスを実行します。このプロセスでは、ノードはいずれの新規 Pod のスケジューリングもサポートしません。

ノードは、ホストシステムにコンテナーランタイム用の専用 imagefs が設定されているかどうかに基づいて、エンドユーザー Pod のエビクト前にノードレベルのリソース回収を試行します。

Imagefs が設定されている場合

ホストシステムに imagefs が設定されている場合:

Imagefs が設定されていない場合

ホストシステムに imagefs がされていない場合:

エビクションしきい値に達し、猶予期間を経過している場合、ノードはシグナルが定義されたしきい値を下回るまで Pod のエビクトのプロセスを実行します。

ノードは、エビクトする Pod を QoS (Quality of Service) に基づいてランク付けし、同じQoS レベルにある Pod については Pod のスケジューリング要求との関連で不足状態のリソースの消費量に基づいてランク付けします。

それぞれの QoS レベルには OOM スコープが設定されており、Linux out-of-memory ツール (OOM killer) はこのスコープを使用して強制終了する Pod を判別します。以下の「QoS および Out of Memory Killer について」を参照してください。

以下の表には、各 QoS レベルと関連付けられた OOM スコアが一覧表示されています。

Guaranteed Pod は、(ノード、docker、journald などの) システムデーモンが システム予約か、または kube 予約 の割り当てを使用して予約されている量よりも多くのリソースを消費しているか、またはノードに Guaranteed Pod のみが残っているのでない限り、別の Pod のリソース消費が原因でエビクトされることはありません。

ノードに Guaranteed Pod のみが残っている場合、ノードはノードの安定性に最も影響の少ない Guaranteed Pod をエビクトし、他の Guaranteed Pod に対する予想外の消費による影響を制限します。

ローカルディスクは BestEffort リソースです。必要な場合は、ノードは DiskPressure の発生時にディスクを回収するため、Pod を 1 度に 1 つずつエビクトします。ノードは QoS に基づいて Pod をランク付けします。ノードが inode の不足状態に対応している場合、ノードは QoS の最も低いレベルにある Pod を最初にエビクトして inode を回収します。ノードが利用可能なディスクの不足状態に対応している場合は、ノードはローカルディスクを最も多く消費する QoS 内の Pod をランク付けし、それらの Pod を最初にエビクトします。

% of node memory a container is using + `oom_score_adj` = `oom_score`

スケジューラーは、追加の Pod をノードに配置する際にノードの状態を表示します。たとえば、ノードに以下のようなエビクションのしきい値がある場合は、以下のようになります。

eviction-hard is "memory.available<500Mi"

さらに利用可能なメモリーが 500Mi を下回る場合、ノードは Node.Status.Conditions の MemoryPressure の値を true として報告します。

以下のシナリオについて考えてみましょう。

オペレーター:

この設定から、system-reserved にはエビクションのしきい値でカバーされるメモリー量が含まれていることを読み取ることができます。

この容量に達するのは、一部の Pod による使用がその要求を超えるか、またはシステムによる使用が 1Gi を超える場合のいずれかになります。

ノードに 10 Gi の容量があり、システムデーモン (system-reserved) 用に 10% の容量を予約する必要がある場合、以下の計算を実行します。

capacity = 10 Gi
system-reserved = 10 Gi * .1 = 1 Gi

割り当て可能なリソースの量は以下のようになります。

allocatable = capacity - system-reserved = 9 Gi

これは、デフォルトでスケジューラーはノードに対し、9 Gi のメモリーを要求する Pod をスケジュールすることを意味します。

エビクションをオンに設定して、エビクションのトリガーが利用可能なメモリーが 30 秒間で 10% の容量を下回ることをノードで確認される場合や、5% の容量を下回る場合には即時にトリガーされるようにする必要がある場合、スケジューラーで 8Gi が割り当て可能であることを確認できる必要があります。そのため、システム予約ではエビクションしきい値の大きい方の値がカバーされている必要があります。

capacity = 10 Gi
eviction-threshold = 10 Gi * .1 = 1 Gi
system-reserved = (10Gi * .1) + eviction-threshold = 2 Gi
allocatable = capacity - system-reserved = 8 Gi

以下を適切なノード設定マップに追加します。

kubeletArguments:
  system-reserved:
  - "memory=2Gi"
  eviction-hard:
  - "memory.available<.5Gi"
  eviction-soft:
  - "memory.available<1Gi"
  eviction-soft-grace-period:
  - "memory.available=30s"

この設定により、スケジューラーは Pod が設定される要求を下回る量のメモリーを使用することを前提とし、メモリー不足を即時に発生させ、エビクションをトリガーする Pod をノードに配置しないようにします。