71- 第16章：OpenShiftの管理と監視-1：リソース要求と制限の説明

type

status

date

slug

summary

category

icon

password

第16章: OpenShiftコンテナープラットフォームの管理と監視

目標: OpenShiftのリソースとソフトウェアを管理および監視する。

目的:

アプリケーションによるリソース消費量を制限する。

OpenShiftのインスタンスをアップグレードする方法を説明する。

アプリケーションのヘルスを監視するためにプローブを設定する。

ウェブコンソールから取得したデータを使用してOpenShiftリソースを監視する。

セクション:

リソース使用の制限（およびガイド付き演習）

OpenShiftコンテナープラットフォームのアップグレード（およびクイズ）

プローブを使用したアプリケーションの監視（およびガイド付き演習）

ウェブコンソールを使用したリソースの監視

ラボ: OpenShiftの管理と監視

リソース使用の制限

目標

このセクションを完了した後、学生はアプリケーションが消費するリソースを制限する方法を理解できるようになります。

ポッドのリソース要求と制限

ポッド定義には、リソース要求とリソース制限の両方を含めることができます。

リソース要求

スケジューリングに使用され、ポッドが指定された量の計算リソース以上で動作できないことを示します。スケジューラーは、ポッドの要求を満たすのに十分な計算リソースを持つノードを探そうとします。

リソース制限

ポッドがノードのすべての計算リソースを使い果たさないようにするために使用されます。ポッドを実行するノードは、Linuxカーネルのcgroups機能を設定して、ポッドのリソース制限を強制します。

リソース要求とリソース制限はポッド定義の一部ですが、通常はデプロイメント設定で設定されます。OpenShiftの推奨プラクティスでは、ポッドは単独で作成すべきではなく、デプロイメント設定によって作成されるべきであるとされています。

クォータの適用

OpenShift Container Platformは、2種類のリソースの使用を追跡して制限するクォータを適用できます。

オブジェクト数

ポッド、サービス、ルートなどのKubernetesリソースの数。

計算リソース

CPU、メモリ、ストレージ容量などの物理的または仮想的なハードウェアリソースの数。

Kubernetesリソース数にクォータを設定することで、OpenShiftマスターの安定性を保つのに役立ちます。これは、マスターデータストア（Etcdデータベース）の無制限な成長を避けるためです。Kubernetesリソースにクォータを設定することは、サービスのIPアドレスなど、他の限られたソフトウェアリソースの枯渇を防ぐことにもなります。

同様に、計算リソースの量にクォータを設定することで、OpenShiftクラスタ内の単一ノードの計算能力を使い果たさないようにします。また、クラスタ全体のリソースを1つのアプリケーションがすべて使ってしまい、他のアプリケーションがリソース不足に陥ることを防ぎます。

OpenShiftは、クラスタ内のオブジェクトと計算リソースの使用に対して、ResourceQuotaオブジェクト、または単にクォータを使用して管理します。ResourceQuotaオブジェクトは、プロジェクトのハードリソース使用制限を指定します。クォータのすべての属性はオプションであり、クォータで制限されていないリソースは無制限に消費できます。

注意

1つのプロジェクトには複数のResourceQuotaオブジェクトを含めることができます。その効果は累積的ですが、同じプロジェクト内で異なるResourceQuotaオブジェクトが同じ種類のKubernetesリソースや計算リソースの使用を制限しないようにすることが期待されています。

以下の表は、ResourceQuota によって強制される可能性のあるいくつかのオブジェクト数制限を説明しています。

オブジェクト数の名前	説明
pods	ポッドの総数
replicationcontrollers	レプリケーションコントローラーの総数
services	サービスの総数
secrets	シークレットの総数
persistentvolumeclaims	永続ボリューム要求の総数

以下の表は、ResourceQuota によって強制される可能性のあるいくつかの計算リソース制限を説明しています。

計算リソースの名前	説明
cpu	すべてのコンテナで使用される総CPU
memory	すべてのコンテナで使用される総メモリ
storage	すべてのコンテナで使用される総ディスク容量

注意

リソースクォータの属性の完全なリストと各属性の意味については、Red Hat OpenShift Container Platform 3.9 クラスター管理者および開発者ガイドのドキュメントを参照してください。

クォータの属性は、プロジェクト内のすべてのポッドに対するリソース要求（requests）またはリソース制限（limits）を追跡できます。デフォルトでは、クォータの属性はリソース要求を追跡します。リソース制限を追跡したい場合は、計算リソース名の前に「limits」を追加します。例えば、limits.cpu などです。

以下に、オブジェクト数と計算リソースの両方のクォータを指定した ResourceQuota リソースの YAML 構文を示します：

リソース単位は、ポッドのリソース要求やリソース制限と同じです。例えば、Gi は GiB（ギガバイト）、m はミリコアを意味します。

リソースクォータは、他の OpenShift Container Platform リソースと同じ方法で作成できます。つまり、JSON または YAML のリソース定義ファイルを oc create コマンドで渡して作成します：

リソースクォータを作成する別の方法は、oc create quota コマンドを使用することです。例えば、次のように指定できます：

oc get resourcequota コマンドを使用して、利用可能なクォータのリストを表示できます。また、oc describe resourcequota NAME コマンドを使用して、クォータで定義された制限に関連する使用状況の統計を表示できます。例えば：

oc describe resourcequota コマンドを引数なしで実行すると、プロジェクト内のすべての ResourceQuota オブジェクトの累積制限が表示され、どのオブジェクトがどの制限を定義しているかは表示されません。

アクティブなクォータは、oc delete resourcequota NAME コマンドを使用して名前で削除できます：

プロジェクト内でクォータが最初に作成されると、クォータの制約に違反する新しいリソースの作成が制限されますが、使用状況統計が更新されると、新しいリソースを作成できるようになります。新しいリソースが作成されると、クォータ使用量は即座に増加します。リソースが削除されると、次回プロジェクトのクォータ統計が完全に再計算される際に、クォータ使用量は減少します。

重要

ResourceQuota の制約はプロジェクト全体に適用されますが、ビルドやデプロイメントなどの多くの OpenShift プロセスはプロジェクト内でポッドを作成します。これらは、プロジェクトのクォータを超えると失敗する可能性があります。

LimitRange の適用

LimitRange リソース（または単にリミット）は、プロジェクト内の ポッド や コンテナ に対する計算リソースのリクエストや制限に関する デフォルト値、最小値、および 最大値 を定義します。ポッドのリソースリクエストや制限は、そのポッド内の すべてのコンテナ の合計として計算されます。

リミットレンジとリソースクォータの違い

リミットレンジ は、 単一のポッド に対して有効な範囲やデフォルト値を定義します。

リソースクォータ は、 プロジェクト内のすべてのポッド の合計に対する上限を定義します。

リソース使用に関して懸念があるクラスター管理者は、通常 リミット と クォータ の両方を設定します。

リミットレンジで定義できるリソース

リミットレンジは、以下のようなリソースに対しても デフォルト値、最小値、最大値 を定義できます：

コンテナ の CPU やメモリ

ポッド の CPU やメモリ

イメージ のストレージ容量

永続ボリュームクレーム (PVC) のストレージ容量

LimitRangeの動作

プロジェクトにリソースが追加された場合、計算リソースのリクエスト が設定されていない場合、そのリソースはプロジェクトのリミットレンジに基づいて デフォルト値 を適用します。

リクエストや制限がリミットレンジで指定された 最小値 より小さい場合、そのリソースは作成されません。

リクエストや制限がリミットレンジで指定された 最大値 より大きい場合、そのリソースも作成されません。

LimitRangeの例

以下は、リミットレンジを YAML構文 で定義した例です：

LimitRangeの作成

LimitRangeリソースは、他のOpenShiftリソースと同じように作成できます。以下のコマンドで作成可能です：

Red Hat OpenShift Container Platform 3.9 には、リソース制限を設定するための oc create コマンドがありません。その代わりに、YAML ファイルを使用する必要があります。プロジェクトに適用されているリミット制約を表示するには、oc describe limitranges NAME コマンドを使用します。また、oc get limits コマンドを使用しても同様の出力が得られます。

アクティブなリミットレンジは、oc delete limitranges NAME コマンドを使用して名前で削除できます：

リミットレンジがプロジェクトに作成されると、すべてのリソース作成リクエストは、プロジェクト内の各 LimitRange リソースに対して評価されます。新しいリソースが LimitRange によって指定された最小または最大制約を違反する場合、そのリソースは拒否されます。新しいリソースが明示的な値を設定していない場合、制約がデフォルト値をサポートしていれば、そのデフォルト値が適用されます。

すべてのリソース更新リクエストもプロジェクト内の各 LimitRange リソースに対して評価されます。更新されたリソースが制約に違反する場合、その更新は拒否されます。

重要

リミットレンジの制約を過度に高く設定したり、リソースクォータの制約を過度に低く設定したりしないようにしてください。リミットレンジの制約に違反すると、ポッドが作成されず、明確なエラーメッセージが表示されます。リソースクォータの制約に違反すると、ポッドがノードにスケジュールされない場合があります。ポッドは作成されても、保留状態のままであることがあります。