第8章 Ingress Controller エンドポイント公開戦略の設定
8.1. Ingress Controller エンドポイントの公開ストラテジー
NodePortService エンドポイントの公開ストラテジー
NodePortService エンドポイントの公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress Controller を公開します。
この設定では、Ingress Controller のデプロイメントはコンテナーのネットワークを使用します。NodePortService はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理される NodePortService のノードポートフィールドへの変更が保持されます。
図8.1 NodePortService の図
前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。
- クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
-
たとえば、クライアントが図中の IP アドレス
10.0.128.4に接続してダウンしているノードに接続した場合に、ノードポートは、サービスを実行中で利用可能なノードにクライアントを直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、10.0.128.4アドレスがダウンしており、代わりに別の IP アドレスを使用する必要があります。
Ingress Operator は、サービスの .spec.ports[].nodePort フィールドへの更新を無視します。
デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、マネージドのサービスリソースを直接更新できます。
詳細は、NodePort についての Kubernetes サービスについてのドキュメント を参照してください。
HostNetwork エンドポイントの公開ストラテジー
HostNetwork エンドポイントの公開ストラテジーは、Ingress Controller がデプロイされるノードポートで Ingress Controller を公開します。
HostNetwork エンドポイント公開ストラテジーを持つ Ingress Controller には、ノードごとに単一の Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80 および 443 を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。
8.1.1. Ingress Controller エンドポイント公開スコープの内部への設定
クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeがExternalに設定されたデフォルトの Ingress Controller が作成されます。クラスター管理者は、External スコープの Ingress Controller をInternalに変更できます。
前提条件
-
ocCLI をインストールしていること。
手順
Externalスコープの Ingress Controller をInternalに変更するには、次のコマンドを入力します。$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"Internal"}}}}'Ingress Controller のステータスを確認するには、次のコマンドを入力します。
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
ステータス状態が
Progressingの場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。$ oc -n openshift-ingress delete services/router-default
サービスを削除すると、Ingress Operator はサービスを
Internalとして再作成します。
8.1.2. Ingress Controller エンドポイント公開スコープの外部への設定
クラスター管理者がクラスターをプライベートに指定せずに新しいクラスターをインストールすると、scopeがExternalに設定されたデフォルトの Ingress Controller が作成されます。
Ingress Controller のスコープは、インストール中またはインストール後にInternalになるように設定でき、クラスター管理者はInternal の Ingress Controller をExternalに変更できます。
一部のプラットフォームでは、サービスを削除して再作成する必要があります。
スコープを変更すると、場合によっては数分間、Ingress トラフィックが中断される可能性があります。これが該当するのは、サービスを削除して再作成する必要があるプラットフォームです。理由は、この手順により、OpenShift Container Platform が既存のサービスロードバランサーのプロビジョニングを解除して新しいサービスロードバランサーをプロビジョニングし、DNS を更新する可能性があるためです。
前提条件
-
ocCLI をインストールしていること。
手順
Internalスコープの入力コントローラーをExternalに変更するには、次のコマンドを入力します。$ oc -n openshift-ingress-operator patch ingresscontrollers/private --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"type":"LoadBalancerService","loadBalancer":{"scope":"External"}}}}'Ingress Controller のステータスを確認するには、次のコマンドを入力します。
$ oc -n openshift-ingress-operator get ingresscontrollers/default -o yaml
ステータス状態が
Progressingの場合は、さらにアクションを実行する必要があるかどうかを示します。たとえば、ステータスの状態によっては、次のコマンドを入力して、サービスを削除する必要があることを示している可能性があります。$ oc -n openshift-ingress delete services/router-default
サービスを削除すると、Ingress Operator はサービスを
Externalとして再作成します。
