複数のアベイラビリティーゾーンの Kubernetes クラスター管理

最も高い稼働時間の要件を必要とする組織には、アベイラビリティーゾーン (AZ) 全体の喪失といった重大な障害に対する耐性が必要です。複数の AZ にまたがる Kubernetes クラスターのプロビジョニングはマネージドクラウドプロバイダーのわかりやすいタスクですが、ArcGIS Enterprise on Kubernetes ソフトウェアのデプロイメント、構成、操作フェーズ中に考慮しなければならない追加の管理要件があります。

次のセクションでは、検討すべき注意事項、組織を構成する前に満たしておくべき要件、AZ 内での機能の喪失による予想される影響、その AZ 内の機能を回復した後に管理者が基本となるシステムの健全性を確認する方法について説明します。

アプリケーションがデプロイされる Kubernetes クラスターは少なくとも、次の要件を満たしている必要があります。

ワーカーノードグループが 3 つ以上の AZ にまたがっている。
ワーカーノードのキャパシティーが停電時にすべてのワークロードを 2 つの AZ に再調整するのに十分である。

デプロイメントと構成

ArcGIS Enterprise on Kubernetes を複数の AZ クラスターにデプロイする場合、ステートフルワークロードの存在は、ブロックストレージデバイスを使用した場合に関連付けられたディスクの AZ 依存関係があることを意味します。

各 statefulset の関連付けられたレプリカが適切なトポロジー全体にまたがるようにするために、新しいプロパティ (K8S_AVAILABILITY_TOPOLOGY_KEY) がデプロイメントプロパティファイルに導入されました。これは、デプロイメントスクリプトを実行する前に更新する必要があります。このプロパティを kubernetes.io/hostname 以外の値に更新すると、topologySpreadConstraint 仕様が statefulset に導入されます。これにより、調整が不均一であったり、1 つの AZ に複数のレプリカが含まれたりすることがなくなります。ほとんどのクラウドプロバイダーの AZ ノードラベルキーは topology.kubernetes.io/zone です。

組織の構成時に、最も高い可用性を確保するには、強化された高い可用性アーキテクチャープロファイルを使用して組織を構成します。これは、AZ の障害時にすべてのステートフルワークロードに対して適切なカバレッジを保証する唯一のプロファイルです。

強化された高い可用性アーキテクチャープロファイルを使用した場合でも、デプロイメントは特定の組織の要件によって大きく異なるため、1 つのレプリカに残るデプロイメントが多数あります。ダウンタイムをさらに短縮するために、1 つのレプリカ上で次のデプロイメントを検討してください。

enterprise-manager
enterprise-web-style-app
enterprise-help
service-lifecycle-manager
featureserver-webhook-processor
gpserver-webhook-processor

リストされたすべてのデプロイメントの追加レプリカに対するスケーリングでは、名前空間のリクエストと制限に追加の CPU とメモリーが追加されます。総増加量は、追加のポッドレプリカ数や各ポッドに設定されたリクエストと制限によって異なります。各パフォーマンスプロファイルによって設定されるデフォルトのリクエストと制限については、「パフォーマンスプロファイル」をご参照ください。

サービスを公開するとき、スケジュールの再設定中に中断がないようにするため、最低 2 つ以上のポッドを実行するようにすべての専用サービスを設定します。共有インスタンスデプロイメントも、同じ目的で少なくとも 2 つのレプリカにスケール処理します。

AZ 喪失の影響

AZ 喪失の意味と影響は、影響を受けるクラウドサービスによって異なります。特定のサービス (計算やストレージなど) の喪失は実行しているワークロードに大きな影響をおよぼす可能性があり、他のネットワークベースの障害 (DNS 解決や遅延の急激な増加など) はマイクロサービスが相互に通信できる方法に影響する可能性があります。

リレーショナルストアのフェイルオーバー時には、特定の機能 (サインイン、ホストフィーチャサービスの編集、ホストレイヤーの読み込みなど) が短時間だけ低下することがあります。スタンバイインスタンスがプライマリーへの昇格を終了したら、すべての組織の機能が安定した状態に戻ります。

組織の健全性の確認

管理者は、統合されたヘルスチェックレポートを使用して、サイトの組織の健全性を評価できます。ポッドの起動での問題や生じる可能性があるその他の課題について、名前区間のワークロードを確認することもできます。

AZ 喪失中

PV のブロックストレージを使用しているときに AZ が失われた場合、ボリュームのアフィニティ要件により、statefulset ポッドを他の AZ にスケジュール変更できません。

このスケジュール変更を必要とするデータストアの場合、クォーラムが維持されるので、関連するサービスは劣化した状態で機能できます。リレーショナルストアは、他のいくつかのサービスが依存しているコアコンポーネントであるため、管理 API を使用してスタンバイをリセットすることができます。このとき、statefulset と関連する PVC が削除され、新しいステートフルセットが作成されます。これにより、スタンバイインスタンスは、残りの AZ のいずれかに移動した後でプライマリーと再同期することができます。

AZ 喪失後

障害が発生した AZ にサービスが復元された場合、保留状態にあった関連するワークロードが再開されます。これは、Kubernetes API を使用して確認できます。