6.8. Ingress コントローラーの設定
6.8.1. カスタムデフォルト証明書の設定
管理者として、 Secret リソースを作成し、IngressController
カスタムリソース (CR) を編集して Ingress コントローラーがカスタム証明書を使用するように設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアがなければなりません。ここで、証明書は信頼される認証局またはカスタム PKI で設定されたプライベートの信頼される認証局で署名されます。
証明書が以下の要件を満たしている必要があります。
- 証明書が Ingress ドメインに対して有効化されている必要があります。
-
証明書は拡張を使用して、
subjectAltName
拡張を使用して、*.apps.ocp4.example.com
などのワイルドカードドメインを指定します。
IngressController
CR がなければなりません。デフォルトの CR を使用できます。$ oc --namespace openshift-ingress-operator get ingresscontrollers
出力例
NAME AGE default 10m
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-ingress
namespace に作成します。$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
IngressController CR を、新規証明書シークレットを参照するように更新します。
$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \ --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
更新が正常に行われていることを確認します。
$ echo Q |\ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\ openssl x509 -noout -subject -issuer -enddate
ここでは、以下のようになります。
<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
証明書シークレットの名前は、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'
クラスターが新しい証明書設定を調整している間、遅延が発生する可能性があります。
検証
元のクラスター証明書が復元されたことを確認するには、次のコマンドを入力します。
$ echo Q | \ openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \ openssl x509 -noout -subject -issuer -enddate
ここでは、以下のようになります。
<domain>
- クラスターのベースドメイン名を指定します。
出力例
subject=CN = *.apps.<domain> issuer=CN = ingress-operator@1620633373 notAfter=May 10 10:44:36 2023 GMT
6.8.3. Ingress コントローラーのスケーリング
Ingress コントローラーは、スループットを増大させるための要件を含む、ルーティングのパフォーマンスや可用性に関する各種要件に対応するために手動でスケーリングできます。oc
コマンドは、IngressController
リソースのスケーリングに使用されます。以下の手順では、デフォルトの IngressController
をスケールアップする例を示します。
手順
デフォルト
IngressController
の現在の利用可能なレプリカ数を表示します。$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
出力例
2
oc patch
コマンドを使用して、デフォルトのIngressController
を必要なレプリカ数にスケーリングします。以下の例では、デフォルトのIngressController
を 3 つのレプリカにスケーリングしています。$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
出力例
ingresscontroller.operator.openshift.io/default patched
デフォルトの
IngressController
が指定したレプリカ数にスケーリングされていることを確認します。$ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
出力例
3
スケーリングは、必要な数のレプリカを作成するのに時間がかかるため、すぐに実行できるアクションではありません。
6.8.4. Ingress アクセスロギングの設定
アクセスログを有効にするように Ingress コントローラーを設定できます。大量のトラフィックを受信しないクラスターがある場合、サイドカーにログインできます。クラスターのトラフィックが多い場合、ロギングスタックの容量を超えないようにしたり、OpenShift Container Platform 外のロギングインフラストラクチャーと統合したりするために、ログをカスタム syslog エンドポイントに転送することができます。アクセスログの形式を指定することもできます。
コンテナーロギングは、既存の Syslog ロギングインフラストラクチャーがない場合や、Ingress コントローラーで問題を診断する際に短期間使用する場合に、低トラフィックのクラスターのアクセスログを有効にするのに役立ちます。
アクセスログが OpenShift Logging スタックの容量を超える可能性があるトラフィックの多いクラスターや、ロギングソリューションが既存の Syslog ロギングインフラストラクチャーと統合する必要のある環境では、syslog が必要です。Syslog のユースケースは重複する可能性があります。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
サイドカーへの Ingress アクセスロギングを設定します。
Ingress アクセスロギングを設定するには、
spec.logging.access.destination
を使用して宛先を指定する必要があります。サイドカーコンテナーへのロギングを指定するには、Container
spec.logging.access.destination.type
を指定する必要があります。以下の例は、コンテナーContainer
の宛先に対してログ記録する Ingress コントローラー定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Container
Ingress コントローラーをサイドカーに対してログを記録するように設定すると、Operator は Ingress コントローラー Pod 内に
logs
という名前のコンテナーを作成します。$ oc -n openshift-ingress logs deployment.apps/router-default -c logs
出力例
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"
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 コントローラーの定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514
注記syslog
宛先ポートは UDP である必要があります。
特定のログ形式で Ingress アクセスロギングを設定します。
spec.logging.access.httpLogFormat
を指定して、ログ形式をカスタマイズできます。以下の例は、IP アドレスが 1.2.3.4 およびポート 10514 のsyslog
エンドポイントに対してログを記録する Ingress コントローラーの定義です。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: destination: type: Syslog syslog: address: 1.2.3.4 port: 10514 httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'
Ingress アクセスロギングを無効にします。
Ingress アクセスロギングを無効にするには、
spec.logging
またはspec.logging.access
を空のままにします。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: replicas: 2 logging: access: null
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
ファイルを編集します。# cat router-internal.yaml apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" routeSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
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
出力例
apiVersion: v1 items: - apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: sharded namespace: openshift-ingress-operator spec: domain: <apps-sharded.basedomain.example.net> nodePlacement: nodeSelector: matchLabels: node-role.kubernetes.io/worker: "" namespaceSelector: matchLabels: type: sharded status: {} kind: List metadata: resourceVersion: "" selfLink: ""
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
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) を作成します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: <name> 1 spec: domain: <domain> 2 endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal 3
以下のコマンドを実行して、直前の手順で定義された Ingress コントローラーを作成します。
$ oc create -f <name>-ingress-controller.yaml 1
- 1
<name>
をIngressController
オブジェクトの名前に置き換えます。
オプション: 以下のコマンドを実行して Ingress コントローラーが作成されていることを確認します。
$ oc --all-namespaces=true get ingresscontrollers
6.8.7. クラスターを内部に配置するようにのデフォルト Ingress コントローラーを設定する
削除や再作成を実行して、クラスターを内部に配置するように default
Ingress コントローラーを設定できます。
クラウドプロバイダーが Microsoft Azure の場合、ノードを参照するパブリックロードバランサーが少なくとも 1 つ必要です。これがない場合、すべてのノードがインターネットへの egress 接続を失います。
IngressController
オブジェクトの スコープ
を変更する必要がある場合、IngressController
オブジェクトを削除してから、これを再作成する必要があります。カスタムリソース (CR) の作成後に .spec.endpointPublishingStrategy.loadBalancer.scope
パラメーターを変更することはできません。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
削除や再作成を実行して、クラスターを内部に配置するように
default
Ingress コントローラーを設定します。$ oc replace --force --wait --filename - <<EOF apiVersion: operator.openshift.io/v1 kind: IngressController metadata: namespace: openshift-ingress-operator name: default spec: endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: Internal EOF
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
イメージコントローラー設定例
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
6.8.9. ワイルドカードルートの使用
HAProxy Ingress コントローラーにはワイルドカードルートのサポートがあります。Ingress Operator は wildcardPolicy
を使用して、Ingress コントローラーの ROUTER_ALLOW_WILDCARD_ROUTES
環境変数を設定します。
Ingress コントローラーのデフォルトの動作では、ワイルドカードポリシーの None
(既存の IngressController
リソースとの後方互換性がある) を持つルートを許可します。
手順
ワイルドカードポリシーを設定します。
以下のコマンドを使用して
IngressController
リソースを編集します。$ oc edit IngressController
spec
の下で、wildcardPolicy
フィールドをWildcardsDisallowed
またはWildcardsAllowed
に設定します。spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed
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
spec
の下で、HTTPHeaders
ポリシーフィールドをAppend
、Replace
、IfNone
、またはNever
に設定します。apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: httpHeaders: forwardedHeaderPolicy: Append
使用例
クラスター管理者として、以下を実行できます。
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
<ingresscontroller_name>
をアノテーションを付ける Ingress コントローラーの名前に置き換えます。
クラスター全体で HTTP/2 を有効にします。
クラスター全体で HTTP/2 を有効にするには、
oc annotate
コマンドを入力します。$ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true
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
YAML ファイルを編集します。
test.example.com
へのapps Domain
の設定例apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: apps.example.com 1 appsDomain: <test.example.com> 2
ルートを公開し、ルートドメインの変更を確認して、既存のルートに、
appsDomain
フィールドで指定したドメイン名が含まれていることを確認します。注記ルートを公開する前に
openshift-apiserver
がローリング更新を終了するのを待機します。ルートを公開します。
$ oc expose service hello-openshift route.route.openshift.io/hello-openshift exposed
出力例:
$ 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