2.4. Ingress Controller エンドポイント公開戦略の設定
Ingress Controller のエンドポイントを外部システムに公開し、OpenShift Container Platform でロードバランサーとの統合を有効にするには、endpointPublishingStrategy パラメーターを設定します。
Red Hat OpenStack Platform (RHOSP) では、クラウドプロバイダーがヘルスモニターを作成するように設定されている場合にのみ、LoadBalancerService エンドポイントの公開ストラテジーがサポートされます。RHOSP 16.2 の場合、このストラテジーは Amphora Octavia プロバイダーを使用する場合にのみ可能です。
詳細は、RHOSP インストールドキュメントの「RHOSP Cloud Controller Manager オプションの設定」セクションを参照してください。
2.4.1. Ingress Controller エンドポイントの公開ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で Ingress Controller エンドポイントを外部ネットワークに公開するには、NodePortService エンドポイント公開ストラテジーまたは HostNetwork エンドポイント公開ストラテジーのいずれかを設定します。
NodePortServiceエンドポイント公開ストラテジー-
NodePortServiceエンドポイント公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress Controller を公開します。
この設定では、Ingress Controller のデプロイメントはコンテナーのネットワークを使用します。NodePortService はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理対象の NodePortService のノードポートフィールドへの変更が保持されます。
図2.3 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エンドポイント公開ストラテジーは、Ingress Controller がデプロイされるノードポートで Ingress Controller を公開します。
HostNetwork エンドポイント公開ストラテジーを持つ Ingress Controller には、ノードごとに 1 つの Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80 および 443 を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。
HostNetwork オブジェクトには、オプションのバインディングポートのデフォルト値が httpPort:80、httpsPort:443、statsPort:1936 の hostNetwork フィールドがあります。ネットワークに異なるバインディングポートを指定することで、HostNetwork ストラテジーに対して、同じノードに複数の Ingress Controller をデプロイできます。
例
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
name: internal
namespace: openshift-ingress-operator
spec:
domain: example.com
endpointPublishingStrategy:
type: HostNetwork
hostNetwork:
httpPort: 80
httpsPort: 443
statsPort: 1936
2.4.1.1. Ingress Controller エンドポイント公開スコープの内部への設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者として、クラスターがプライベートであることを指定せずに新しいクラスターをインストールすると、デフォルトの Ingress コントローラーが 外部スコープ に設定された状態で作成されます。外部 スコープのイングレスコントローラーを 内部スコープ に変更できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
外部スコープのイングレスコントローラーを内部スコープに変更するには、次のコマンドを入力します。$ 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として再作成します。
2.4.1.2. Ingress Controller エンドポイント公開スコープの外部への設定 リンクのコピーリンクがクリップボードにコピーされました!
インストール時またはインストール後のタスクとして、クラスター管理者は Ingress Controller を Internal に設定できます。さらに、クラスター管理者は 内部 イングレスコントローラーを 外部イングレス コントローラーに変更できます。
クラスターがプライベートであることを指定せずに新しいクラスターをインストールすると、デフォルトの Ingress コントローラーが スコープ を External に設定して作成されます。
一部のプラットフォームでは、サービスを削除して再作成する必要があります。
スコープを変更すると、場合によっては数分間、Ingress トラフィックが中断される可能性があります。これが該当するのは、サービスを削除して再作成する必要があるプラットフォームです。理由は、この手順により、OpenShift Container Platform が既存のサービスロードバランサーのプロビジョニングを解除して新しいサービスロードバランサーをプロビジョニングし、DNS を更新する可能性があるためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
内部スコープのイングレスコントローラーを外部スコープに変更するには、次のコマンドを入力します。$ 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として再作成します。
2.4.1.3. Ingress Controller への単一の NodePort サービスの追加 リンクのコピーリンクがクリップボードにコピーされました!
ポートの競合を防ぐため、プロジェクトごとに NodePort タイプの サービス を作成する代わりに、NodePortService エンドポイント公開ストラテジーを使用できるカスタム Ingress コントローラーを作成します。
すでに HostNetwork Ingress Controller がインストールされている可能性のあるノードに、Ingress シャーディングを通じて一連のルートを適用したい場合は、Ingress Controller にこの設定を検討してください。
各プロジェクトに NodePort タイプの Service を設定する前に、次の考慮事項を確認してください。
-
NodeportIngress Controller ドメインに対して、ワイルドカード DNS レコードを作成する必要があります。Nodeport Ingress Controller ルートには、ワーカーノードのアドレスからアクセスできます。ルートに必要な DNS レコードの詳細は、「user-provisioned DNS 要件」を参照してください。 -
サービス用のルートを公開し、カスタム Ingress Controller ドメインの
--hostname引数を指定する必要があります。 -
アプリケーション Pod にアクセスできるようにするには、
NodePortタイプのServiceに割り当てられているポートをルートに追加する必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - ワイルドカード DNS レコードが作成されている。
手順
Ingress Controller のカスタムリソース (CR) ファイルを作成します。
IngressControllerオブジェクトの情報を定義する CR ファイルの例apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: <custom_ic_name> namespace: openshift-ingress-operator spec: replicas: 1 domain: <custom_ic_domain_name> nodePlacement: nodeSelector: matchLabels: <key>: <value> namespaceSelector: matchLabels: <key>: <value> endpointPublishingStrategy: type: NodePortService # ...ここでは、以下のようになります。
metadata.name-
IngressControllerCR のカスタム名を指定します。 仕様ドメイン-
Ingress Controller がサービスを提供する DNS 名を指定します。たとえば、デフォルトのイングレスコントローラーのドメインは
apps.ipi-cluster.example.comなので、<custom_ic_domain_name>にはnodeportsvc.ipi-cluster.example.comを指定します。 nodeSelector.matchLabels.<key>- カスタム Ingress コントローラーを含むノードのラベルを指定します。
namespaceSelector.matchLabels.<key>-
一連の名前空間のラベルを指定します。
<key>:<value>は、キーと値のペアのマップに置き換えます。<key>は新しいラベルの一意の名前、<value>はその値です。たとえば、ingresscontroller: custom-icです。
oc label nodeコマンドを使用してノードにラベルを追加します。$ oc label node <node_name> <key>=<value>-
<key>=<value>: ここで、<value> はIngressControllerCR のnodePlacementセクションで指定されたキーと値のペアと一致する必要があります。
-
IngressControllerオブジェクトを作成します。$ oc create -f <ingress_controller_cr>.yamlIngressControllerCR 用に作成されたサービスのポートを確認します。$ oc get svc -n openshift-ingressrouter-nodeport-custom-ic3サービスのポート80:32432/TCPを示す出力例NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-internal-default ClusterIP 172.30.195.74 <none> 80/TCP,443/TCP,1936/TCP 223d router-nodeport-custom-ic3 NodePort 172.30.109.219 <none> 80:32432/TCP,443:31366/TCP,1936:30499/TCP 155m新しいプロジェクトを作成するために、次のコマンドを入力します。
$ oc new-project <project_name>新しい namespace にラベルを付けるために、次のコマンドを入力します。
$ oc label namespace <project_name> <key>=<value>-
<key>=<value>:: ここで、<key>=<value> はIngress Controller CR のnamespaceSelectorセクションの値と一致する必要があります。
-
クラスター内に新しいアプリケーションを作成します。
$ oc new-app --image=<image_name>-
<image_name>:<image_name>の例はquay.io/openshifttest/hello-openshift:multiarchです。
-
サービスの
Routeオブジェクトを作成して、Pod がサービスを使用してアプリケーションをクラスターの外部に公開できるようにします。$ oc expose svc/<service_name> --hostname=<svc_name>-<project_name>.<custom_ic_domain_name>注記--hostname引数で、カスタム Ingress Controller のドメイン名を指定する必要があります。これを行わない場合、Ingress Operator がデフォルトの Ingress Controller を使用してクラスターのすべてのルートを提供します。ルートのステータスが
Admittedであり、カスタム Ingress Controller のメタデータがルートに含まれていることを確認します。$ oc get route/hello-openshift -o json | jq '.status.ingress'出力例
# ... { "conditions": [ { "lastTransitionTime": "2024-05-17T18:25:41Z", "status": "True", "type": "Admitted" } ], [ { "host": "hello-openshift.nodeportsvc.ipi-cluster.example.com", "routerCanonicalHostname": "router-nodeportsvc.nodeportsvc.ipi-cluster.example.com", "routerName": "nodeportsvc", "wildcardPolicy": "None" } ], }デフォルトの
IngressControllerCR を更新して、デフォルトの Ingress Controller がNodePortタイプのServiceを管理しないようにします。他のすべてのクラスタートラフィックは、引き続きデフォルトの Ingress Controller によって監視します。$ oc patch --type=merge -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"namespaceSelector":{"matchExpressions":[{"key":"<key>","operator":"NotIn","values":["<value>]}]}}}'
検証
次のコマンドを入力して、DNS エントリーがクラスターの内外にルーティングできることを確認します。このコマンドでは、上記の手順で
oc label nodeコマンドを実行してラベルを追加したノードの IP アドレスが出力されます。$ dig +short <svc_name>-<project_name>.<custom_ic_domain_name>クラスターが DNS 解決に外部 DNS サーバーの IP アドレスを使用していることを確認するために、次のコマンドを入力してクラスターの接続を確認します。
$ curl <svc_name>-<project_name>.<custom_ic_domain_name>:<port>1 <custom_ic_domain_name>:<port>: ここで、<port>はNodePortタイプのサービスからのノードポートです。oc get svc -n openshift-ingressコマンドの出力例の80:32432/TCPHTTP ルートから、32432がノードポートであることがわかります。出力例
Hello OpenShift!