ArcGIS Enterprise on Kubernetes のシステム要件と前提条件を理解するには、Kubernetes の概念とアーキテクチャについて熟知する必要があります。 以下では、このドキュメントで使用される一般的な用語について説明します。
クラスター
クラスターは、コンテナー化されたアプリケーションを連携して実行するワーカー ノードのセットです。 Kubernetes クラスターは、ArcGIS Enterprise on Kubernetes をデプロイメントする上での前提条件です。
ノード
ノードは、ハードウェアの一連の最小要件によって規定されている仮想または物理コンピューターです。 デプロイメントに必要なノードの数は、デプロイメント時に選択されたアーキテクチャ プロファイルに応じて異なります。 デプロイメントに必要な最小ノード数を決定するには、システム要件をご確認ください。
名前空間
名前空間は、Kubernetes クラスター内のオブジェクトを整理するために使用します。 クラスターには 1 つ以上の名前空間を含めることができ、それぞれの名前空間には一意の名前が付けられます。 名前空間を削除すると、それに含まれるすべてのオブジェクトが削除されます。 名前空間は、ArcGIS Enterprise on Kubernetes をデプロイメントする上での前提条件です。
ロール ベース アクセス制御 (RBAC)
ロール ベース アクセス制御 (RBAC) は、クラスター内部でのリソースの権限を管理するために使用します。
リソース クォータ
リソース クォータは、指定された名前空間内で CPU やメモリなどのリソース制限を管理するために使用します。
シークレット
シークレットは、パスワード、トークン、キーなどの機密性の高い情報を名前空間に格納して管理するために使用します。
ポッド
ポッドは、Kubernetes クラスター内の最小単位です。 ポッドは 1 つのコンテナー (状況によってはコンテナーのセット) を抽象化したものです。 クラスター内のポッドごとに、内部で使用可能な一意の IP アドレスが割り当てられます。
配置
デプロイメントは、指定された一連のポッド、ReplicaSets、およびサービスのグループ化を意味し、これらが連携して機能することで、コンテナー化されたアプリケーションを実行します。 デプロイメントではポッドのセットに対する更新が管理され、リソース制限の最適化によるポッドのスケーリングや更新が可能になっています。 ArcGIS Enterprise on Kubernetes では、ArcGIS Enterprise Manager または ArcGIS Enterprise Administrator API からデプロイメントを管理します。 ArcGIS Enterprise on Kubernetes では、管理者が GIS サービスおよびアプリをデプロイメントとして管理します。
ReplicaSet
デプロイメントでは、指定されたレプリカのセットが既定のポッドに対して実行されることを保証するために ReplicaSet を利用します。 ReplicaSet では、必要に応じてポッドを作成または削除することで、デプロイメントを通じて指定された必要なレプリカ数を満たします。 ReplicaSets はステートレスです。
StatefulSets
StatefulSets は、同じ仕様のセットを使用して作成されたポッドの管理に使用します。 StatefulSets では、それぞれのデプロイメント内でポッドごとに一意の ID を維持することで、ポッドが一意であり、永続的なストレージ ボリュームに適切に割り当てられることを確実にします。 StatefulSets はステートフルです。
サービス
サービスは、ポッドのセットをグループ化し、必要に応じてそれらのポッドへのアクセスを提供するために使用します。 サービスでは、ポッドのグループに単一のドメイン名システム (DNS) 名を使用して、内部のネットワーク トラフィックを一連のポッドに向けて送信することで、ワークロードを管理し、ポッド間の通信を可能にします。 サービスは、関連するポッドによる接続および認識が可能な静的 IP アドレスによって定義されます。
サービスとポッドのライフサイクルは独立しています。つまり、ポッドは、終了した後に新しいポッドに置き換えることができます。 これが行われた場合、サービスはそれに応じて新しい IP アドレスを認識します。
サービスの利用により、ワークロード用に指定された現在のポッドのセットに向けて確実にネットワーク トラフィックを送信できるようになります。
Ingress
Ingress は、外部トラフィックをクラスターにルーティングするために使用します。 また、クラスター内のサービスに対して追加の負荷分散機能を提供するためにも使用できます。
永続ボリューム
永続ボリュームは、データおよびシステム リソースのストレージとしての用途でクラスターで利用できるリソースです。 クラスター内のコンテナーとポッドは永続ボリューム クレームを使用して永続ボリュームにアクセスします。 永続ボリュームに関連する情報には次のようなものがあります。
- 管理者は、Kubernetes クラスターから、クラウド ストレージやネットワーク ファイル システム (NFS) などの物理ストレージへの接続を確立できます。
- 永続ボリュームはポッドのライフサイクルに依存しません。
- 永続ボリュームは特定のノードではなく、クラスター全体に関連付けられます。
- 永続ボリュームは、名前空間の外部に存在し、クラスター全体に対するストレージを提供します。
永続ボリュームは、管理者が一連のプロパティとして定義します。 ファイル内で必須の仕様は、物理ストレージのタイプに応じて異なります。 永続ボリュームは、デプロイメント前に静的にプロビジョニングできます。 また、ストレージ クラスが使用されている場合は、デプロイメント時に動的にプロビジョニングすることもできます。
永続ボリュームの詳細については、「システム要件」をご確認ください。
ストレージ クラス
ストレージ クラスは、使用可能なストレージ タイプの属性を記述するものです。 ストレージ クラスは、永続ボリュームが動的にプロビジョニングされるときに使用されます。 ストレージ クラスは一連のプロパティとして指定され、プロビジョナーの属性を使用して指定されます。 各物理ストレージ プロバイダーにはプロビジョナーが含まれます。
永続ボリューム クレーム
永続ボリューム クレームは、ポッドにリソースを提供するように永続ボリュームに要求、つまり「クレーム」します。 ポッドが永続ボリューム クレームを使用してストレージをクレームし、次に、永続ボリューム クレームがストレージ クラスを使用してストレージを要求します。 永続ボリューム クレームは名前空間内部に存在します。 永続ストレージは、構成ファイルやログ、メンバーのコンテンツなど、保存されたデータの管理に使用されます。
ポッド間の通信
ポッドは仮想ネットワーク内のサービスを介して相互に通信します。 個々のポッドには、サービスがポッドのライフサイクル全体を通して認識する IP アドレスが割り当てられます。 ポッドが、含まれるコンテナー内のアプリケーションに障害が発生したなどが原因で終了すると、その代わりとして、交換ポッドおよび関連する IP アドレスが作成されます。
トポロジ拡散の制限
topologySpreadConstraint はプロパティで、ポッド テンプレートに適用でき、クラスターのトポロジ間でどのようにスケジュール設定が行われるかを制御します。 トポロジ ドメインは、それぞれの固有値が同じラベル キーに割り当てられることで定義されます。 topologySpreadConstraint により、トポロジ ドメイン間にわたって、定義済みの maxSkew プロパティに従い、均等な分散が保証されます。 maxSkew が 1 に設定されているなら、トポロジ ドメインごとのポッド数は、他のドメインよりレプリカ数が最大で 1 つまでしか多く、または少なくできないため、3 つのトポロジ ドメインを使用しているなら、スケジューラは 3 つのドメインのそれぞれについて 0、1、2 個のレプリカを許可せず、代わりに 1、1、1 個としてスケジュールします。