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 コントローラーの設定
6.8.1. カスタムデフォルト証明書の設定 リンクのコピーリンクがクリップボードにコピーされました!
管理者として、 Secret リソースを作成し、IngressController カスタムリソース (CR) を編集して Ingress コントローラーがカスタム証明書を使用するように設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
証明書が以下の要件を満たしている必要があります。
- 証明書が Ingress ドメインに対して有効化されている必要があります。
-
証明書は拡張を使用して、
subjectAltName拡張を使用して、*.apps.ocp4.example.comなどのワイルドカードドメインを指定します。
IngressControllerCR がなければなりません。デフォルトの CR を使用できます。oc --namespace openshift-ingress-operator get ingresscontrollers
$ oc --namespace openshift-ingress-operator get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE default 10m
NAME AGE default 10mCopy 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 コントローラーはデプロイメントストラテジーを使用して再デプロイされます。
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.keyCopy 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 -enddateCopy 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 GMCopy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。
IngressController CR が変更された後に、Ingress Operator はカスタム証明書を使用できるように Ingress コントローラーのデプロイメントを更新します。
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 -enddateCopy 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 GMTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.3. Ingress コントローラーのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
Ingress コントローラーは、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。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
2Copy 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
ingresscontroller.operator.openshift.io/default patched
ingresscontroller.operator.openshift.io/default patchedCopy 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
3Copy to Clipboard Copied! Toggle word wrap Toggle overflow
スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。
6.8.4. Ingress アクセスロギングの設定 リンクのコピーリンクがクリップボードにコピーされました!
アクセスログを有効にするように Ingress コントローラーを設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。
コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress コントローラーで問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。
アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
サイドカーへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destinationを使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Containerspec.logging.access.destination.typeを指定する必要があります。以下の例は、コンテナーContainerの宛先に対してログ記録する Ingress コントローラー定義です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーをサイドカーに対してログを記録するように設定すると、Operator は Ingress コントローラー Pod 内に
logsという名前のコンテナーを作成します。oc -n openshift-ingress logs deployment.apps/router-default -c logs
$ oc -n openshift-ingress logs deployment.apps/router-default -c logsCopy 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 コントローラーの定義です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記syslog宛先ポートは UDP である必要があります。
特定のログ形式で Ingress アクセスロギングを設定します。
spec.logging.access.httpLogFormatを指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 のsyslogエンドポイントに対してログを記録する Ingress コントローラーの定義です。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 コントローラーのシャード化 リンクのコピーリンクがクリップボードにコピーされました!
トラフィックがクラスターに送信される主要なメカニズムとして、Ingress コントローラーまたはルーターへの要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。
- Ingress コントローラーまたはルーターを複数のルートに分散し、変更に対する応答を加速します。
- 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
- 特定の Ingress コントローラーに異なるポリシーを定義することを許可します。
- 特定のルートのみが追加機能を使用することを許可します。
- たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
Ingress コントローラーは、ルートラベルまたは namespace ラベルのいずれかをシャード化の方法として使用できます。
6.8.5.1. ルートラベルを使用した Ingress コントローラーのシャード化の設定 リンクのコピーリンクがクリップボードにコピーされました!
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
router-internal.yamlファイルを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーの
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: shardedというラベルのある namespace のルートを選択します。
6.8.5.2. namespace ラベルを使用した Ingress コントローラーのシャード化の設定 リンクのコピーリンクがクリップボードにコピーされました!
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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーの
router-internal.yamlファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: shardedというラベルのある namespace セレクターによって選択される namespace のルートを選択します。
6.8.6. 内部ロードバランサーを使用するように Ingress コントローラーを設定する リンクのコピーリンクがクリップボードにコピーされました!
クラウドプラットフォームで Ingress コントローラーを作成する場合、Ingress コントローラーはデフォルトでパブリッククラウドロードバランサーによって公開されます。管理者は、内部クラウドロードバランサーを使用する Ingress コントローラーを作成できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
IngressController オブジェクトの スコープ を変更する必要がある場合、IngressController オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更することはできません。
図6.2 ロードバランサーの図
前述の図では、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 コントローラーを作成します。
oc create -f <name>-ingress-controller.yaml
$ oc create -f <name>-ingress-controller.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<name>をIngressControllerオブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress コントローラーが作成されていることを確認します。
oc --all-namespaces=true get ingresscontrollers
$ oc --all-namespaces=true get ingresscontrollersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.7. クラスターを内部に配置するようにのデフォルト Ingress コントローラーを設定する リンクのコピーリンクがクリップボードにコピーされました!
削除や再作成を実行して、クラスターを内部に配置するように default Ingress コントローラーを設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
IngressController オブジェクトの スコープ を変更する必要がある場合、IngressController オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを変更することはできません。
前提条件
-
OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
defaultIngress コントローラーを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.8. ルートの受付ポリシーの設定 リンクのコピーリンクがクリップボードにコピーされました!
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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=mergeCopy 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
6.8.9. ワイルドカードルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy Ingress コントローラーにはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy を使用して、Ingress コントローラーの ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を設定します。
Ingress コントローラーのデフォルトの動作では、ワイルドカードポリシーの None (既存の IngressController リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressControllerリソースを編集します。oc edit IngressController
$ oc edit IngressControllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow specの下で、wildcardPolicyフィールドをWildcardsDisallowedまたはWildcardsAllowedに設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedspec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.10. X-Forwarded ヘッダーの使用 リンクのコピーリンクがクリップボードにコピーされました!
Forwarded および X-Forwarded-For を含む HTTP ヘッダーの処理方法についてのポリシーを指定するように HAProxy Ingress コントローラーを設定します。Ingress Operator は HTTPHeaders フィールドを使用して、Ingress コントローラーの ROUTER_SET_FORWARDED_HEADERS 環境変数を設定します。
手順
Ingress コントローラー用に
HTTPHeadersフィールドを設定します。以下のコマンドを使用して
IngressControllerリソースを編集します。oc edit IngressController
$ oc edit IngressControllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow specの下で、HTTPHeadersポリシーフィールドをAppend、Replace、IfNone、またはNeverに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
使用例
クラスター管理者として、以下を実行できます。
Ingress コントローラーに転送する前に、
X-Forwarded-Forヘッダーを各リクエストに挿入する外部プロキシーを設定します。ヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、
neverポリシーを指定します。これにより、Ingress コントローラーはヘッダーを設定しなくなり、アプリケーションは外部プロキシーが提供するヘッダーのみを受信します。外部プロキシーが外部クラスター要求を設定する
X-Forwarded-Forヘッダーを変更せずに渡すように Ingress コントローラーを設定します。外部プロキシーを通過しない内部クラスター要求に
X-Forwarded-Forヘッダーを設定するように Ingress コントローラーを設定するには、if-noneポリシーを指定します。外部プロキシー経由で HTTP 要求にヘッダーがすでに設定されている場合、Ingress コントローラーはこれを保持します。要求がプロキシーを通過していないためにヘッダーがない場合、Ingress コントローラーはヘッダーを追加します。
アプリケーション開発者として、以下を実行できます。
X-Forwarded-Forヘッダーを挿入するアプリケーション固有の外部プロキシーを設定します。他の Route のポリシーに影響を与えずに、アプリケーションの Route 用にヘッダーを変更せずに渡すように Ingress コントローラーを設定するには、アプリケーションの Route に アノテーション
haproxy.router.openshift.io/set-forwarded-headers: if-noneまたはhaproxy.router.openshift.io/set-forwarded-headers: neverを追加します。注記Ingress コントローラーのグローバルに設定された値とは別に、
haproxy.router.openshift.io/set-forwarded-headersアノテーションをルートごとに設定できます。
6.8.11. HTTP/2 Ingress 接続の有効化 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy で透過的なエンドツーエンド HTTP/2 接続を有効にすることができます。これにより、アプリケーションの所有者は、単一接続、ヘッダー圧縮、バイナリーストリームなど、HTTP/2 プロトコル機能を使用できます。
個別の Ingress コントローラーまたはクラスター全体について、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 コントローラーはクライアントからの接続とは独立してアプリケーションへの接続をネゴシエートします。つまり、クライアントが Ingress コントローラーに接続して HTTP/1.1 をネゴシエートし、Ingress コントローラーは次にアプリケーションに接続して HTTP/2 をネゴシエートし、アプリケーションへの HTTP/2 接続を使用してクライアント HTTP/1.1 接続からの要求の転送を実行できます。Ingress コントローラーは WebSocket を HTTP/2 に転送できず、その HTTP/2 接続を WebSocket に対してアップグレードできないため、クライアントが後に HTTP/1.1 から WebSocket プロトコルに接続をアップグレードしようとすると問題が発生します。そのため、WebSocket 接続を受け入れることが意図されたアプリケーションがある場合、これは HTTP/2 プロトコルのネゴシエートを許可できないようにする必要があります。そうしないと、クライアントは WebSocket プロトコルへのアップグレードに失敗します。
手順
単一 Ingress コントローラーで HTTP/2 を有効にします。
Ingress コントローラーで 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=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow <ingresscontroller_name>をアノテーションを付ける Ingress コントローラーの名前に置き換えます。
クラスター全体で 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=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.8.12. 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 yamlCopy 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 exposedCopy 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 NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow