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.第17章 ルートの作成
17.1. ルート設定 リンクのコピーリンクがクリップボードにコピーされました!
17.1.1. HTTP ベースのルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
以下の手順では、hello-openshift
アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
hello-openshift
というサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
hello-openshift
アプリケーションに対して、セキュアではないルートを作成します。oc expose svc hello-openshift
$ oc expose svc hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果として生成される
Route
リソースを検査すると、以下のようになります。上記で作成されたセキュアでないルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトの ingress ドメインを表示するには、以下のコマンドを実行します。
oc get ingresses.config/cluster -o jsonpath={.spec.domain}
$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.2. ルートのタイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。
前提条件
- 実行中のクラスターでデプロイ済みの Ingress コントローラーが必要になります。
手順
oc annotate
コマンドを使用して、ルートにタイムアウトを追加します。oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>
$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。
以下の例では、2 秒のタイムアウトを
myroute
という名前のルートに設定します。oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.3. HTTP Strict Transport Security リンクのコピーリンクがクリップボードにコピーされました!
HTTP Strict Transport Security (HSTS) ポリシーは、HTTPS トラフィックのみがルートホストで許可されるブラウザークライアントに通知するセキュリティーの拡張機能です。また、HSTS は、HTTP リダイレクトを使用せずに HTTPS トランスポートにシグナルを送ることで Web トラフィックを最適化します。HSTS は Web サイトとの対話を迅速化するのに便利です。
HSTS ポリシーが適用されると、HSTS はサイトから Strict Transport Security ヘッダーを HTTP および HTTPS 応答に追加します。HTTP を HTTPS にリダイレクトするルートで insecureEdgeTerminationPolicy
値を使用できます。HSTS を強制している場合は、要求の送信前にクライアントがすべての要求を HTTP URL から HTTPS に変更するため、リダイレクトの必要がなくなります。
クラスター管理者は、以下を実行するために HSTS を設定できます。
- ルートごとに HSTS を有効にします。
- ルートごとに HSTS を無効にします。
- ドメインごとに HSTS を適用するか、ドメインと組み合わせた namespace ラベルを使用します。
HSTS はセキュアなルート (edge-termination または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。
17.1.3.1. ルートごとの HTTP Strict Transport Security の有効化 リンクのコピーリンクがクリップボードにコピーされました!
HTTP 厳密なトランスポートセキュリティー (HSTS) は HAProxy テンプレートに実装され、haproxy.router.openshift.io/hsts_header
アノテーションを持つ edge および re-encrypt ルートに適用されます。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
oc
CLI をインストールしていること。
手順
ルートで HSTS を有効にするには、
haproxy.router.openshift.io/hsts_header
値を edge-termed または re-encrypt ルートに追加します。これを実行するには、oc annotate
ツールを使用してこれを実行できます。oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ includeSubDomains;preload"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\
1 includeSubDomains;preload"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この例では、最長期間は
31536000
ミリ秒 (約 8 時間および半分) に設定されます。
注記この例では、等号 (
=
) が引用符で囲まれています。これは、annotate コマンドを正しく実行するために必要です。アノテーションで設定されたルートの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必須。
max-age
は、HSTS ポリシーが有効な期間 (秒単位) を測定します。0
に設定すると、これはポリシーを無効にします。 - 2
- オプション:
includeSubDomains
は、クライアントに対し、ホストのすべてのサブドメインにホストと同じ HSTS ポリシーを持つ必要があることを指示します。 - 3
- オプション:
max-age
が 0 より大きい場合、preload
をhaproxy.router.openshift.io/hsts_header
に追加し、外部サービスがこのサイトをそれぞれの HSTS プリロード一覧に含めることができます。たとえば、Google などのサイトはpreload
が設定されているサイトの一覧を作成します。ブラウザーはこれらの一覧を使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload
を設定していない場合、ブラウザーはヘッダーを取得するために、HTTPS を介してサイトと少なくとも 1 回対話している必要があります。
17.1.3.2. ルートごとの HTTP Strict Transport Security の無効化 リンクのコピーリンクがクリップボードにコピーされました!
ルートごとに HSTS (HTTP Strict Transport Security) を無効にするには、ルートアノテーションの max-age
の値を 0
に設定します。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
oc
CLI をインストールしていること。
手順
HSTS を無効にするには、以下のコマンドを入力してルートアノテーションの
max-age
の値を0
に設定します。oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントまたは、以下の YAML を適用して ConfigMap を作成できます。
ルートごとに HSTS を無効にする例
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace のすべてのルートで HSTS を無効にするには、followinf コマンドを入力します。
oc annotate <route> --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate <route> --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name: routename HSTS: max-age=0
Name: routename HSTS: max-age=0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.3.3. ドメインごとに HTTP Strict Transport Security の強制 リンクのコピーリンクがクリップボードにコピーされました!
安全なルートのドメインごとに HTTPStrict Transport Security(HSTS) を適用するには、requiredHSTSPolicies
レコードを Ingress 仕様に追加して、HSTS ポリシーの設定を取得します。
requiredHSTSPolicy
を設定して HSTS を適用する場合は、新規に作成されたルートは準拠された HSTS ポリシーアノテーションで設定する必要があります。
準拠しない HSTS ルートを持つアップグレードされたクラスターを処理するには、ソースでマニフェストを更新し、更新を適用できます。
oc expose route
コマンドまたは oc create route
コマンドを使用して、HSTS を強制するドメインにルートを追加することはできません。このコマンドの API はアノテーションを受け入れないためです。
HSTS がすべてのルートに対してグローバルに要求されている場合でも、セキュアではないルートや非 TLS ルートに適用することはできません。
前提条件
- プロジェクトの管理者権限があるユーザーで、クラスターにログインしている。
-
oc
CLI をインストールしていること。
手順
Ingress 設定ファイルを編集します。
oc edit ingresses.config.openshift.io/cluster
$ oc edit ingresses.config.openshift.io/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow HSTS ポリシーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必須。
requiredHSTSPolicies
は順番に検証され、最初に一致するdomainPatterns
が適用されます。 - 2 7
- 必須。1 つ以上の
domainPatterns
ホスト名を指定する必要があります。任意の数のドメインを一覧表示できます。さまざまなdomainPatterns
について、Enforcing オプションの複数のセクションを含めることができます。 - 3
- オプション:
namespaceSelector
を含める場合、ルートを配置するプロジェクトのラベルと一致する必要があります。これにより、ルートに設定された HSTS ポリシーを適用する必要があります。domainPatterns
ではなくnamespaceSelector
のみに一致するルートは検証されません。 - 4
- 必須。
max-age
は、HSTS ポリシーが有効な期間 (秒単位) を測定します。このポリシー設定により、最小および最大のmax-age
を適用することができます。-
largestMaxAge
の値は0
から2147483647
の範囲内で指定する必要があります。これを指定しないと、上限が強制されないことを意味します。 -
smallestMaxAge
の値は0
から2147483647
の範囲内で指定する必要があります。トラブルシューティングのために HSTS を無効にするには、0
を入力します。HSTS を無効にする必要がない場合は1
を入力します。これを指定しないと、下限が強制されません。
-
- 5
- オプション:
haproxy.router.openshift.io/hsts_header
にpreload
を含めることで、外部サービスがこのサイトをそれぞれの HSTS プリロード一覧に含めることができます。ブラウザーはこれらの一覧を使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload
設定がない場合、ブラウザーは少なくともサイトと通信してヘッダーを取得する必要があります。preload
は、以下のいずれかで設定できます。-
RequirePreload
:preload
はRequiredHSTSPolicy
で必要になります。 -
RequireNoPreload
:preload
はRequiredHSTSPolicy
によって禁止されます。 -
NoOpinion
:preload
はRequiredHSTSPolicy
に重要ではありません。
-
- 6
- オプション:
includeSubDomainsPolicy
は、以下のいずれかで設定できます。-
RequireIncludeSubDomains
:includeSubDomains
はRequiredHSTSPolicy
で必要です。 -
RequireNoIncludeSubDomains
:includeSubDomains
はRequiredHSTSPolicy
によって禁止されています。 -
NoOpinion
:includeSubDomains
はRequiredHSTSPolicy
に重要ではありません。
-
oc annotate command
を入力して、HSTS をクラスターのすべてのルートまたは特定の namespace に適用することができます。HSTS をクラスターのすべてのルートに適用するには、
oc annotate command
を実行します。以下に例を示します。oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定の namespace のすべてのルートに HSTS を適用するには、
oc annotate command
を実行します。以下に例を示します。oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
設定した HSTS ポリシーを確認できます。以下に例を示します。
必要な HSTS ポリシーの
maxAge
セットを確認するには、以下のコマンドを入力します。oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのルートで HSTS アノテーションを確認するには、以下のコマンドを入力します。
oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
$ oc get route --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.4. スループット関連の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。
Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。
ping または tcpdump などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。
たとえば、問題を生じさせる動作を再現している間に各 Pod で tcpdump ツールを実行します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェイスが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。
tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
podip
は Pod の IP アドレスです。oc get pod <pod_name> -o wide
コマンドを実行して Pod の IP アドレスを取得します。
tcpdump は 2 つの Pod 間のすべてのトラフィックが含まれる
/tmp/dump.pcap
のファイルを生成します。理想的には、ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。以下のようにノード間でパケットアナライザーを実行することもできます (式から SDN を排除する)。tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。ボトルネックの特定を試行するには、最初に Pod から、次にノードからツールを実行します。
- iperf のインストールおよび使用についての詳細は、こちらの Red Hat ソリューション を参照してください。
17.1.5. Cookie に使用によるルートのステートフル性の維持 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。
OpenShift Container Platform は Cookie を使用してセッションの永続化を設定できます。Ingress コントローラーはユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress コントローラーに対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。
cookie は、HTTP トラフィックを表示できないので、パススルールートで設定できません。代わりに、ソース IP アドレスをベースに数が計算され、バックエンドを判断します。
バックエンドが変わると、トラフィックが間違ったサーバーに転送されてしまい、スティッキーではなくなります。ソース IP を非表示にするロードバランサーを使用している場合は、すべての接続に同じ番号が設定され、トラフィックは同じ Pod に送られます。
17.1.5.1. Cookie を使用したルートのアノテーション リンクのコピーリンクがクリップボードにコピーされました!
ルート用に自動生成されるデフォルト名を上書きするために Cookie 名を設定できます。これにより、ルートトラフィックを受信するアプリケーションが Cookie 名を認識できるようになります。Cookie を削除すると、次の要求でエンドポイントの再選択が強制的に実行される可能性があります。そのためサーバーがオーバーロードしている場合には、クライアントからの要求を取り除き、それらの再分配を試行します。
手順
指定される cookie 名でルートにアノテーションを付けます。
oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
<cookie_name>
- cookie の名前を指定します。
たとえば、ルート
my_route
に cookie 名my_cookie
でアノテーションを付けるには、以下を実行します。oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変数でルートのホスト名を取得します。
ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
cookie を保存してからルートにアクセスします。
curl $ROUTE_NAME -k -c /tmp/cookie_jar
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。
curl $ROUTE_NAME -k -b /tmp/cookie_jar
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.6. パスベースのルート リンクのコピーリンクがクリップボードにコピーされました!
パスベースのルートは、URL に対して比較できるパスコンポーネントを指定します。この場合、ルートのトラフィックは HTTP ベースである必要があります。そのため、それぞれが異なるパスを持つ同じホスト名を使用して複数のルートを提供できます。ルーターは、最も具体的なパスの順に基づいてルートと一致する必要があります。ただし、これはルーターの実装によって異なります。
以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。
ルート | 比較対象 | アクセス可能 |
---|---|---|
www.example.com/test | www.example.com/test | はい |
www.example.com | いいえ | |
www.example.com/test および www.example.com | www.example.com/test | はい |
www.example.com | はい | |
www.example.com | www.example.com/text | Yes (ルートではなく、ホストで一致) |
www.example.com | はい |
パスが 1 つでセキュリティー保護されていないルート
- 1
- パスは、パスベースのルートに唯一追加される属性です。
ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、パススルー TLS を使用する場合には利用できません。
17.1.7. ルート固有のアノテーション リンクのコピーリンクがクリップボードにコピーされました!
Ingress コントローラーは、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。
複数のソース IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、一覧が警告やエラーメッセージなしに無視されます。
変数 | 説明 | デフォルトで使用される環境変数 |
---|---|---|
|
ロードバランシングアルゴリズムを設定します。使用できるオプションは、 |
パススルールートの |
|
関連の接続を追跡する cookie の使用を無効にします。 | |
| このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。 | |
|
ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。 | |
|
| |
|
同じソース IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。 | |
|
同じソース IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。 | |
|
同じソース IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。 | |
| ルートのサーバー側のタイムアウトを設定します。(TimeUnits) |
|
| このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した Web Socket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。 |
|
|
設定できるのは、Ingress Controller または ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxy |
|
| バックエンドのヘルスチェックの間隔を設定します。(TimeUnits) |
|
| ルートのホワイトリストを設定します。ホワイトリストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲の一覧をスペース区切りにします。ホワイトリストに含まれていない IP アドレスからの要求は破棄されます。 ホワイトリストの許可される IP アドレスおよび CIDR 範囲の最大数は 61 です。 | |
| edge terminated または re-encrypt ルートの Strick-Transport-Security ヘッダーを設定します。 | |
|
Syslog ヘッダーの | |
| バックエンドの要求の書き換えパスを設定します。 | |
| Cookie を制限するために値を設定します。値は以下のようになります。
この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメント を参照してください。 | |
|
ルートごとに
|
|
環境変数を編集することはできません。
ルータータイムアウト変数
TimeUnits
は数字、その後に単位を指定して表現します。 us
*(マイクロ秒)、ms
(ミリ秒、デフォルト)、s
(秒)、m
(分)、h
*(時間)、d
(日)
正規表現: [1-9][0-9]*(us
\|ms
\|s
\|m
\|h
\|d
)
変数 | デフォルト | 説明 |
---|---|---|
|
| バックエンドでの後続の liveness チェックの時間の長さ。 |
|
| クライアントがルートに接続する場合の TCP FIN タイムアウトの期間を制御します。接続切断のために送信された FIN が指定の時間内に応答されない場合は、HAProxy が接続を切断します。小さい値を設定し、ルーターでリソースをあまり使用していない場合には、リスクはありません。 |
|
| クライアントがデータを確認するか、送信するための時間の長さ。 |
|
| 最大接続時間。 |
|
| ルーターからルートをバッキングする Pod の TCP FIN タイムアウトを制御します。 |
|
| サーバーがデータを確認するか、送信するための時間の長さ。 |
|
| TCP または WebSocket 接続が開放された状態で保つ時間数。このタイムアウト期間は、HAProxy が再読み込みされるたびにリセットされます。 |
|
|
新しい HTTP 要求が表示されるまで待機する最大時間を設定します。この値が低すぎる場合には、ブラウザーおよびアプリケーションの
有効なタイムアウト値には、想定した個別のタイムアウトではなく、特定の変数を合計した値に指定することができます。たとえば、 |
|
| HTTP 要求の伝送にかかる時間。 |
|
| ルーターがリロードし、新規の変更を受け入れる最小の頻度を許可します。 |
|
| HAProxy メトリクスの収集タイムアウト。 |
ルート設定のカスタムタイムアウト
- 1
- HAProxy 対応の単位 (
us
、ms
、s
、m
、h
、d
) で新規のタイムアウトを指定します。単位が指定されていない場合は、ms
がデフォルトになります。
パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、WebSocket 接続がそのルートで頻繁にタイムアウトする可能性があります。
特定の IP アドレスを 1 つだけ許可するルート
metadata: annotations: haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
複数の IP アドレスを許可するルート
metadata: annotations: haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
IP アドレスの CIDR ネットワークを許可するルート
metadata: annotations: haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
IP アドレスと IP アドレスの CIDR ネットワークの両方を許可するルート
metadata: annotations: haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
書き換えターゲットを指定するルート
- 1
- バックエンドの要求の書き換えパスとして
/
を設定します。
ルートに haproxy.router.openshift.io/rewrite-target
アノテーションを設定すると、要求をバックエンドアプリケーションに転送する前に Ingress コントローラーがこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path
で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。
以下の表は、spec.path
、要求パス、および書き換えターゲットの各種の組み合わせについてのパスの書き換え動作の例を示しています。
Route.spec.path | 要求パス | 書き換えターゲット | 転送された要求パス |
---|---|---|---|
/foo | /foo | / | / |
/foo | /foo/ | / | / |
/foo | /foo/bar | / | /bar |
/foo | /foo/bar/ | / | /bar/ |
/foo | /foo | /bar | /bar |
/foo | /foo/ | /bar | /bar/ |
/foo | /foo/bar | /baz | /baz/bar |
/foo | /foo/bar/ | /baz | /baz/bar/ |
/foo/ | /foo | / | 該当なし (要求パスがルートパスに一致しない) |
/foo/ | /foo/ | / | / |
/foo/ | /foo/bar | / | /bar |
17.1.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=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
17.1.9. Ingress オブジェクトを使用したルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
一部のエコシステムコンポーネントには Ingress リソースとの統合機能がありますが、ルートリソースとは統合しません。これに対応するために、OpenShift Container Platform は Ingress オブジェクトの作成時に管理されるルートオブジェクトを自動的に作成します。これらのルートオブジェクトは、対応する Ingress オブジェクトが削除されると削除されます。
手順
OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、または oc
create
コマンドを実行します。Ingress の YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
route.openshift.io/termination
アノテーションは、Route
のspec.tls.termination
フィールドを設定するために使用できます。Ingress
にはこのフィールドがありません。許可される値はedge
、passthrough
、およびreencrypt
です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edge
がデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。route.openshift.io/termination
アノテーションでpassthrough
の値を指定する場合は、仕様でpath
を''
に設定し、pathType
をImplementationSpecific
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
oc apply -f ingress.yaml
$ oc apply -f ingress.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを一覧表示します。
oc get routes
$ oc get routes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果には、
frontend-
で始まる名前の自動生成ルートが含まれます。NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このルートを検査すると、以下のようになります。
自動生成されるルートの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.10. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する リンクのコピーリンクがクリップボードにコピーされました!
TLS 設定を指定せずに Ingress オブジェクトを作成すると、OpenShift Container Platform は安全でないルートを生成します。デフォルトの Ingress 証明書を使用してセキュアなエッジ終端ルートを生成する Ingress オブジェクトを作成するには、次のように空の TLS 設定を指定できます。
前提条件
- 公開したいサービスがあります。
-
OpenShift CLI (
oc
) にアクセスできる。
手順
Ingress オブジェクトの YAML ファイルを作成します。この例では、ファイルの名前は
example-ingress.yaml
です。Ingress オブジェクトの YAML 定義
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。
次のコマンドを実行して、Ingress オブジェクトを作成します。
oc create -f example-ingress.yaml
$ oc create -f example-ingress.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
以下のコマンドを実行して、OpenShift Container Platform が Ingress オブジェクトの予期されるルートを作成したことを確認します。
oc get routes -o yaml
$ oc get routes -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.11. デュアルスタックネットワーク用の OpenShift Container Platform Ingress コントローラーの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターが IPv4 および IPv6 デュアルスタックネットワーク用に設定されている場合、クラスターは OpenShift Container Platform ルートによって外部からアクセス可能です。
Ingress コントローラーは、IPv4 エンドポイントと IPv6 エンドポイントの両方を持つサービスを自動的に提供しますが、シングルスタックまたはデュアルスタックサービス用に Ingress コントローラーを設定できます。
前提条件
- ベアメタルに OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc
) がインストールされている。
手順
Ingress コントローラーが、IPv4 / IPv6 を介してトラフィックをワークロードに提供するようにするには、
ipFamilies
フィールドおよびipFamilyPolicy
フィールドを設定して、サービス YAML ファイルを作成するか、既存のサービス YAML ファイルを変更します。以下に例を示します。サービス YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのリソースは、対応する
endpoints
を生成します。Ingress コントローラーは、endpointslices
を監視するようになりました。endpoints
を表示するには、以下のコマンドを入力します。oc get endpoints
$ oc get endpoints
Copy to Clipboard Copied! Toggle word wrap Toggle overflow endpointslices
を表示するには、以下のコマンドを入力します。oc get endpointslices
$ oc get endpointslices
Copy to Clipboard Copied! Toggle word wrap Toggle overflow