ポッドの配置
Kubernetes では、新しく作成されたポッドとスケジュールされていないポッドは、要件を満たすノードに自動的にスケジュールされます。 クラスター内に異なるタイプのノードがある場合、ポッドがスケジュールされるノードを制御することが重要になることがあります。 ポッドの配置を制御する 4 つのツールが用意されています:
ノード ラベルはノードに適用され、そのノードに関する情報を指定します。 ラベルには、キーまたはキー/値のペアを使用できます。
ノード アフィニティーはポッドに適用され、指定されたラベルが付いたノード上でポッドが実行されるようにします。
テイントはノードに適用され、ポッドがそのノードにスケジュールされないようにします。
トライレイションはポッドに適用され、指定されたテイントをポッドが無視できるようにします。
ノード ラベル、ノード アフィニティー、テイント、トライレイションの詳細については、Kubernetes のドキュメントをご参照ください。 ArcGIS Enterprise on Kubernetes におけるポッドへのノード アフィニティーとトライレイションの適用については、「ポッドの配置の管理」をご参照ください。
メリット
ノード ラベルとノード アフィニティーによって、ポッドが適切なノードにスケジュールされるようになります。 テイントとトライレイションによって、適切なポッドだけがノードにスケジュールされるようになります。 これらを組み合わせて使用することで、分離の強化、リソース割り当ての最適化を行い、Kubernetes クラスター内のコンプライアンス要件を効果的に満たすことができます:
特殊な要件によるワークロードの分離 - ラベルとノードのアフィニティ ルールを使用して、特定のポッドが専用ノードにスケジュールされるようにします。 テイントを使用して、CPU やメモリーの要件が高いなどの特定の特性を持つノードを、ArcGIS ワークロード専用としてマークします。 サービス ポッドにトライレイションを適用して、必要なリソースを持つノードにスケジュールされるようにします。
リソースの割り当ての最適化 - リソースのオーバーロードを防ぐためにリソースが制限されているノードにテイントを適用し、これらのノードのリソース制約に一致するようにサービス ポッドにトライレイションを定義します。 ノードのアフィニティをテイントおよびトライレイションと組み合わせて、サービス ポッドがリソース要件を満たすノードにのみスケジュールされるようにします。
ジオロケーションベースのスケジュール設定 - データの場所や特定の規制への準拠が必要なアプリケーションの場合は、ノードのアフィニティを使用して、ノードの地理的な場所に基づいてサービス ポッドをスケジュールします。 物理的な場所やデータ主権の規制に基づいてノードをテイントし、サービス ポッドにトライレイションを適用して、ノード上でスケジュールされ、必要な場所の制約に準拠するようにします。
自動スケーリングは、ワークロードの需要に基づいてポッドの数を動的に調整することで、ノードのアフィニティとトライレイションの使用を強化します。 この動的スケーリングにより、特定の要件を満たすノードや必要なリソースが利用できるノードにポッドが効率的にスケジュールされ、リソースの割り当てが最適化されます。 自動スケーリングをノード アフィニティーおよびトライレイションと組み合わせることで、Kubernetes クラスターは、ノードの制約と設定に準拠しながらワークロードの変動に適応し、リソースの使用率、パフォーマンス、スケーラビリティーの向上を実現します。 自動スケーリングについての詳細は「サービスのスケーリング」をご参照ください。
ポッドの配置の管理
ノード アフィニティーの前にノード ラベルを適用することをおすすめします。 これによって、ノードにまだ対応するラベルがないことが原因でポッドが保留状態になるのを防ぎます。 同様に、トライレイションを適用してから、ノードにテイントを適用することをおすすめします。 これにより、一致するトライレイションがないポッドを誤って除外したことで、サービスが中断してしまうことを回避できます。
多くの環境では、ノード プールまたはノード グループを使用してワークロードをグループ化できます。 個別ノードではなくノードのグループにラベルおよびテイントを適用することをおすすめします。
ArcGIS Enterprise on Kubernetes では、ArcGIS Enterprise Manager を使用して以下のデプロイメントのノード アフィニティーとトライレイションを設定できます:
ノード アフィニティーの構成
ノード アフィニティー ルールを構成するには、以下の値を設定します:
Type - ノード アフィニティのタイプ。 次のタイプを使用できます。
Preferred (
PreferredDuringSchedulingIgnoredDuringExecution) - ポッドは、ルールを満たすノードに優先的にスケジュールされます。Required (
RequiredDuringSchedulingIgnoredDuringExecution) - ポッドは、ルールを満たすノードにスケジュールされなければなりません。
Key - ルールが一致する必要があるノード ラベルまたはアノテーションのキー。
Operator - ルールのオペレーター。 次のオペレーターを使用できます。
In - ノード ラベルまたはアノテーションは、指定された値のリストに含まれている必要があります。
Not in - ノード ラベルまたはアノテーションは、指定された値のリストに含まれてはなりません。
Exists - ノードには指定されたラベルまたはアノテーションが必要です。
Does not exist - ノードには指定されたラベルまたはアノテーションがあってはなりません。
Value - ノード ラベルまたはアノテーションと一致する値のリスト。 Exists または Does not exist オペレーターが選択されている場合は使用できません。
トライレイションの構成
トライレイションを構成するには、以下の値を設定します:
Effect - トライレイションが一致する必要があるテイントの効果。 次の効果を使用できます。
No schedule - 一致するトライレイションがないと、新しいポッドはテイントされたノードにスケジュールされません。
Prefer no schedule - 新しいポッドは、一致するトライレイションのないテイント ノードにスケジュールされることを回避しようとしますが、保証はされません。
No Execute - 一致するトライレイションのないポッドはすべて、ノードにテイントが設定された直後に除外されます。 一致するトライレイションがないと、新しいポッドは、テイントが設定されたノードにスケジュールされません。
Key - トライレイションが一致する必要のあるテイントのキー。
Operator - 容認に使用するオペレーター。 次のオペレーターを使用できます。
Equal - ポッドは指定されたキーと値を持つテイントを許容します。
Exists - ポッドは指定されたキーを持つテイントを許容します。
Value - 演算子が Equal と設定されている場合、トライレイションが一致する必要のあるテイントの値。 Exists オペレーターが選択されている場合は使用できません。
注意:
GPU 対応ノードを実行する必要があるラスター解析およびノートブック サービスのワークロードでは、所定のノード アフィニティー設定とトライレイション設定が必要です。 これらの設定の詳細については、ラスター解析ワークロードの場合は「GPU 対応ノードの構成」、ノートブック サービス ワークロードの場合は「ランタイムの表示および編集」をご参照ください。
シナリオ
サービス上のポッド配置の管理が組織にどのようなメリットをもたらすかをより深く理解するには、次のシナリオを確認してください。
シナリオ 1 - パブリック マッピング サービスでの季節的なトラフィックの急増
ある公共団体は、地元の祭りの期間中、トラフィックの大幅な増加を経験します。 イベント情報を得ようと Web マップにアクセスするユーザーは、基になるマップ サービスへの需要が高いため、遅延に遭遇します。 これに対処するため、組織管理者は以下を行います。
CPU リソースとメモリー リソースが多いノードにキー/値ラベル high-performance: true を追加します。
CPU リソースとメモリー リソースが多いノードへのマップ サービス ポッドを優先的にスケジュールするノード アフィニティー ルールを適用します。 これにより、マップ サービスはトラフィックの急増に対応できるようになります:
Type - Preferred
Key - high-performance
Operator - Exists
Value - true
重要なマップ サービスのポッドにトライレンションを適用して、高パフォーマンス ワークロード用にテイントが適用されたノードにスケジュールできるようにします。
Effect - NoSchedule
Key - workload
Operator - Equal
Value - high-performance
workload=high-performance:NoSchedule を使用して高パフォーマンス ノードをテイントすることで、対応するトライレイションがない重要度が低いポッドがそのノードにスケジュールされないようにします。 これにより、高パフォーマンス ノードにイベント関連サービスのポッドをスケジュールする余地ができます。
シナリオ 2 - 環境モニタリングのためのデータ処理
環境局は、土地利用の変化を監視するために一連の地理空間解析を行っています。 この解析は膨大な計算リソースを要し、当局はこの目的のために GPU を備えた専用ノードを用意しています。 他のサービスとリソースを競合せずに地理空間解析を効果的に実行するため、組織管理者は以下を行います。
GPU 対応ノードにキー/値ラベル gpu: true を追加します。
GPU ノードにのみ解析ポッドをスケジュールするノード アフィニティー ルールを適用します:
Type - Required
Key - gpu
Operator - In
Value - true
解析ポッドにトライレイションを適用して、テイントが適用された GPU ノードにスケジュールできるようにします:
Effect - NoSchedule
Key - workload
Operator - Equal
Value - high-resource
workload=high-resource:NoSchedule を使用して GPU ノードをテイントすることで、対応するトライレイションがない、リソースをあまり消費しないポッドがそのノードにスケジュールされないようにします。 これにより、高価な GPU 対応コンピューターはこれを必要とする解析ポッドにのみ使用されるようになります。
シナリオ 3 - 共有フィーチャ サービスのためのリソースの最適化
市の GIS 部門には、頻繁に使用されるわけではないものの、総じて単一サービスの実施に負荷をかけるフィーチャ サービスが多数あります。 クラスターには、サービス品質が保証されたプレミアム ノード (優先度が高いサービス用) とリソース可用性が低いノード (優先度が低いサービス用) が含まれています。 これらの優先度が低いフィーチャ サービスがより低コストなノードに優先的にスケジュールされるようにするため、組織管理者は以下を実行します:
キー resource-constrained を使用して、リソース可用性が低いノードを構成します。
リソース可用性が低いノードに優先的にスケジュールするノード アフィニティー ルールをフィーチャ サービス ポッドに適用します。
Type - Preferred
Key - resource-constrained
Operator - DoesNotExist
フィーチャ サービス ポッドにトライレイションを適用して、制約にかかわらず、テイントされたノードにスケジュールできるようにします:
Effect - PreferNoSchedule
Key - resource-constrained
Operator - Exists
resource-constrained:PreferNoSchedule を使用してリソース可用性が低いノードをテイントします。
シナリオ 4 - クラスター スケーリング中のデータ ストアの中断の回避
政府のサービス利用パターンでは、日中にサービスが集中して使用されます。 このパターンでは、これらのサービスに必要なすべてのポッド レプリカをサポートするために、多数のクラスター ノードが必要となります。 サービスは夜間には使用されないため、組織ではクラウド コンピューティングのコストを削減するため、ノード数を縮小したいと考えています。 しかし、ステートフルなシステム管理のデータ ストア ポッドが実行されているノードを終了すると、ArcGIS Enterprise が中断するリスクが生じます。 このような潜在的な中断を回避するため、組織管理者は以下のことを行います:
別のノード グループを作成します。
このグループ内の各ノードにキー/値ラベル data-store: true を追加します。
ノード アフィニティーのルールを適用し、データ ストアのポッドがこのグループのノードにスケジュールされるようにします。
Type - Required
Key - data-store
Operator - In
Value - true
ステートフルなデータ ストア ポッドにトライレイションを適用して、テイントされたデータ ストア ノード上で実行できるようにします:
Effect - NoSchedule
Key - workload
Operator - Equal
Value - data-store
workload=data-store:NoSchedule を使用してデータ ストア ノードをテイントすることで、対応するトライレイションがないステートレスなポッドがそのノードにスケジュールされないようにします。 これにより、データ ストア ノードにすべてのステートフルなデータ ストア ポッドをスケジュールする余地ができます。
夜間にクラスター ノードをスケール ダウンする際、データ ストア ノード グループをスケール ダウンしません。 ステートフルなデータ ストア ポッドはすべてこのノード グループに属しているため、他のノード グループのスケール ダウンの影響を受けません。