第25章 ルートの作成
25.1. ルート設定
25.1.1. HTTP ベースのルートの作成
ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
以下の手順では、hello-openshift
アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。$ oc new-project hello-openshift
以下のコマンドを実行してプロジェクトに Pod を作成します。
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
以下のコマンドを実行して、
hello-openshift
というサービスを作成します。$ oc expose pod/hello-openshift
次のコマンドを実行して、
hello-openshift
アプリケーションに対して、セキュアではないルートを作成します。$ oc expose svc hello-openshift
検証
作成した
route
リソースを確認するには、次のコマンドを実行します。$ oc get routes -o yaml <name of resource> 1
- 1
- この例では、ルートの名前は
hello-openshift
です。
上記で作成されたセキュアでないルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift spec: host: hello-openshift-hello-openshift.<Ingress_Domain> 1 port: targetPort: 8080 2 to: kind: Service name: hello-openshift
- 1
<Ingress_Domain>
はデフォルトの Ingress ドメイン名です。ingresses.config/cluster
オブジェクトはインストール中に作成され、変更できません。別のドメインを指定する場合は、appsDomain
オプションを使用して別のクラスタードメインを指定できます。- 2
targetPort
は、このルートが指すサービスによって選択される Pod のターゲットポートです。注記デフォルトの Ingress ドメインを表示するには、以下のコマンドを実行します。
$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
25.1.2. Ingress Controller シャーディングのルート作成
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift
アプリケーションを使用して、Ingress コントローラーシャーディングのルートを作成する方法について説明します。
Ingress Controller のシャード化は、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。$ oc new-project hello-openshift
以下のコマンドを実行してプロジェクトに Pod を作成します。
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
以下のコマンドを実行して、
hello-openshift
というサービスを作成します。$ oc expose pod/hello-openshift
hello-openshift-route.yaml
というルート定義を作成します。シャーディング用に作成されたルートの YAML 定義:
apiVersion: route.openshift.io/v1 kind: Route metadata: labels: type: sharded 1 name: hello-openshift-edge namespace: hello-openshift spec: subdomain: hello-openshift 2 tls: termination: edge to: kind: Service name: hello-openshift
次のコマンドを実行し、
hello-openshift-route.yaml
を使用してhello-openshift
アプリケーションへのルートを作成します。$ oc -n hello-openshift create -f hello-openshift-route.yaml
検証
次のコマンドを使用して、ルートのステータスを取得します。
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
結果の
Route
リソースは次のようになります。出力例
apiVersion: route.openshift.io/v1 kind: Route metadata: labels: type: sharded name: hello-openshift-edge namespace: hello-openshift spec: subdomain: hello-openshift tls: termination: edge to: kind: Service name: hello-openshift status: ingress: - host: hello-openshift.<apps-sharded.basedomain.example.net> 1 routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2 routerName: sharded 3
25.1.3. ルートのタイムアウトの設定
Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。
前提条件
- 実行中のクラスターでデプロイ済みの Ingress Controller が必要になります。
手順
oc annotate
コマンドを使用して、ルートにタイムアウトを追加します。$ oc annotate route <route_name> \ --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1
- 1
- サポートされる時間単位は、マイクロ秒 (us)、ミリ秒 (ms)、秒 (s)、分 (m)、時間 (h)、または日 (d) です。
以下の例では、2 秒のタイムアウトを
myroute
という名前のルートに設定します。$ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s
25.1.4. 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-terminated または re-encrypt) でのみ機能します。この設定は、HTTP またはパススルールートには適していません。
25.1.4.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;\ 1 includeSubDomains;preload"
- 1
- この例では、最長期間は
31536000
ミリ秒 (約 8 時間および半分) に設定されます。
注記この例では、等号 (
=
) が引用符で囲まれています。これは、annotate コマンドを正しく実行するために必要です。アノテーションで設定されたルートの例
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload 1 2 3 ... spec: host: def.abc.com tls: termination: "reencrypt" ... wildcardPolicy: "Subdomain"
- 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 回対話している必要があります。
25.1.4.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"
ヒントまたは、以下の YAML を適用して config map を作成できます。
ルートごとに HSTS を無効にする例
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0
namespace のすべてのルートで HSTS を無効にするには、following コマンドを入力します。
$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
検証
すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。
$ 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}}'
出力例
Name: routename HSTS: max-age=0
25.1.4.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
HSTS ポリシーの例
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: 'hello-openshift-default.apps.username.devcluster.openshift.com' requiredHSTSPolicies: 1 - domainPatterns: 2 - '*hello-openshift-default.apps.username.devcluster.openshift.com' - '*hello-openshift-default2.apps.username.devcluster.openshift.com' namespaceSelector: 3 matchLabels: myPolicy: strict maxAge: 4 smallestMaxAge: 1 largestMaxAge: 31536000 preloadPolicy: RequirePreload 5 includeSubDomainsPolicy: RequireIncludeSubDomains 6 - domainPatterns: 7 - 'abc.example.com' - '*xyz.example.com' namespaceSelector: matchLabels: {} maxAge: {} preloadPolicy: NoOpinion includeSubDomainsPolicy: RequireNoIncludeSubDomains
- 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"
特定の namespace のすべてのルートに HSTS を適用するには、
oc annotate command
を実行します。以下に例を示します。$ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
検証
設定した HSTS ポリシーを確認できます。以下に例を示します。
必要な HSTS ポリシーの
maxAge
セットを確認するには、以下のコマンドを入力します。$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
すべてのルートで 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}}'
出力例
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
25.1.5. スループットの問題のトラブルシューティング方法
OpenShift Container Platform でデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が生じることがあります。
Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。
ping
またはtcpdump
などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。たとえば、問題を生じさせる動作を再現している間に各ノードで
tcpdump
ツールを実行 します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェイスが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Container Platform で発生する可能性があります。$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 1
- 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
ストリーミングのスループットおよび UDP スループットを測定するために
iperf
などの帯域幅測定ツールを使用します。最初に Pod からツールを実行し、次にノードから実行して、ボトルネックを特定します。-
iperf
のインストールおよび使用についての詳細は、こちらの Red Hat ソリューション を参照してください。
-
- 場合によっては、レイテンシーの問題が原因で、クラスターがルーター Pod を含むノードを異常としてマークすることがあります。ワーカーレイテンシープロファイルを使用して、アクションを実行する前にクラスターがノードからステータスの最新情報を受け取る頻度を調節します。
-
クラスターでレイテンシーの低いノードとレイテンシーの高いノードが指定されている場合は、Ingress コントローラーの
spec.nodePlacement
フィールドを設定して、ルーター Pod の配置を制御します。
25.1.6. Cookie の使用によるルートのステートフル性の維持
OpenShift Container Platform は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。
OpenShift Container Platform は Cookie を使用してセッションの永続化を設定できます。Ingress Controller はユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress Controller に対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。
cookie は、HTTP トラフィックを表示できないので、パススルールートで設定できません。代わりに、送信元 IP アドレスをベースに数が計算され、バックエンドを判断します。
バックエンドが変わると、トラフィックが間違ったサーバーに転送されてしまい、スティッキーではなくなります。送信元 IP を非表示にするロードバランサーを使用している場合は、すべての接続に同じ番号が設定され、トラフィックは同じ Pod に送られます。
25.1.6.1. Cookie を使用したルートのアノテーション
ルート用に自動生成されるデフォルト名を上書きするために Cookie 名を設定できます。これにより、ルートトラフィックを受信するアプリケーションが Cookie 名を認識できるようになります。Cookie を削除すると、次の要求でエンドポイントの再選択が強制的に実行される可能性があります。そのためサーバーがオーバーロードしている場合には、クライアントからの要求を取り除き、それらの再分配を試行します。
手順
指定される cookie 名でルートにアノテーションを付けます。
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
<cookie_name>
- cookie の名前を指定します。
たとえば、ルート
my_route
に cookie 名my_cookie
でアノテーションを付けるには、以下を実行します。$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
変数でルートのホスト名を取得します。
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
cookie を保存してからルートにアクセスします。
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
25.1.7. パスベースのルート
パスベースのルートは、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 つでセキュリティー保護されていないルート
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: route-unsecured
spec:
host: www.example.com
path: "/test" 1
to:
kind: Service
name: service-name
- 1
- パスは、パスベースのルートに唯一追加される属性です。
ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、パススルー TLS を使用する場合には利用できません。
25.1.8. ルート固有のアノテーション
Ingress Controller は、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。
複数の送信元 IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、リストが警告やエラーメッセージなしに無視されます。
変数 | 説明 | デフォルトで使用される環境変数 |
---|---|---|
|
ロードバランシングアルゴリズムを設定します。使用できるオプションは、 |
パススルールートの |
|
関連の接続を追跡する cookie の使用を無効にします。 | |
| このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。 | |
|
ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。 | |
|
| |
|
同じ送信元 IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。 | |
|
同じ送信元 IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。 | |
|
同じ送信元 IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。 | |
| ルートのサーバー側のタイムアウトを設定します。(TimeUnits) |
|
| このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した WebSocket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。 |
|
|
設定できるのは、IngressController または Ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxy |
|
| バックエンドのヘルスチェックの間隔を設定します。(TimeUnits) |
|
| ルートの許可リストを設定します。許可リストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにしたリストです。許可リストに含まれていない IP アドレスからの要求は破棄されます。
| |
| edge terminated または re-encrypt ルートの Strict-Transport-Security ヘッダーを設定します。 | |
| バックエンドの要求の書き換えパスを設定します。 | |
| Cookie を制限するために値を設定します。値は以下のようになります。
この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメント を参照してください。 | |
|
ルートごとに
|
|
許可リストの IP アドレスと CIDR 範囲の数が 61 を超えると、それらは別のファイルに書き込まれます。このファイルは
haproxy.config
から参照されます。このファイルは、var/lib/haproxy/router/whitelists
フォルダーに保存されます。注記アドレスが許可リストに書き込まれることを確認するには、CIDR 範囲の完全なリストが Ingress Controller 設定ファイルに記載されていることを確認します。etcd オブジェクトサイズ制限は、ルートアノテーションのサイズを制限します。このため、許可リストに追加できる IP アドレスと CIDR 範囲の最大数のしきい値が作成されます。
環境変数を編集することはできません。
ルータータイムアウト変数
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 メトリクスの収集タイムアウト。 |
ルート設定のカスタムタイムアウト
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/timeout: 5500ms 1
...
- 1
- HAProxy 対応の単位 (
us
、ms
、s
、m
、h
、d
) で新規のタイムアウトを指定します。単位が指定されていない場合は、ms
がデフォルトになります。
パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、WebSocket 接続がそのルートで頻繁にタイムアウトする可能性があります。
特定の IP アドレスを 1 つだけ許可するルート
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
IP アドレスの CIDR ネットワークを許可するルート
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
書き換えターゲットを指定するルート
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/rewrite-target: / 1
...
- 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 |
25.1.9. ルートの受付ポリシーの設定
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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 ...
ヒントまたは、以下の YAML を適用してルートの受付ポリシーを設定できます。
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: default namespace: openshift-ingress-operator spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed
25.1.10. Ingress オブジェクトを使用したルートの作成
一部のエコシステムコンポーネントには Ingress リソースとの統合機能がありますが、ルートリソースとは統合しません。これに対応するために、OpenShift Container Platform は Ingress オブジェクトの作成時に管理されるルートオブジェクトを自動的に作成します。これらのルートオブジェクトは、対応する Ingress オブジェクトが削除されると削除されます。
手順
OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、
oc create
コマンドを実行します。Ingress の YAML 定義
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend annotations: route.openshift.io/termination: "reencrypt" 1 route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 2 spec: rules: - host: www.example.com 3 http: paths: - backend: service: name: frontend port: number: 443 path: / pathType: Prefix tls: - hosts: - www.example.com secretName: example-com-tls-certificate
- 1
route.openshift.io/termination
アノテーションは、Route
のspec.tls.termination
フィールドを設定するために使用できます。Ingress
にはこのフィールドがありません。許可される値はedge
、passthrough
、およびreencrypt
です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edge
がデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。- 3
Ingress
オブジェクトを操作する場合、ルートを操作する場合とは異なり、明示的なホスト名を指定する必要があります。<host_name>.<cluster_ingress_domain>
構文 (apps.openshiftdemos.com
など) を使用して、*.<cluster_ingress_domain>
ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。route.openshift.io/termination
アノテーションでpassthrough
の値を指定する場合は、仕様でpath
を''
に設定し、pathType
をImplementationSpecific
に設定します。spec: rules: - host: www.example.com http: paths: - path: '' pathType: ImplementationSpecific backend: service: name: frontend port: number: 443
$ oc apply -f ingress.yaml
- 2
route.openshift.io/destination-ca-certificate-secret
を Ingress オブジェクトで使用して、カスタム宛先証明書 (CA) でルートを定義できます。アノテーションは、生成されたルートに挿入される kubernetes シークレットsecret-ca-cert
を参照します。-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
data.tls.crt
指定子に PEM エンコード形式の証明書を使用してkubernetes.io/tls
またはOpaque
タイプのシークレットを作成する必要があります。
-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
ルートを一覧表示します。
$ oc get routes
結果には、
frontend-
で始まる名前の自動生成ルートが含まれます。NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
このルートを検査すると、以下のようになります。
自動生成されるルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-gnztq ownerReferences: - apiVersion: networking.k8s.io/v1 controller: true kind: Ingress name: frontend uid: 4e6c59cc-704d-4f44-b390-617d879033b6 spec: host: www.example.com path: / port: targetPort: https tls: certificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- insecureEdgeTerminationPolicy: Redirect key: | -----BEGIN RSA PRIVATE KEY----- [...] -----END RSA PRIVATE KEY----- termination: reencrypt destinationCACertificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- to: kind: Service name: frontend
25.1.11. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する
TLS 設定を指定せずに Ingress オブジェクトを作成すると、OpenShift Container Platform は安全でないルートを生成します。デフォルトの Ingress 証明書を使用してセキュアなエッジ終端ルートを生成する Ingress オブジェクトを作成するには、次のように空の TLS 設定を指定できます。
前提条件
- 公開したいサービスがあります。
-
OpenShift CLI (
oc
) にアクセスできる。
手順
Ingress オブジェクトの YAML ファイルを作成します。この例では、ファイルの名前は
example-ingress.yaml
です。Ingress オブジェクトの YAML 定義
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend ... spec: rules: ... tls: - {} 1
- 1
- この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。
次のコマンドを実行して、Ingress オブジェクトを作成します。
$ oc create -f example-ingress.yaml
検証
以下のコマンドを実行して、OpenShift Container Platform が Ingress オブジェクトの予期されるルートを作成したことを確認します。
$ oc get routes -o yaml
出力例
apiVersion: v1 items: - apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-j9sdd 1 ... spec: ... tls: 2 insecureEdgeTerminationPolicy: Redirect termination: edge 3 ...
25.1.12. Ingress アノテーションでの宛先 CA 証明書を使用したルート作成
route.openshift.io/destination-ca-certificate-secret
アノテーションを Ingress オブジェクトで使用して、カスタム宛先 CA 証明書でルートを定義できます。
前提条件
- PEM エンコードされたファイルで証明書/キーのペアを持つことができます。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
手順
route.openshift.io/destination-ca-certificate-secret
を Ingress アノテーションに追加します。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: secret-ca-cert 1 ...
- 1
- アノテーションは kubernetes シークレットを参照します。
このアノテーションで参照されているシークレットは、生成されたルートに挿入されます。
出力例
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend annotations: route.openshift.io/termination: reencrypt route.openshift.io/destination-ca-certificate-secret: secret-ca-cert spec: ... tls: insecureEdgeTerminationPolicy: Redirect termination: reencrypt destinationCACertificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- ...
25.1.13. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定
OpenShift Container Platform クラスターが IPv4 および IPv6 デュアルスタックネットワーク用に設定されている場合、クラスターは OpenShift Container Platform ルートによって外部からアクセス可能です。
Ingress Controller は、IPv4 エンドポイントと IPv6 エンドポイントの両方を持つサービスを自動的に提供しますが、シングルスタックまたはデュアルスタックサービス用に Ingress Controller を設定できます。
前提条件
- ベアメタルに OpenShift Container Platform クラスターをデプロイしていること。
-
OpenShift CLI (
oc
) がインストールされている。
手順
Ingress コントローラーが、IPv4 / IPv6 を介してトラフィックをワークロードに提供するようにするには、
ipFamilies
フィールドおよびipFamilyPolicy
フィールドを設定して、サービス YAML ファイルを作成するか、既存のサービス YAML ファイルを変更します。以下に例を示します。サービス YAML ファイルの例
apiVersion: v1 kind: Service metadata: creationTimestamp: yyyy-mm-ddT00:00:00Z labels: name: <service_name> manager: kubectl-create operation: Update time: yyyy-mm-ddT00:00:00Z name: <service_name> namespace: <namespace_name> resourceVersion: "<resource_version_number>" selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>" uid: <uid_number> spec: clusterIP: 172.30.0.0/16 clusterIPs: 1 - 172.30.0.0/16 - <second_IP_address> ipFamilies: 2 - IPv4 - IPv6 ipFamilyPolicy: RequireDualStack 3 ports: - port: 8080 protocol: TCP targetport: 8080 selector: name: <namespace_name> sessionAffinity: None type: ClusterIP status: loadbalancer: {}
これらのリソースは、対応する
endpoints
を生成します。Ingress コントローラーは、endpointslices
を監視するようになりました。endpoints
を表示するには、以下のコマンドを入力します。$ oc get endpoints
endpointslices
を表示するには、以下のコマンドを入力します。$ oc get endpointslices