第20章ルートの作成

20.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 リソースを検査すると、以下のようになります。
上記で作成されたセキュアでないルートの 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}
```

20.1.2. ルートのタイムアウトの設定

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
```

20.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 またはパススルールートには適していません。

20.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;\ 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 回対話している必要があります。

20.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"
```
ヒント
または、以下の YAML を適用して ConfigMap を作成できます。
ルートごとに HSTS を無効にする例
```
metadata:
  annotations:
    haproxy.router.openshift.io/hsts_header: max-age=0
```

namespace のすべてのルートで HSTS を無効にするには、followinf コマンドを入力します。

$ 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

20.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
```
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

20.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> 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 ソリューションを参照してください。

20.1.5. Cookie に使用によるルートのステートフル性の維持

OpenShift Container Platform は、すべてのトラフィックを同じエンドポイントにヒットさせることによりステートフルなアプリケーションのトラフィックを可能にするスティッキーセッションを提供します。ただし、エンドポイント Pod が再起動、スケーリング、または設定の変更などによって終了する場合、このステートフル性はなくなります。

OpenShift Container Platform は Cookie を使用してセッションの永続化を設定できます。Ingress Controller はユーザー要求を処理するエンドポイントを選択し、そのセッションの Cookie を作成します。Cookie は要求の応答として戻され、ユーザーは Cookie をセッションの次の要求と共に送り返します。Cookie は Ingress Controller に対し、セッションを処理しているエンドポイントを示し、クライアント要求が Cookie を使用して同じ Pod にルーティングされるようにします。

注記

cookie は、HTTP トラフィックを表示できないので、パススルールートで設定できません。代わりに、ソース IP アドレスをベースに数が計算され、バックエンドを判断します。

バックエンドが変わると、トラフィックが間違ったサーバーに転送されてしまい、スティッキーではなくなります。ソース IP を非表示にするロードバランサーを使用している場合は、すべての接続に同じ番号が設定され、トラフィックは同じ Pod に送られます。

20.1.6. パスベースのルート

パスベースのルートは、URL に対して比較できるパスコンポーネントを指定します。この場合、ルートのトラフィックは HTTP ベースである必要があります。そのため、それぞれが異なるパスを持つ同じホスト名を使用して複数のルートを提供できます。ルーターは、最も具体的なパスの順に基づいてルートと一致する必要があります。ただし、これはルーターの実装によって異なります。

以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。

表20.1 ルートの可用性
ルート	比較対象	アクセス可能
www.example.com/test	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/test および www.example.com	www.example.com	はい
www.example.com	www.example.com/text	Yes (ルートではなく、ホストで一致)
www.example.com	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 を使用する場合には利用できません。

20.1.7. ルート固有のアノテーション

Ingress Controller は、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。

重要

複数のソース IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、リストが警告やエラーメッセージなしに無視されます。

表20.2 ルートアノテーション
変数	説明	デフォルトで使用される環境変数
`haproxy.router.openshift.io/balance`	ロードバランシングアルゴリズムを設定します。使用できるオプションは、`random`、 `source`、`roundrobin`、および `leastconn` です。デフォルト値は `random` です。	パススルールートの `ROUTER_TCP_BALANCE_SCHEME` です。それ以外の場合は `ROUTER_LOAD_BALANCE_ALGORITHM` を使用します。
`haproxy.router.openshift.io/disable_cookies`	関連の接続を追跡する cookie の使用を無効にします。`'true'` または `'TRUE'` に設定する場合は、分散アルゴリズムを使用して、受信する HTTP 要求ごとに、どのバックエンドが接続を提供するかを選択します。
`router.openshift.io/cookie_name`	このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。
`haproxy.router.openshift.io/pod-concurrent-connections`	ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。注意: Pod が複数ある場合には、それぞれに対応する接続数を設定できます。複数のルーターがある場合は、それらのルーター間で調整は行われず、それぞれがこれに複数回接続する可能性があります。設定されていない場合または 0 に設定されている場合には制限はありません。
`haproxy.router.openshift.io/rate-limit-connections`	`'true'` または `'TRUE'` を設定すると、ルートごとに特定のバックエンドの stick-tables で実装されるレート制限機能が有効になります。注記: このアノテーションを使用すると、DDoS (Distributed Denial-of-service) 攻撃に対する基本的な保護機能が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp`	同じソース IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。注記: このアノテーションを使用すると、DDoS (Distributed Denial-of-service) 攻撃に対する基本的な保護機能が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.rate-http`	同じソース IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。注記: このアノテーションを使用すると、DDoS (Distributed Denial-of-service) 攻撃に対する基本的な保護機能が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.rate-tcp`	同じソース IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。注記: このアノテーションを使用すると、DDoS (Distributed Denial-of-service) 攻撃に対する基本的な保護機能が提供されます。
`haproxy.router.openshift.io/timeout`	ルートのサーバー側のタイムアウトを設定します。(TimeUnits)	`ROUTER_DEFAULT_SERVER_TIMEOUT`
`haproxy.router.openshift.io/timeout-tunnel`	このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した Web Socket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。	`ROUTER_DEFAULT_TUNNEL_TIMEOUT`
`ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after`	設定できるのは、Ingress Controller または ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxy`hard-stop-after` グローバルオプションを実行するように設定します。このオプションは、クリーンなソフトストップの実行に許容される最大時間を定義します。	`ROUTER_HARD_STOP_AFTER`
`router.openshift.io/haproxy.health.check.interval`	バックエンドのヘルスチェックの間隔を設定します。(TimeUnits)	`ROUTER_BACKEND_CHECK_INTERVAL`
`haproxy.router.openshift.io/ip_whitelist`	ルートのホワイトリストを設定します。ホワイトリストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにします。ホワイトリストに含まれていない IP アドレスからの要求は破棄されます。ホワイトリストの許可される IP アドレスおよび CIDR 範囲の最大数は 61 です。
`haproxy.router.openshift.io/hsts_header`	edge terminated または re-encrypt ルートの Strick-Transport-Security ヘッダーを設定します。
`haproxy.router.openshift.io/log-send-hostname`	Syslog ヘッダーの `hostname` フィールドを設定します。システムのホスト名を使用します。サイドカーや Syslog ファシリティーなどの Ingress API ロギングメソッドがルーターに対して有効になっている場合、`log-send-hostname` はデフォルトで有効になります。
`haproxy.router.openshift.io/rewrite-target`	バックエンドの要求の書き換えパスを設定します。
`router.openshift.io/cookie-same-site`	Cookie を制限するために値を設定します。値は以下のようになります。 `Lax`: Cookie はアクセスしたサイトとサードパーティーのサイト間で転送されます。 `Strict`: Cookie はアクセスしたサイトに制限されます。 `None`: Cookie はアクセスしたサイトに制限されます。この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメントを参照してください。
`haproxy.router.openshift.io/set-forwarded-headers`	ルートごとに `Forwarded` および `X-Forwarded-For` HTTP ヘッダーを処理するポリシーを設定します。値は以下のようになります。 `append`: ヘッダーを追加し、既存のヘッダーを保持します。これはデフォルト値です。 `Replace`: ヘッダーを設定し、既存のヘッダーを削除します。 `never`: ヘッダーを設定しませんが、既存のヘッダーを保持します。 `if-none`: ヘッダーがまだ設定されていない場合にこれを設定します。	`ROUTER_SET_FORWARDED_HEADERS`

注記

環境変数を編集することはできません。

ルータータイムアウト変数

TimeUnits は数字、その後に単位を指定して表現します。us *(マイクロ秒)、ms (ミリ秒、デフォルト)、s (秒)、m (分)、h *(時間)、d (日)

正規表現: [1-9][0-9]*(us\|ms\|s\|m\|h\|d)

変数	デフォルト	説明
`ROUTER_BACKEND_CHECK_INTERVAL`	`5000ms`	バックエンドでの後続の liveness チェックの時間の長さ。
`ROUTER_CLIENT_FIN_TIMEOUT`	`1s`	クライアントがルートに接続する場合の TCP FIN タイムアウトの期間を制御します。接続切断のために送信された FIN が指定の時間内に応答されない場合は、HAProxy が接続を切断します。小さい値を設定し、ルーターでリソースをあまり使用していない場合には、リスクはありません。
`ROUTER_DEFAULT_CLIENT_TIMEOUT`	`30s`	クライアントがデータを確認するか、送信するための時間の長さ。
`ROUTER_DEFAULT_CONNECT_TIMEOUT`	`5s`	最大接続時間。
`ROUTER_DEFAULT_SERVER_FIN_TIMEOUT`	`1s`	ルーターからルートをバッキングする Pod の TCP FIN タイムアウトを制御します。
`ROUTER_DEFAULT_SERVER_TIMEOUT`	`30s`	サーバーがデータを確認するか、送信するための時間の長さ。
`ROUTER_DEFAULT_TUNNEL_TIMEOUT`	`1h`	TCP または WebSocket 接続が開放された状態で保つ時間数。このタイムアウト期間は、HAProxy が再読み込みされるたびにリセットされます。
`ROUTER_SLOWLORIS_HTTP_KEEPALIVE`	`300s`	新しい HTTP 要求が表示されるまで待機する最大時間を設定します。この値が低すぎる場合には、ブラウザーおよびアプリケーションの `keepalive` 値が低くなりすぎて、問題が発生する可能性があります。有効なタイムアウト値には、想定した個別のタイムアウトではなく、特定の変数を合計した値に指定することができます。たとえば、`ROUTER_SLOWLORIS_HTTP_KEEPALIVE` は、`timeout http-keep-alive` を調整します。HAProxy はデフォルトで `300s` に設定されていますが、HAProxy は `tcp-request inspect-delay` も待機します。これは `5s` に設定されています。この場合、全体的なタイムアウトは `300s` に `5s` を加えたことになります。
`ROUTER_SLOWLORIS_TIMEOUT`	`10s`	HTTP 要求の伝送にかかる時間。
`RELOAD_INTERVAL`	`5s`	ルーターがリロードし、新規の変更を受け入れる最小の頻度を許可します。
`ROUTER_METRICS_HAPROXY_TIMEOUT`	`5s`	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 Controller がこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。

以下の表は、spec.path、要求パス、および書き換えターゲットの各種の組み合わせについてのパスの書き換え動作の例を示しています。

表20.3 rewrite-target の例:
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

20.1.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
...

ヒント

または、以下の YAML を適用してルートの受付ポリシーを設定できます。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed

20.1.9. Ingress オブジェクトを使用したルートの作成

一部のエコシステムコンポーネントには Ingress リソースとの統合機能がありますが、Route リソースとは統合しません。これに対応するために、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
spec:
  rules:
  - host: www.example.com 2
    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 証明書の詳細を定義して、デフォルトのエッジルートを実装し、安全でないルートが生成されないようにする必要があります。
2
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
```

ルートを一覧表示します。

$ 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
  to:
    kind: Service
    name: frontend

20.1.10. 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
  ...
```
1
ルートの名前には、Ingress オブジェクトの名前とそれに続くランダムな接尾辞が含まれます。
2
デフォルトの証明書を使用するには、ルートで spec.certificate を指定しないでください。
3
ルートは、edge の終了ポリシーを指定する必要があります。

20.1.11. デュアルスタックネットワーク用の 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 Controller が、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: {}
```
1
デュアルスタックインスタンスでは、2 つの異なる clusterIPs が提供されます。
2
シングルスタックインスタンスの場合は、IPv4 または IPv6 と入力します。デュアルスタックインスタンスの場合は、IPv4 と IPv6 の両方を入力します。
3
シングルスタックインスタンスの場合は、SingleStack と入力します。デュアルスタックインスタンスの場合は、RequireDualStack と入力します。
これらのリソースは、対応する endpoints を生成します。Ingress Controller は、endpointslices を監視するようになりました。
endpoints を表示するには、以下のコマンドを入力します。
```
$ oc get endpoints
```
endpointslices を表示するには、以下のコマンドを入力します。
```
$ oc get endpointslices
```

関連情報

appsDomain オプションを使用した代替クラスタードメインの指定

20.1. ルート設定

20.1.1. HTTP ベースのルートの作成

20.1.2. ルートのタイムアウトの設定

20.1.3. HTTP Strict Transport Security

20.1.3.1. ルートごとの HTTP Strict Transport Security の有効化

20.1.3.2. ルートごとの HTTP Strict Transport Security の無効化

20.1.3.3. ドメインごとに HTTP Strict Transport Security の強制

20.1.4. スループット関連の問題のトラブルシューティング

20.1.5. Cookie に使用によるルートのステートフル性の維持

20.1.6. パスベースのルート

20.1.7. ルート固有のアノテーション

20.1.8. ルートの受付ポリシーの設定

20.1.9. Ingress オブジェクトを使用したルートの作成

20.1.10. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する

20.1.11. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第20章 ルートの作成

20.1. ルート設定

20.1.1. HTTP ベースのルートの作成

20.1.2. ルートのタイムアウトの設定

20.1.3. HTTP Strict Transport Security

20.1.3.1. ルートごとの HTTP Strict Transport Security の有効化

20.1.3.2. ルートごとの HTTP Strict Transport Security の無効化

20.1.3.3. ドメインごとに HTTP Strict Transport Security の強制

20.1.4. スループット関連の問題のトラブルシューティング

20.1.5. Cookie に使用によるルートのステートフル性の維持

20.1.5.1. Cookie を使用したルートのアノテーション

20.1.6. パスベースのルート

20.1.7. ルート固有のアノテーション

20.1.8. ルートの受付ポリシーの設定

20.1.9. Ingress オブジェクトを使用したルートの作成

20.1.10. Ingress オブジェクトを介してデフォルトの証明書を使用してルートを作成する

20.1.11. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第20章ルートの作成