62- 第14章：アプリケーションデプロイメントの管理-3：ポッドスケジューリング制御の説明

type

status

date

slug

summary

ポッドスケジューリングの制御

目的

このセクションを完了すると、学生はポッドがクラスター内でどのようにスケジューリングされるかを説明し、制御できるようになります。

OpenShiftスケジューラーアルゴリズムの紹介

ポッドスケジューラーは、新しいポッドをOpenShiftクラスターのノードに配置する場所を決定します。これは非常に設定可能で、さまざまなクラスターに適応できるように設計されています。Red Hat OpenShift Container Platform 3.9に付属するデフォルトの設定は、ノードのラベル、アフィニティルール、およびアンチアフィニティルールを使用して、ゾーンやリージョンといったデータセンターの一般的な概念をサポートします。

以前のRed Hat OpenShift Container Platformのリリースでは、インストーラーがマスターホストを「スケジュール不可」とマークして新しいポッドを配置できないようにしていました。しかし、Red Hat OpenShift Container Platform 3.9のリリースでは、マスターがインストールおよびアップグレード時に自動的に「スケジュール可能」とマークされます。これにより、Webコンソールがマスターのコンポーネントとしてではなく、マスターにデプロイされたポッドとして実行できるようになりました。

インストールおよびアップグレード時に、デフォルトのノードセレクターが設定されます。このセレクターは、osm_default_node_selector Ansible変数を使用して上書きしない限り、node-role.kubernetes.io/compute=true に設定されます。

インストールおよびアップグレード中に、インベントリファイルで定義されたホストに次の自動ラベリングが行われます。osm_default_node_selector設定に関係なく、以下のようにラベル付けされます：

コンピュートノード役割は、マスターでなく、専用インフラストラクチャノードのホスト（デフォルトでは、region=infra ラベルが付けられたノード）にnode-role.kubernetes.io/compute=true ラベルが付けられます。

マスターノードはnode-role.kubernetes.io/master=true ラベルが付けられ、マスターノード役割が割り当てられます。

OpenShiftのポッドスケジューラーアルゴリズムは、次の3段階のプロセスを実行します：

1. ノードのフィルタリング

スケジューラーは、ノードのリソース（ホストポートなど）の可用性に基づいて実行中のノードのリストをフィルタリングします。フィルタリングは、ノードセレクターやポッドのリソース要求を考慮して続行されます。最終的に、ポッドを実行する候補ノードのリストが短縮されます。

ポッドは、クラスター内のノードラベルに一致するノードセレクターを定義できます。ラベルが一致しないノードは対象外となります。

ポッドは、CPU、メモリ、ストレージなどの計算リソースに対するリソース要求を定義することもできます。リソースが不足しているノードは対象外となります。

2. フィルタリングされたノードリストの優先順位付け

候補ノードのリストは、複数の優先順位基準を使用して評価され、重み付けされたスコアが加算されます。スコアが高いノードが、ポッドを実行する最適な候補と見なされます。

アフィニティおよびアンチアフィニティルールも基準に含まれます。ポッドとのアフィニティが高いノードはスコアが高く、アンチアフィニティが高いノードはスコアが低くなります。

アフィニティルールの一般的な使用例は、パフォーマンス向上のために関連するポッドを近くにスケジュールすることです。例えば、同期を取る必要があるポッドを同じネットワークバックボーン上に配置することが挙げられます。

アンチアフィニティルールの一般的な使用例は、高可用性のために関連するポッドを互いに遠くにスケジュールすることです。例えば、すべてのポッドを同じノードにスケジュールしないようにすることです。

3. 最適なノードの選択

候補ノードのリストは、スコアに基づいて並べ替えられ、スコアが最も高いノードがポッドをホストするために選ばれます。複数のノードが同じ高スコアを持っている場合、その中からランダムに1つが選ばれます。

スケジューラー設定ファイル（/etc/origin/master/scheduler.json）には、フィルタリングまたは優先順位付けの関数として使用される一連の述語が定義されています。このようにして、スケジューラーは異なるクラスターのトポロジーをサポートするように構成できます。

スケジューリングとトポロジー

大規模データセンター（クラウドプロバイダーなど）の一般的なトポロジーは、ホストをリージョンとゾーンに分けることです：

リージョンは、地理的に近いホストのセットであり、それらの間に高速な接続を保証します。

ゾーン（別名アベイラビリティゾーン）は、共通の重要なインフラストラクチャコンポーネント（ネットワーク、ストレージ、電力など）を共有するため、同時に故障する可能性があるホストのセットです。

OpenShiftのポッドスケジューラーの標準設定は、リージョンおよびゾーンのラベルに基づいた述語を定義することによって、この種のクラスタートポロジーをサポートします。述語は次のように定義されています：

同じレプリカポッド（同じレプリケーションコントローラーまたはデプロイメント設定から作成されたポッド）は、同じリージョンラベルの値を持つノードにスケジュールされます。

レプリカポッドは、異なるゾーンラベルの値を持つノードにスケジュールされます。

下の図は、複数のリージョン、各リージョンに複数のゾーンがあり、各ゾーンに複数のノードがあるサンプルトポロジーを示しています。

サンプルのトポロジーを実装するには、クラスター管理者として oc label コマンドを使用します。例えば、以下のように実行します：

重要なこと

各ノードは完全修飾名（FQDN）で識別する必要があります。上記のコマンドは簡略化のために短縮名を使用しています。

region ラベルを変更するには -overwrite オプションが必要です。なぜなら、Red Hat OpenShift Container Platform 3.9 の高度なインストール方法では、ノードにデフォルトで region=infra ラベルが設定されるからです。

ノードに設定されているラベルを確認するには、oc get node コマンドに --showlabels オプションを付けて実行します：

注意： OpenShiftによってノードにいくつかのデフォルトラベルが自動的に付与されます。kubernetes.io サフィックスが含まれるラベルは、スケジューラによって内部的に使用されるため、クラスター管理者が変更すべきではありません。

クラスター管理者はまた、-L オプションを使って単一のラベルの値を確認できます。例えば：

複数の -L オプションを同時に使用することもできます。例えば：

スケジューリングできないノード

時々、クラスター管理者はノードをメンテナンスのために停止する必要があります。ノードがハードウェアのアップグレードやカーネルのセキュリティ更新を必要とする場合です。この場合、OpenShift クラスターのユーザーに最小限の影響を与えるため、管理者は次の二段階のプロセスを実行するべきです：

ノードをスケジューリング不可にする

これにより、スケジューラは新しいポッドをそのノードに割り当てなくなります。

ノードをスケジューリング不可にするには、oc adm manage-node コマンドを使用します：

ノードをドレインする

これにより、そのノード上で実行中のすべてのポッドが削除され、残りの利用可能なノードでポッドが再作成されます。ドレイン操作を行うには、oc adm drain コマンドを使用します：

メンテナンスが完了したら、oc adm manage-node コマンドでノードを再びスケジューリング可能に設定します：

ポッドの配置を制御する

一部のアプリケーションは、特定のノードセット上で実行する必要があります。例えば、特定のノードは特定の種類のワークロードに対してハードウェア加速を提供するか、またはクラスター管理者が本番アプリケーションと開発アプリケーションを混ぜたくない場合です。これらのニーズに対応するために、ノードラベルとノードセレクターを使用します。

ノードセレクターはポッド定義の一部ですが、推奨される方法はポッド定義を変更するのではなく、デプロイメント構成を変更することです。ノードセレクターを追加するには、oc edit コマンドまたは oc patch コマンドを使用します。例えば、myapp デプロイメント構成を変更して、ポッドが env=qa ラベルを持つノードでのみ実行されるようにするには、次のコマンドを使用します：

この変更により、新しいデプロイメントがトリガーされ、新しいポッドは新しいノードセレクターに従ってスケジュールされます。

もしクラスター管理者が開発者にポッドのノードセレクターを制御させたくない場合、プロジェクトリソースにデフォルトのノードセレクターを設定するべきです。

デフォルトプロジェクトの管理

本番環境では、OpenShift インフラストラクチャポッド（ルーターや内部レジストリなど）を実行するために、特定のノードセットを専用にすることが一般的です。これらのポッドは default プロジェクトに定義されています。

この実装方法は、次の二段階から成ります：

専用ノードに region=infra ラベルを付ける。

default 名前空間にデフォルトのノードセレクターを設定する。

プロジェクトにデフォルトのノードセレクターを設定するには、openshift.io/node-selector キーを使用して名前空間リソースにアノテーションを追加します。これには、oc edit コマンドまたは oc annotate コマンドを使用できます。次の例では、oc annotate コマンドを使用しています：

Red Hat OpenShift Container Platform 3.9 のクイックインストーラーおよび高度なインストーラーの Ansible プレイブックでは、インストール時にノードに割り当てられるラベルや、各インフラポッドに割り当てられるノードセレクターを制御するための Ansible 変数をサポートしています。メトリクスサブシステムなどのサブシステムをインストールするプレイブックも、これらのサブシステムのノードセレクター用の変数をサポートしています。詳細については、製品ドキュメントを参照してください。