This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.6.8. Ingress Controller の設定
6.8.1. カスタムデフォルト証明書の設定
					管理者として、 Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress Controller がカスタム証明書を使用するように設定できます。
				
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
- 証明書が以下の要件を満たしている必要があります。 - 証明書が Ingress ドメインに対して有効化されている必要があります。
- 
									証明書は拡張を使用して、subjectAltName拡張を使用して、*.apps.ocp4.example.comなどのワイルドカードドメインを指定します。
 
- IngressControllerCR がなければなりません。デフォルトの CR を使用できます。- oc --namespace openshift-ingress-operator get ingresscontrollers - $ oc --namespace openshift-ingress-operator get ingresscontrollers- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME AGE default 10m - NAME AGE default 10m- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
						Intermediate 証明書がある場合、それらはカスタムデフォルト証明書が含まれるシークレットの tls.crt ファイルに組み込まれる必要があります。証明書を指定する際の順序は重要になります。サーバー証明書の後に Intermediate 証明書をリスト表示します。
					
手順
						以下では、カスタム証明書とキーのペアが、現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提とします。tls.crt および tls.key を実際のパス名に置き換えます。さらに、 Secret リソースを作成し、これを IngressController CR で参照する際に、custom-certs-default を別の名前に置き換えます。
					
このアクションにより、Ingress Controller はデプロイメントストラテジーを使用して再デプロイされます。
- tls.crtおよび- tls.keyファイルを使用して、カスタム証明書を含む Secret リソースを- openshift-ingressnamespace に作成します。- oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key - $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- IngressController CR を、新規証明書シークレットを参照するように更新します。 - oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'- $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 更新が正常に行われていることを確認します。 - echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate - $ echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - ここでは、以下のようになります。 - <domain>
- クラスターのベースドメイン名を指定します。
 - 出力例 - subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com notAfter=May 10 08:32:45 2022 GM - subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com notAfter=May 10 08:32:45 2022 GM- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow ヒント- または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。 
IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress Controller のデプロイメントを更新します。
6.8.2. カスタムデフォルト証明書の削除
管理者は、使用する Ingress Controller を設定したカスタム証明書を削除できます。
前提条件
- 
							cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
- 
							OpenShift CLI (oc) がインストールされている。
- Ingress Controller のカスタムデフォルト証明書を設定している。
手順
- カスタム証明書を削除し、OpenShift Container Platform に同梱されている証明書を復元するには、以下のコマンドを入力します。 - oc patch -n openshift-ingress-operator ingresscontrollers/default \ --type json -p $'- op: remove\n path: /spec/defaultCertificate' - $ oc patch -n openshift-ingress-operator ingresscontrollers/default \ --type json -p $'- op: remove\n path: /spec/defaultCertificate'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。 
検証
- 元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。 - echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate - $ echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - ここでは、以下のようになります。 - <domain>
- クラスターのベースドメイン名を指定します。
 - 出力例 - subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT - subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.3. Ingress Controller のスケーリング
					Ingress Controller は、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc コマンドは、IngressController リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController をスケールアップする例を示します。
				
スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。
手順
- デフォルト - IngressControllerの現在の利用可能なレプリカ数を表示します。- oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'- $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - 2 - 2- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- oc patchコマンドを使用して、デフォルトの- IngressControllerを必要なレプリカ数にスケーリングします。以下の例では、デフォルトの- IngressControllerを 3 つのレプリカにスケーリングしています。- oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge- $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - ingresscontroller.operator.openshift.io/default patched - ingresscontroller.operator.openshift.io/default patched- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- デフォルトの - IngressControllerが指定したレプリカ数にスケーリングされていることを確認します。- oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'- $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - 3 - 3- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow ヒント- または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- 異なる数のレプリカが必要な場合はreplicas値を変更します。
 
6.8.4. Ingress アクセスロギングの設定
アクセスログを有効にするように Ingress Controller を設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。
コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress Controller で問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。
アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。
前提条件
- 
							cluster-admin権限を持つユーザーとしてログインしている。
手順
サイドカーへの Ingress アクセスロギングを設定します。
- Ingress アクセスロギングを設定するには、 - spec.logging.access.destinationを使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、- Container- spec.logging.access.destination.typeを指定する必要があります。以下の例は、コンテナー- Containerの宛先に対してログ記録する Ingress Controller 定義です。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Ingress Controller をサイドカーに対してログを記録するように設定すると、Operator は Ingress Controller Pod 内に - logsという名前のコンテナーを作成します。- oc -n openshift-ingress logs deployment.apps/router-default -c logs - $ oc -n openshift-ingress logs deployment.apps/router-default -c logs- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - 2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1" - 2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
Syslog エンドポイントへの Ingress アクセスロギングを設定します。
- Ingress アクセスロギングを設定するには、 - spec.logging.access.destinationを使用して宛先を指定する必要があります。Syslog エンドポイント宛先へのロギングを指定するには、- spec.logging.access.destination.typeに- Syslogを指定する必要があります。宛先タイプが- Syslogの場合、- spec.logging.access.destination.syslog.endpointを使用して宛先エンドポイントも指定する必要があります。また、- spec.logging.access.destination.syslog.facilityを使用してファシリティーを指定できます。以下の例は、- Syslog宛先に対してログを記録する Ingress Controller の定義です。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 注記- syslog宛先ポートは UDP である必要があります。
特定のログ形式で Ingress アクセスロギングを設定します。
- spec.logging.access.httpLogFormatを指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 の- syslogエンドポイントに対してログを記録する Ingress Controller の定義です。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
Ingress アクセスロギングを無効にします。
- Ingress アクセスロギングを無効にするには、 - spec.loggingまたは- spec.logging.accessを空のままにします。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.5. Ingress Controller スレッド数の設定
クラスター管理者は、スレッド数を設定して、クラスターが処理できる受信接続の量を増やすことができます。既存の Ingress Controller にパッチを適用して、スレッドの数を増やすことができます。
前提条件
- 以下では、Ingress Controller がすでに作成されていることを前提とします。
手順
- Ingress Controller を更新して、スレッド数を増やします。 - oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'- $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 注記- 大量のリソースを実行できるノードがある場合、 - spec.nodePlacement.nodeSelectorを、意図されているノードの容量に一致するラベルで設定し、- spec.tuningOptions.threadCountを随時高い値に設定します。
6.8.6. Ingress Controller のシャード化
トラフィックがクラスターに送信される主要なメカニズムとして、Ingress Controller またはルーターへの要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。
- Ingress Controller またはルーターを複数のルートに分散し、変更に対する応答を加速します。
- 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
- 特定の Ingress Controller に異なるポリシーを定義することを許可します。
- 特定のルートのみが追加機能を使用することを許可します。
- たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
Ingress コントローラーは、ルートラベルまたは namespace ラベルのいずれかをシャード化の方法として使用できます。
6.8.6.1. ルートラベルを使用した Ingress コントローラーのシャード化の設定
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
- router-internal.yamlファイルを編集します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
 
- Ingress Controller の - router-internal.yamlファイルを適用します。- oc apply -f router-internal.yaml - # oc apply -f router-internal.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Ingress Controller は、 - type: shardedというラベルのある namespace のルートを選択します。
- router-internal.yamlで設定されたドメインを使用して新しいルートを作成します。- oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net - $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.6.2. namespace ラベルを使用した Ingress Controller のシャード化の設定
namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
							Keepalived Ingress VIP をデプロイする場合は、endpoint Publishing Strategy パラメーターに Host Network の値が割り当てられた、デフォルト以外の Ingress Controller をデプロイしないでください。デプロイしてしまうと、問題が発生する可能性があります。endpoint Publishing Strategy に Host Network ではなく、Node Port という値を使用してください。
						
手順
- router-internal.yamlファイルを編集します。- cat router-internal.yaml - # cat router-internal.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
 
- Ingress Controller の - router-internal.yamlファイルを適用します。- oc apply -f router-internal.yaml - # oc apply -f router-internal.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Ingress Controller は、 - type: shardedというラベルのある namespace セレクターによって選択される namespace のルートを選択します。
- router-internal.yamlで設定されたドメインを使用して新しいルートを作成します。- oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net - $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.7. 内部ロードバランサーを使用するための Ingress Controller の設定
クラウドプラットフォームで Ingress Controller を作成する場合、Ingress Controller はデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress Controller を作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
						IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。
					
図6.1 ロードバランサーの図
前述の図では、OpenShift Container Platform Ingress LoadBalancerService エンドポイントの公開戦略に関する以下のような概念を示しています。
- 負荷は、外部からクラウドプロバイダーのロードバランサーを使用するか、内部から OpenShift Ingress Controller Load Balancer を使用して、分散できます。
- ロードバランサーのシングル IP アドレスと、図にあるクラスターのように、8080 や 4200 といった馴染みのあるポートを使用することができます。
- 外部のロードバランサーからのトラフィックは、ダウンしたノードのインスタンスで記載されているように、Pod の方向に進められ、ロードバランサーが管理します。実装の詳細については、Kubernetes サービスドキュメント を参照してください。
前提条件
- 
							OpenShift CLI (oc) がインストールされている。
- 
							cluster-admin権限を持つユーザーとしてログインしている。
手順
- 以下の例のように、 - <name>-ingress-controller.yamlという名前のファイルに- IngressControllerカスタムリソース (CR) を作成します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。 - oc create -f <name>-ingress-controller.yaml - $ oc create -f <name>-ingress-controller.yaml- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- <name>を- IngressControllerオブジェクトの名前に置き換えます。
 
- オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。 - oc --all-namespaces=true get ingresscontrollers - $ oc --all-namespaces=true get ingresscontrollers- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.8. GCP での Ingress Controller のグローバルアクセスの設定
内部ロードバランサーで GCP で作成された Ingress Controller は、サービスの内部 IP アドレスを生成します。クラスター管理者は、グローバルアクセスオプションを指定できます。これにより、同じ VPC ネットワーク内の任意のリージョンでクラスターを有効にし、ロードバランサーとしてコンピュートリージョンを有効にして、クラスターで実行されるワークロードに到達できるようにできます。
詳細情報は、GCP ドキュメントの グローバルアクセス について参照してください。
前提条件
- OpenShift Container Platform クラスターを GCP インフラストラクチャーにデプロイしている。
- 内部ロードバランサーを使用するように Ingress Controller を設定している。
- 
							OpenShift CLI (oc) がインストールされている。
手順
- グローバルアクセスを許可するように Ingress Controller リソースを設定します。 注記- Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。 - Ingress Controller リソースを設定します。 - oc -n openshift-ingress-operator edit ingresscontroller/default - $ oc -n openshift-ingress-operator edit ingresscontroller/default- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- YAML ファイルを編集します。 - サンプル - clientAccess設定を- Globalに設定します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- gcp.clientAccessを- Globalに設定します。
 
- 変更を適用するためにファイルを保存します。
 
- 以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。 - oc -n openshift-ingress edit svc/router-default -o yaml - $ oc -n openshift-ingress edit svc/router-default -o yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - この出力では、グローバルアクセスがアノテーション - networking.gke.io/internal-load-balancer-allow-global-accessで GCP について有効にされていることを示しています。
6.8.9. クラスターを内部に配置するようにのデフォルト Ingress コントローラーを設定する
					削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定できます。
				
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
						IngressControllerのscopeを変更する場合は、カスタムリソース (CR) の作成後に.spec.endpoint Publishing Strategy.load Balancer.scopeパラメーターを変更できます。
					
前提条件
- 
							OpenShift CLI (oc) がインストールされている。
- 
							cluster-admin権限を持つユーザーとしてログインしている。
手順
- 削除や再作成を実行して、クラスターを内部に配置するように - defaultIngress Controller を設定します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.10. ルートの受付ポリシーの設定
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の namespace でアプリケーションを実行できます。これは、複数のチームが同じホスト名で公開されるマイクロサービスを開発する組織を対象としています。
複数の namespace での要求の許可は、namespace 間の信頼のあるクラスターに対してのみ有効にする必要があります。有効にしないと、悪意のあるユーザーがホスト名を乗っ取る可能性があります。このため、デフォルトの受付ポリシーは複数の namespace 間でのホスト名の要求を許可しません。
前提条件
- クラスター管理者の権限。
手順
- 以下のコマンドを使用して、 - ingresscontrollerリソース変数の- .spec.routeAdmissionフィールドを編集します。- oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge- $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - イメージコントローラー設定例 - spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...- spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow ヒント- または、以下の YAML を適用してルートの受付ポリシーを設定できます。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.11. ワイルドカードルートの使用
					HAProxy Ingress Controller にはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress Controller の ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。
				
					Ingress Controller のデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。
				
手順
- ワイルドカードポリシーを設定します。 - 以下のコマンドを使用して - IngressControllerリソースを編集します。- oc edit IngressController - $ oc edit IngressController- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- specの下で、- wildcardPolicyフィールドを- WildcardsDisallowedまたは- WildcardsAllowedに設定します。- spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed- spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
6.8.12. X-Forwarded ヘッダーの使用
					Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法についてのポリシーを指定するように HAProxy Ingress Controller を設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress Controller の ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。
				
手順
- Ingress Controller 用に - HTTPHeadersフィールドを設定します。- 以下のコマンドを使用して - IngressControllerリソースを編集します。- oc edit IngressController - $ oc edit IngressController- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- specの下で、- HTTPHeadersポリシーフィールドを- Append、- Replace、- IfNone、または- Neverに設定します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
使用例
クラスター管理者として、以下を実行できます。
- Ingress Controller に転送する前に、 - X-Forwarded-Forヘッダーを各リクエストに挿入する外部プロキシーを設定します。- ヘッダーを変更せずに渡すように Ingress Controller を設定するには、 - neverポリシーを指定します。これにより、Ingress Controller はヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。
- 外部プロキシーが外部クラスター要求を設定する - X-Forwarded-Forヘッダーを変更せずに渡すように Ingress Controller を設定します。- 外部プロキシーを通過しない内部クラスター要求に - X-Forwarded-Forヘッダーを設定するように Ingress Controller を設定するには、- if-noneポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress Controller はこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress Controller はヘッダーを追加します。
アプリケーション開発者として、以下を実行できます。
- X-Forwarded-Forヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。- 他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress Controller を設定するには、アプリケーションの Route に アノテーション - haproxy.router.openshift.io/set-forwarded-headers: if-noneまたは- haproxy.router.openshift.io/set-forwarded-headers: neverを追加します。注記- Ingress Controller のグローバルに設定された値とは別に、 - haproxy.router.openshift.io/set-forwarded-headersアノテーションをルートごとに設定できます。
6.8.13. HTTP/2 Ingress 接続の有効化
HAProxy で透過的なエンドツーエンド HTTP/2 接続を有効にすることができます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。
個別の Ingress Controller またはクラスター全体について、HTTP/2 接続を有効にすることができます。
クライアントから HAProxy への接続について HTTP/2 の使用を有効にするために、ルートはカスタム証明書を指定する必要があります。デフォルトの証明書を使用するルートは HTTP/2 を使用することができません。この制限は、クライアントが同じ証明書を使用する複数の異なるルートに接続を再使用するなどの、接続の結合 (coalescing) の問題を回避するために必要です。
HAProxy からアプリケーション Pod への接続は、re-encrypt ルートのみに HTTP/2 を使用でき、edge termination ルートまたは非セキュアなルートには使用しません。この制限は、HAProxy が TLS 拡張である Application-Level Protocol Negotiation (ALPN) を使用してバックエンドで HTTP/2 の使用をネゴシエートするためにあります。そのため、エンドツーエンドの HTTP/2 はパススルーおよび re-encrypt 使用できますが、非セキュアなルートまたは edge termination ルートでは使用できません。
再暗号化ルートで WebSocket を使用し、Ingress Controller で HTTP/2 を有効にするには、HTTP/2 を介した WebSocket のサポートが必要です。HTTP/2 上の WebSockets は HAProxy 2.4 の機能であり、現時点では OpenShift Container Platform ではサポートされていません。
パススルー以外のルートの場合、Ingress Controller はクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。つまり、クライアントが Ingress Controller に接続して HTTP/1.1 をネゴシエートし、Ingress Controller は次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress Controller は WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。
手順
単一 Ingress Controller で HTTP/2 を有効にします。
- Ingress Controller で HTTP/2 を有効にするには、 - oc annotateコマンドを入力します。- oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true - $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - <ingresscontroller_name>をアノテーションを付ける Ingress Controller の名前に置き換えます。
クラスター全体で HTTP/2 を有効にします。
- クラスター全体で HTTP/2 を有効にするには、 - oc annotateコマンドを入力します。- oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true - $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow ヒント- または、以下の YAML を適用してアノテーションを追加できます。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.14. Ingress Controller の PROXY プロトコルの設定
					クラスター管理者は、Ingress Controller が HostNetwork または NodePortService エンドポイントの公開ストラテジータイプのいずれかを使用する際に PROXY プロトコル を設定できます。PROXY プロトコルにより、ロードバランサーは Ingress Controller が受信する接続の元のクライアントアドレスを保持することができます。元のクライアントアドレスは、HTTP ヘッダーのロギング、フィルタリング、および挿入を実行する場合に便利です。デフォルト設定では、Ingress Controller が受信する接続には、ロードバランサーに関連付けられるソースアドレスのみが含まれます。
				
この機能は、クラウドデプロイメントではサポートされていません。この制限があるのは、OpenShift Container Platform がクラウドプラットフォームで実行され、IngressController がサービスロードバランサーを使用するように指定している場合に、Ingress Operator がロードバランサーサービスを設定し、ソースアドレスを保持するプラットフォーム要件に基づいて PROXY プロトコルを有効にするためです。
PROXY プロトコルまたは TCP を使用するには、OpenShift Container Platform と外部ロードバランサーの両方を設定する必要があります。
PROXY プロトコルは、Keepalived Ingress VIP を使用するクラウド以外のプラットフォーム上のインストーラーによってプロビジョニングされたクラスターを使用するデフォルトの Ingress Controller ではサポートされていません。
前提条件
- Ingress Controller を作成している。
手順
- Ingress Controller リソースを編集します。 - oc -n openshift-ingress-operator edit ingresscontroller/default - $ oc -n openshift-ingress-operator edit ingresscontroller/default- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- PROXY 設定を設定します。 - Ingress Controller が hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、 - spec.endpointPublishingStrategy.nodePort.protocolサブフィールドを- PROXYに設定します。- PROXYへの- hostNetworkの設定例- spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork- spec: endpointPublishingStrategy: hostNetwork: protocol: PROXY type: HostNetwork- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、 - spec.endpointPublishingStrategy.nodePort.protocolサブフィールドを- PROXYに設定します。- PROXYへのサンプル- nodePort設定- spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService- spec: endpointPublishingStrategy: nodePort: protocol: PROXY type: NodePortService- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
6.8.15. appsDomain オプションを使用した代替クラスタードメインの指定
					クラスター管理者は、appsDomain フィールドを設定して、ユーザーが作成したルートのデフォルトのクラスタードメインの代わりとなるものを指定できます。appsDomain フィールドは、domain フィールドで指定されているデフォルトの代わりに使用する OpenShift Container Platform のオプションのドメインです。代替ドメインを指定する場合、これは新規ルートのデフォルトホストを判別できるようにする目的でデフォルトのクラスタードメインを上書きします。
				
たとえば、所属企業の DNS ドメインを、クラスター上で実行されるアプリケーションのルートおよび ingress のデフォルトドメインとして使用できます。
前提条件
- OpenShift Container Platform クラスターをデプロイしていること。
- 
							ocコマンドラインインターフェイスをインストールしている。
手順
- ユーザーが作成するルートに代替のデフォルトドメインを指定して - appsDomainフィールドを設定します。- Ingress - clusterリソースを編集します。- oc edit ingresses.config/cluster -o yaml - $ oc edit ingresses.config/cluster -o yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- YAML ファイルを編集します。 - test.example.comへの- apps Domainの設定例- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- ルートを公開し、ルートドメインの変更を確認して、既存のルートに、 - appsDomainフィールドで指定したドメイン名が含まれていることを確認します。注記- ルートを公開する前に - openshift-apiserverがローリング更新を終了するのを待機します。- ルートを公開します。 - oc expose service hello-openshift - $ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例: - oc get routes - $ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hello-openshift hello_openshift-<my_project>.test.example.com hello-openshift 8080-tcp None- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
6.8.16. HTTP ヘッダーケースの変換
					HAProxy 2.2 では、デフォルトで HTTP ヘッダー名を小文字化します。たとえば、Host: xyz.com を host: xyz.com に変更します。レガシーアプリケーションが HTTP ヘッダー名の大文字を認識する場合、Ingress Controller の spec.httpHeaders.headerNameCaseAdjustments  API フィールドを、修正されるまでレガシーアプリケーションに対応するソリューションに使用します。
				
						OpenShift Container Platform 4.10 には HAProxy 2.2 が含まれるため、アップグレードする前に spec.httpHeaders.headerNameCaseAdjustments を使用して必要な設定を追加するようにしてください。
					
前提条件
- 
							OpenShift CLI (oc) がインストールされている。
- 
							cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
						クラスター管理者は、oc patch コマンドを入力するか、Ingress Controller YAML ファイルの HeaderNameCaseAdjustments フィールドを設定して HTTP ヘッダーのケースを変換できます。
					
- oc patchコマンドを入力して、HTTP ヘッダーの大文字化を指定します。- oc patchコマンドを入力して、HTTP- hostヘッダーを- Hostに変更します。- oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'- $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- アプリケーションのルートにアノテーションを付けます。 - oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true - $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 次に、Ingress Controller は - host要求ヘッダーを指定どおりに調整します。
 
- Ingress Controller の YAML ファイルを設定し、 - HeaderNameCaseAdjustmentsフィールドを使用して調整を指定します。- 以下のサンプル Ingress Controller YAML は、適切にアノテーションが付けられたルートへの HTTP/1 要求について - hostヘッダーを- Hostに調整します。- Ingress Controller YAML のサンプル - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 以下のサンプルルートでは、 - haproxy.router.openshift.io/h1-adjust-caseアノテーションを使用して HTTP 応答ヘッダー名のケース調整を有効にします。- ルート YAML のサンプル - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- haproxy.router.openshift.io/h1-adjust-caseを true に設定します。
 
 
6.8.17. ルーター圧縮の使用
					特定の MIME タイプに対してルーター圧縮をグローバルに指定するように HAProxy Ingress Controller を設定します。mimeTypes変数を使用して、圧縮が適用される MIME タイプの形式を定義できます。タイプは、アプリケーション、イメージ、メッセージ、マルチパート、テキスト、ビデオ、または X-で始まるカスタムタイプです。MIME タイプとサブタイプの完全な表記を確認するには、RFC1341を参照してください。
				
圧縮用に割り当てられたメモリーは、最大接続数に影響を与える可能性があります。さらに、大きなバッファーを圧縮すると、正規表現による負荷が多い場合や正規表現のリストが長い場合など、レイテンシーが発生する可能性があります。
すべての MIME タイプが圧縮から利点を得るわけではありませんが、HAProxy は、指示された場合でもリソースを使用して圧縮を試みます。一般に、html、css、js などのテキスト形式は圧縮から利点を得ますが、イメージ、音声、ビデオなどのすでに圧縮済みの形式は、圧縮に時間とリソースが費やされるわりに利点はほぼありません。
手順
- Ingress Controller の - httpCompressionフィールドを設定します。- 以下のコマンドを使用して - IngressControllerリソースを編集します。- oc edit -n openshift-ingress-operator ingresscontrollers/default - $ oc edit -n openshift-ingress-operator ingresscontrollers/default- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- specで、- httpCompressionポリシーフィールドを- mimeTypesに設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
6.8.18. ルーターメトリクスの公開
デフォルトで、HAProxy ルーターメトリクスをデフォルトの stats ポート (1936) に Prometheus 形式で公開できます。Prometheus などの外部メトリクス収集および集約システムは、HAProxy ルーターメメトリクスにアクセスできます。HAProxy ルーターメトリクスは、HTML およびコンマ区切り値 (CSV) 形式でブラウザーに表示できます。
前提条件
- ファイアウォールを、デフォルトの stats ポート (1936) にアクセスするように設定している。
手順
- 次のコマンドを実行して、ルーター Pod 名を取得します。 - oc get pods -n openshift-ingress - $ oc get pods -n openshift-ingress- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h - NAME READY STATUS RESTARTS AGE router-default-76bfffb66c-46qwp 1/1 Running 0 11h- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- ルーター Pod が - /var/lib/haproxy/conf/metrics-auth/statsUsernameおよび- /var/lib/haproxy/conf/metrics-auth/statsPasswordファイルに保存しているルーターのユーザー名およびパスワードを取得します。- 次のコマンドを実行して、ユーザー名を取得します。 - oc rsh <router_pod_name> cat metrics-auth/statsUsername - $ oc rsh <router_pod_name> cat metrics-auth/statsUsername- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを実行して、パスワードを取得します。 - oc rsh <router_pod_name> cat metrics-auth/statsPassword - $ oc rsh <router_pod_name> cat metrics-auth/statsPassword- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。 - oc describe pod <router_pod> - $ oc describe pod <router_pod>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。 - curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics - $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを実行して、安全にメトリクスにアクセスします。 - curl -u user:password https://<router_IP>:<stats_port>/metrics -k - $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。 - curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics - $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 例6.1 出力例 - … # HELP haproxy_backend_connections_total Total number of connections. # TYPE haproxy_backend_connections_total gauge haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0 haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0 … # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value. # TYPE haproxy_exporter_server_threshold gauge haproxy_exporter_server_threshold{type="current"} 11 haproxy_exporter_server_threshold{type="limit"} 500 … # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes. # TYPE haproxy_frontend_bytes_in_total gauge haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0 haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0 haproxy_frontend_bytes_in_total{frontend="public"} 119070 … # HELP haproxy_server_bytes_in_total Current total of incoming bytes. # TYPE haproxy_server_bytes_in_total gauge haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0 haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0 haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0 … 
- ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。 - http://<user>:<password>@<router_IP>:<stats_port> - http://<user>:<password>@<router_IP>:<stats_port>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。 - http://<user>:<password>@<router_ip>:1936/metrics;csv - http://<user>:<password>@<router_ip>:1936/metrics;csv- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
6.8.19. HAProxy エラーコードの応答ページのカスタマイズ
クラスター管理者は、503、404、またはその両方のエラーページにカスタムのエラーコード応答ページを指定できます。HAProxy ルーターは、アプリケーション Pod が実行していない場合や、要求された URL が存在しない場合に 404 エラーページを提供する 503 エラーページを提供します。たとえば、503 エラーコードの応答ページをカスタマイズする場合は、アプリケーション Pod が実行していないときにページが提供されます。また、デフォルトの 404 エラーコード HTTP 応答ページは、誤ったルートまたは存在しないルートについて HAProxy ルーターによって提供されます。
					カスタムエラーコードの応答ページは ConfigMap に指定し、Ingress Controller にパッチを適用されます。ConfigMap キーには、error-page-503.http と error-page-404.http の 2 つの利用可能なファイル名があります。
				
カスタムの HTTP エラーコードの応答ページは、HAProxy HTTP エラーページ設定のガイドライン に従う必要があります。以下は、デフォルトの OpenShift Container Platform HAProxy ルーターの http 503 エラーコード応答ページ の例です。デフォルトのコンテンツを、独自のカスタムページを作成するためのテンプレートとして使用できます。
デフォルトで、HAProxy ルーターは、アプリケーションが実行していない場合や、ルートが正しくないまたは存在しない場合に 503 エラーページのみを提供します。このデフォルトの動作は、OpenShift Container Platform 4.8 以前の動作と同じです。HTTP エラーコード応答をカスタマイズするための ConfigMap が提供されておらず、カスタム HTTP エラーコード応答ページを使用している場合、ルーターはデフォルトの 404 または 503 エラーコード応答ページを提供します。
OpenShift Container Platform のデフォルトの 503 エラーコードページをカスタマイズのテンプレートとして使用する場合、ファイル内のヘッダーで CRLF 改行コードを使用できるエディターが必要になります。
手順
- openshift-configに- my-custom-error-code-pagesという名前の ConfigMap を作成します。- oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.http - $ oc -n openshift-config create configmap my-custom-error-code-pages \ --from-file=error-page-503.http \ --from-file=error-page-404.http- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 重要- カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、ConfigMap を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。 
- Ingress Controller にパッチを適用し、名前を指定して - my-custom-error-code-pagesConfigMap を参照します。- oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge- $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Ingress Operator は、 - openshift-confignamespace から- openshift-ingressnamespace に- my-custom-error-code-pagesConfigMap をコピーします。Operator は、- openshift-ingressnamespace のパターン- <your_ingresscontroller_name>-errorpagesに従って ConfigMap に名前を付けます。
- コピーを表示します。 - oc get cm default-errorpages -n openshift-ingress - $ oc get cm default-errorpages -n openshift-ingress- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 出力例 - NAME DATA AGE default-errorpages 2 25s - NAME DATA AGE default-errorpages 2 25s- 1 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- defaultの Ingress Controller カスタムリソース (CR) にパッチが適用されているため、ConfigMap 名の例は- default-errorpagesです。
 
- カスタムエラー応答ページを含む ConfigMap がルーターボリュームにマウントされることを確認します。ConfigMap キーは、カスタム HTTP エラーコード応答を持つファイル名です。 - 503 カスタム HTTP カスタムエラーコード応答の場合: - oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http - $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 404 カスタム HTTP カスタムエラーコード応答の場合: - oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http - $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
検証
カスタムエラーコード HTTP 応答を確認します。
- テストプロジェクトおよびアプリケーションを作成します。 - oc new-project test-ingress - $ oc new-project test-ingress- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - oc new-app django-psql-example - $ oc new-app django-psql-example- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 503 カスタム http エラーコード応答の場合: - アプリケーションのすべての Pod を停止します。
- 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。 - curl -vk <route_hostname> - $ curl -vk <route_hostname>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 404 カスタム http エラーコード応答の場合: - 存在しないルートまたは正しくないルートにアクセスします。
- 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。 - curl -vk <route_hostname> - $ curl -vk <route_hostname>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- errorfile属性が- haproxy.configファイルで適切にあるかどうかを確認します。- oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile - $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
