組織に、ArcGIS Enterprise on Kubernetes デプロイメントにルーティングされるクライアント トラフィックの処理に関する特定の要件がある場合があります。 これらの要件には、Web アプリケーション ファイアウォール機能、パスベースおよびホストベースのルート検索、クライアント リクエスト ヘッダーに基づく他の決定論的なルート検索の動作など、OSI モデルのレイヤー 7 で動作するプロバイダー固有の負荷分散ソリューションが提供する高度な機能を使用する必要があることもあります。
管理者は、クラスターレベルの Ingress コントローラーを使用して、着信トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントにルーティングできます。 これらのクラスターレベルの Ingress コントローラーを使用すると、組織は次の機能を利用できます。 Ingress コントローラーは、それぞれの L7 ロード バランサーの実装で Kubernetes Ingress オブジェクトを機能ルート検索ルールに変換します。 Ingress オブジェクト内の仕様には、Kubernetes 名前空間内の 1 つ以上のバックエンド サービス オブジェクトに対するルート検索のセットが含まれています。
これらの Ingress オブジェクトは、Amazon Elastic Kubernetes Service (EKS)、Microsoft Azure Kubernetes Service (AKS)、Google Kubernetes Engine などのマネージド クラウド プロバイダー上でレイヤー 7 対応のロード バランサーにより最終的に実現されます。 特定のアノテーションおよび ingressClass 名を持つ Ingress オブジェクトを作成すると、フロントエンドとバックエンドのリスナーおよびターゲット グループの設定を含むロード バランサーのプロビジョニングと構成が開始される場合があります。 これらのクラスターレベルの Ingress コントローラーは、クラスターのエッジから内部に公開されたサービスへのトラフィックのルーティングを処理します。
クラスターレベルの Ingress コントローラーを使用して、トラフィックを ArcGIS Enterprise デプロイメントにルーティングする方法の詳細については、以下をご参照ください。
各デプロイメント プラットフォームに対して、Kubernetes Ingress オブジェクトの作成によるレイヤー 7 のロード バランサーの初期デプロイメントと構成を行うことができる YAML データが提供されます。 これらの Ingress オブジェクトに構成を追加して、追加の Ingress オブジェクト アノテーションのアプリケーションなど、組織の目的に合わせて、これらの Ingress オブジェクトに構成を追加できます。 必要な場合は、既存のクラスター内 NGINX Ingress コントローラー サービスにアノテーションを作成することもでき、これらのアノテーションを実行する手順が提供されています。
注意:
一部のプロバイダーでは、新しく作成された Ingress を使用して正しい接続を作成するには、arcgis-ingress-controller デプロイメントを更新する必要があります。 Ingress を作成した後で ArcGIS Enterprise Manager にアクセスしたときにエラーが表示された場合は、次の操作を実行してみてください。
kubectl rollout restart deployment/arcgis-ingress-controller -n <deploymentNamespace>
前提条件
ArcGIS Enterprise on Kubernetes を最初にデプロイしたとき、クラスターレベルの Ingress コントローラーを使用して、トラフィックをデプロイメントにルーティングする必要があります。 この方法は、デプロイメント スクリプトを実行するモードによって異なります。
- サイレント モードでスクリプトを実行している場合、INGRESS_SERVICE_USE_CLUSTER_IP=true を deploy.properties ファイル内に設定する必要があります。 このプロパティは、INGRESS_TYPE パラメーターに設定された値をオーバーライドします。
- インタラクティブ ライブ モードでスクリプトを実行している場合、クラウド バランサーをプロビジョニングするかどうかをたずねられたら no と答え、クラスターレベルの Ingress コントローラーを使用してトラフィックをデプロイメントにルーティングするかどうかをたずねられたら yes と答える必要があります。 これにより、クラスター内 NGINX Ingress コントローラー サービスは ClusterIP タイプとして作成されるようになり、クライアント トラフィックをリクエストされた ArcGIS Enterprise エンドポイントにルーティングできます。
レイヤー 7 ロード バランサーは、クラスター内でサービスへのクライアント トラフィックのアクセス ポイントとして機能します。 ArcGIS Enterprise on Kubernetes の場合、クラスターレベルの Ingress コントローラーを、アプリケーションの一部としてデプロイされた埋め込み Ingress コントローラーにトラフィックを渡すように構成する必要があります。
注意:
ArcGIS Enterprise 11.2 以前では、クラスター Ingress コントローラー サービスを ClusterIP タイプとして作成する機能は、OpenShift Route を使用してトラフィックをデプロイメントにルーティングするかどうかを指定するオプションにより提供されました。 この質問はデプロイメント スクリプト内で変更され、クラスターレベルの Ingress コントローラーを使用してトラフィックをデプロイメントにルーティングするかどうかをたずねます。 このオプションを true に設定すると、デプロイメントの INGRESS_TYPE が NodePort または LoadBalancer に設定されているかどうかに関係なく、Ingress コントローラー サービスは ClusterIP タイプとして作成されます。
一般的な Ingress の要件
このドキュメントで指定されていないプラットフォーム上で Ingress コントローラーを使用できます。 これを行うには、前述の一般的な前提条件も適用されます。 以下も考慮してください。
- トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントにルーティングするよう Ingress オブジェクトを構成している場合、クライアント トラフィックのルーティング先のバックエンド ターゲットとして、クラスター内 arcgis-ingress-nginx サービスを使用します。
- Ingress コントローラーが管理するロード バランサーからバックエンドのクラスター内 NGINX Ingress コントローラーにトラフィックを渡している場合、TLS プロトコルを使用します。
プロバイダー固有ではなく、トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントにルーティングするために必要な値を含んでいる Ingress YAML の単純化した例を次に示します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: arcgis-enterprise-ingress
namespace: <deploymentNamespace>
annotations:
spec:
tls:
- hosts:
- <deploymentFQDN>
secretName: <tlsSecretName>
rules:
- host: <deploymentFQDN>
http:
paths:
- backend:
service:
name: arcgis-ingress-nginx
port:
number: 443
path: /<context>
pathType: Prefix
注意:
上記の例では、証明書情報を含んでいる TLS シークレットがデプロイメント名前区間内に作成され、Ingress コントローラーで TLS 証明書を構成するために使用されます。 一部のプロバイダーでは、アノテーションを使用してこの情報を指定でき、これも使用できます。