1.3. ルートの設定

1.3.1. ルートのタイムアウトの設定
リンクのコピー

Service Level Availability (SLA) で必要とされる、低タイムアウトが必要なサービスや、バックエンドでの処理速度が遅いケースで高タイムアウトが必要なサービスがある場合は、既存のルートに対してデフォルトのタイムアウトを設定することができます。

重要

OpenShift Container Platform クラスターの前にユーザー管理の外部ロードバランサーを設定した場合は、ユーザー管理の外部ロードバランサーのタイムアウト値がルートのタイムアウト値よりも高いことを確認してください。この設定により、クラスターが使用するネットワーク上でのネットワーク輻輳の問題を防ぐことができます。

前提条件

実行中のクラスターでデプロイ済みの Ingress Controller が必要になります。

手順

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 Toggle word wrap
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 Toggle word wrap

OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。

注記

IngressController または Route CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions の代わりに spec.httpHeaders.forwardedHeaderPolicy フィールドを使用します。

1.3.2.1. 優先順位
リンクのコピー

同じ HTTP ヘッダーを Ingress Controller とルートの両方で変更すると、HAProxy は、それがリクエストヘッダーであるか応答ヘッダーであるかに応じて、特定の方法でアクションの優先順位を付けます。

HTTP 応答ヘッダーの場合、Ingress Controller で指定されたアクションは、ルートで指定されたアクションの後に実行されます。これは、Ingress Controller で指定されたアクションが優先されることを意味します。
HTTP リクエストヘッダーの場合、ルートで指定されたアクションは、Ingress Controller で指定されたアクションの後に実行されます。これは、ルートで指定されたアクションが優先されることを意味します。

たとえば、クラスター管理者は、次の設定を使用して、Ingress Controller で X-Frame-Options 応答ヘッダーに値 DENY を設定します。

IngressController 仕様の例

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

Copy to Clipboard

Toggle word wrap

ルート所有者は、クラスター管理者が Ingress Controller に設定したものと同じ応答ヘッダーを設定しますが、次の設定を使用して値 SAMEORIGIN を設定します。

Route 仕様の例

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

Copy to Clipboard

Toggle word wrap

IngressController 仕様と Route 仕様の両方で X-Frame-Options 応答ヘッダーが設定されている場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。リクエストヘッダーの場合、Route 仕様の値が IngressController 仕様の値をオーバーライドします。

この優先順位付けは、haproxy.config ファイルで次のロジックが使用されるため発生します。このロジックでは、Ingress Controller がフロントエンドと見なされ、個々のルートがバックエンドと見なされます。フロントエンド設定に適用されるヘッダー値 DENY は、バックエンドで設定されている値 SAMEORIGIN で同じヘッダーをオーバーライドします。

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

Copy to Clipboard

Toggle word wrap

さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。

1.3.2.2. 特殊なケースのヘッダー
リンクのコピー

次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。

Expand

表1.2 特殊な場合のヘッダー設定オプション
ヘッダー名	`IngressController` 仕様を使用して設定可能かどうか	`Route` 仕様を使用して設定可能かどうか	不許可の理由	別の方法で設定可能かどうか
`proxy`	いいえ	いいえ	`プロキシー` HTTP リクエストヘッダーを使用し、ヘッダー値を `HTTP_PROXY` 環境変数に注入して、脆弱な CGI アプリケーションを悪用できます。`プロキシー` HTTP リクエストヘッダーも標準ではないため、設定中にエラーが発生しやすくなります。	いいえ
`host`	いいえ	はい	`IngressController` CR を使用して `ホスト` HTTP 要求ヘッダーが設定されている場合、HAProxy は正しいルートを検索するときに失敗する可能性があります。	いいえ
`strict-transport-security`	いいえ	いいえ	`strict-transport-security` HTTP 応答ヘッダーはルートアノテーションを使用してすでに処理されているため、別の実装は必要ありません。	はい: `haproxy.router.openshift.io/hsts_header` ルートアノテーション
`cookie` と `set-cookie`	いいえ	いいえ	HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。	はい: `haproxy.router.openshift.io/disable_cookie` ルートアノテーション `haproxy.router.openshift.io/cookie_name` ルートアノテーション

1.3.3. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除
リンクのコピー

コンプライアンス目的またはその他の理由で、特定の HTTP 要求および応答ヘッダーを設定または削除できます。これらのヘッダーは、Ingress Controller によって提供されるすべてのルート、または特定のルートに対して設定または削除できます。

たとえば、ルートを提供する Ingress Controller によってデフォルトのグローバルな場所が指定されている場合でも、コンテンツが複数の言語で記述されていると、Web アプリケーションが特定のルートの別の場所でコンテンツを提供するように指定できます。

以下の手順では Content-Location HTTP リクエストヘッダーを設定するルートを作成し、アプリケーション (https://app.example.com) に URL が関連付けられ、https://app.example.com/lang/en-us のロケーションにダイレクトされるようにします。アプリケーショントラフィックをこの場所にダイレクトすると、特定のルートを使用する場合はすべて、アメリカ英語で記載された Web コンテンツにアクセスすることになります。

前提条件

OpenShift CLI (oc) がインストールされている。
プロジェクト管理者として OpenShift Container Platform クラスターにログインしている。
ポートを公開する Web アプリケーションと、そのポート上のトラフィックをリッスンする HTTP または TLS エンドポイントがある。

手順

ルート定義を作成し、app-example-route.yaml というファイルに保存します。
HTTP ヘッダーディレクティブを使用して作成されたルートの YAML 定義
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
      response: 
      - name: Content-Location 
        action:
          type: Set 
          set:
            value: /lang/en-us 
```
```
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  host: app.example.com
  tls:
    termination: edge
  to:
    kind: Service
    name: app-example
  httpHeaders:
    actions: 
```
1
```
      response: 
```
2
```
      - name: Content-Location 
```
3
```
        action:
          type: Set 
```
4
```
          set:
            value: /lang/en-us 
```
5
Copy to Clipboard Toggle word wrap
1
HTTP ヘッダーに対して実行するアクションのリスト。
2
変更するヘッダーのタイプ。この場合は、応答ヘッダーです。
3
変更するヘッダーの名前。設定または削除できる使用可能なヘッダーのリストは、HTTP ヘッダーの設定 を参照してください。
4
ヘッダーに対して実行されるアクションのタイプ。このフィールドには、Set または Delete の値を指定できます。
5
HTTP ヘッダーの設定時は、値 を指定する必要があります。値は、そのヘッダーで使用可能なディレクティブのリストからの文字列 (例: DENY) にすることも、HAProxy の動的値構文を使用して解釈される動的値にすることもできます。この場合、値はコンテンツの相対位置に設定されます。
新しく作成したルート定義を使用して、既存の Web アプリケーションへのルートを作成します。
```
oc -n app-example create -f app-example-route.yaml
```
```
$ oc -n app-example create -f app-example-route.yaml
```
Copy to Clipboard Toggle word wrap

HTTP リクエストヘッダーの場合、ルート定義で指定されたアクションは、Ingress Controller の HTTP リクエストヘッダーに対して実行されたアクションの後に実行されます。これは、ルート内のこれらのリクエストヘッダーに設定された値が、Ingress Controller に設定された値よりも優先されることを意味します。HTTP ヘッダーの処理順序の詳細は、HTTP ヘッダーの設定 を参照してください。

1.3.4. Cookie の使用によるルートのステートフル性の維持
リンクのコピー

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

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

注記

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

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

1.3.4.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 Toggle word wrap
ここでは、以下のようになります。
<route_name>
ルートの名前を指定します。
<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 Toggle word wrap
変数でルートのホスト名を取得します。
```
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 Toggle word wrap
ここでは、以下のようになります。
<route_name>
ルートの名前を指定します。
cookie を保存してからルートにアクセスします。
```
curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap
ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。
```
curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
```
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
```
Copy to Clipboard Toggle word wrap

1.3.5. ルート固有のアノテーション
リンクのコピー

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

重要

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

Expand

表1.3 ルートアノテーション
変数	説明	デフォルトで使用される環境変数
`haproxy.router.openshift.io/balance`	ロードバランシングアルゴリズムを設定します。使用できるオプションは、`random`、`source`、`roundrobin`[¹]、`leastconn` です。デフォルト値は、TLS passthrough ルートの場合、`source` です。他のすべてのルートの場合、デフォルトは `random` です。	passthrough ルートの `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 で実装されるレート制限機能が有効になります。注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp`	同じ送信元 IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.rate-http`	同じ送信元 IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。
`haproxy.router.openshift.io/rate-limit-connections.rate-tcp`	同じ送信元 IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。
`haproxy.router.openshift.io/timeout`	ルートのサーバー側のタイムアウトを設定します。(TimeUnits)	`ROUTER_DEFAULT_SERVER_TIMEOUT`
`haproxy.router.openshift.io/timeout-tunnel`	このタイムアウトは、cleartext、edge、reencrypt、または passthrough のルートを介した WebSocket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。passthrough のルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。	`ROUTER_DEFAULT_TUNNEL_TIMEOUT`
`ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after`	設定できるのは、IngressController または 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 アドレスからの要求は破棄されます。 `haproxy.config` ファイルで直接表示される IP アドレスと CIDR 範囲の最大数は 61 です [²]。
`haproxy.router.openshift.io/hsts_header`	edge terminated または re-encrypt ルートの Strict-Transport-Security ヘッダーを設定します。
`haproxy.router.openshift.io/rewrite-target`	バックエンドの要求の書き換えパスを設定します。
`router.openshift.io/cookie-same-site`	Cookie を制限するために値を設定します。値は以下のようになります。 `Lax`: ブラウザーは、クロスサイト要求では Cookie を送信しませんが、ユーザーが外部サイトから元のサイトに移動するときに Cookie を送信します。これは、`SameSite` 値が指定されていない場合のブラウザーのデフォルトの動作です。 `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`

デフォルトでは、ルーターは 5 秒ごとにリロードされ、最初から Pod 間の接続のバランスがリセットされます。その結果、roundrobin 状態はリロード間で保持されません。このアルゴリズムは、Pod のコンピューティング能力とストレージ容量がほぼ同じである場合に最適に機能します。たとえば、CI/CD パイプラインの使用により、アプリケーションまたはサービスのエンドポイントが継続的に変更される場合、結果的にバランスが不均一になる可能性があります。その場合は別のアルゴリズムを使用します。
許可リストの IP アドレスと CIDR 範囲の数が 61 を超えると、それらは別のファイルに書き込まれます。これは haproxy.config ファイルから参照されます。このファイルは、/var/lib/haproxy/router/allowlists フォルダーに保存されます。
注記
アドレスが許可リストに書き込まれることを確認するには、CIDR 範囲の完全なリストが Ingress Controller 設定ファイルに記載されていることを確認します。etcd オブジェクトサイズ制限は、ルートアノテーションのサイズを制限します。このため、許可リストに追加できる IP アドレスと CIDR 範囲の最大数のしきい値が作成されます。

注記

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

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

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

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

Expand

変数	デフォルト	説明
`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 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms

1

...

Copy to Clipboard

Toggle word wrap

1: HAProxy 対応の単位 (us、ms、s、m、h、d) で新規のタイムアウトを指定します。単位が指定されていない場合は、ms がデフォルトになります。

注記

passthrough ルートのサーバー側のタイムアウト値を低く設定し過ぎると、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

Copy to Clipboard

Toggle word wrap

複数の 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

Copy to Clipboard

Toggle word wrap

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

Copy to Clipboard

Toggle word wrap

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

Copy to Clipboard

Toggle word wrap

書き換えターゲットを指定するルート

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / 
...

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: /

1

...

Copy to Clipboard

Toggle word wrap

1: バックエンドの要求の書き換えパスとして / を設定します。

ルートに haproxy.router.openshift.io/rewrite-target アノテーションを設定すると、要求をバックエンドアプリケーションに転送する前に Ingress Controller がこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。

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

Expand

表1.4 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

haproxy.router.openshift.io/rewrite-target 内の特定の特殊文字は、適切にエスケープする必要があるため、特別な処理が必要です。これらの文字がどのように処理されるかは、次の表を参照してください。

Expand

表1.5 特殊文字の取り扱い
以下の文字の場合	以下の文字を使用	注記
#	\#	# は書き換え式を終了させるので使用しないでください。
%	% または %%	%%% のような変則的なシーケンスは避けてください。
‘	\’	‘ は無視されるので避けてください。

その他の有効な URL 文字はすべてエスケープせずに使用できます。

1.3.6. スループットの問題のトラブルシューティング方法
リンクのコピー

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>
```
```
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2> 
```
1
Copy to Clipboard Toggle word wrap
1
podip は Pod の IP アドレスです。oc get pod <pod_name> -o wide コマンドを実行して Pod の IP アドレスを取得します。
tcpdump は、これらの 2 つの Pod 間のすべてのトラフィックが含まれる /tmp/dump.pcap のファイルを生成します。ファイルサイズを最小限に抑えるために問題を再現するすぐ前と問題を再現したすぐ後ににアナライザーを実行することが良いでしょう。次のコマンドを使用して、ノード間でパケットアナライザーを実行することもできます。
```
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 Toggle word wrap
ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。最初に Pod からツールを実行し、次にノードから実行して、ボトルネックを特定します。
- iperf のインストールおよび使用に関する詳細は、こちらの Red Hat ソリューションを参照してください。
場合によっては、レイテンシーの問題が原因で、クラスターがルーター Pod を含むノードを異常としてマークすることがあります。ワーカーレイテンシープロファイルを使用して、アクションを実行する前にクラスターがノードからステータスの最新情報を受け取る頻度を調節します。
クラスターでレイテンシーの低いノードとレイテンシーの高いノードが指定されている場合は、Ingress Controller の spec.nodePlacement フィールドを設定して、ルーター Pod の配置を制御します。

1.3.7. ルートの受付ポリシーの設定
リンクのコピー

管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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

Toggle word wrap

イメージコントローラー設定例

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

spec:
  routeAdmission:
    namespaceOwnership: InterNamespaceAllowed
...

Copy to Clipboard

Toggle word wrap

ヒント

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

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

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

Copy to Clipboard

Toggle word wrap

1.3.8. デュアルスタックネットワーク用の 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: 
  - 172.30.0.0/16
  - <second_IP_address>
  ipFamilies: 
  - IPv4
  - IPv6
  ipFamilyPolicy: RequireDualStack 
  ports:
  - port: 8080
    protocol: TCP
    targetport: 8080
  selector:
    name: <namespace_name>
  sessionAffinity: None
  type: ClusterIP
status:
  loadbalancer: {}

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: {}

Copy to Clipboard

Toggle word wrap

1: デュアルスタックインスタンスでは、2 つの異なる clusterIPs が提供されます。
2: シングルスタックインスタンスの場合は、IPv4 または IPv6 と入力します。デュアルスタックインスタンスの場合は、IPv4 と IPv6 の両方を入力します。
3: シングルスタックインスタンスの場合は、SingleStack と入力します。デュアルスタックインスタンスの場合は、RequireDualStack と入力します。

これらのリソースは、対応する endpoints を生成します。Ingress Controller は、endpointslices を監視するようになりました。

endpoints を表示するには、以下のコマンドを入力します。
```
oc get endpoints
```
```
$ oc get endpoints
```
Copy to Clipboard Toggle word wrap
endpointslices を表示するには、以下のコマンドを入力します。
```
oc get endpointslices
```
```
$ oc get endpointslices
```
Copy to Clipboard Toggle word wrap

1.3.1. ルートのタイムアウトの設定
リンクのコピー

1.3.2. HTTP ヘッダーの設定
リンクのコピー

1.3.2.1. 優先順位
リンクのコピー

1.3.2.2. 特殊なケースのヘッダー
リンクのコピー

1.3.3. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除
リンクのコピー

1.3.4. Cookie の使用によるルートのステートフル性の維持
リンクのコピー

1.3.5. ルート固有のアノテーション
リンクのコピー

1.3.6. スループットの問題のトラブルシューティング方法
リンクのコピー

1.3.7. ルートの受付ポリシーの設定
リンクのコピー

1.3.8. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.3. ルートの設定

1.3.1. ルートのタイムアウトの設定リンクのコピーリンクがクリップボードにコピーされました!

1.3.2. HTTP ヘッダーの設定リンクのコピーリンクがクリップボードにコピーされました!

1.3.2.1. 優先順位リンクのコピーリンクがクリップボードにコピーされました!

1.3.2.2. 特殊なケースのヘッダーリンクのコピーリンクがクリップボードにコピーされました!

1.3.3. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除リンクのコピーリンクがクリップボードにコピーされました!

1.3.4. Cookie の使用によるルートのステートフル性の維持リンクのコピーリンクがクリップボードにコピーされました!

1.3.4.1. Cookie を使用したルートのアノテーションリンクのコピーリンクがクリップボードにコピーされました!

1.3.5. ルート固有のアノテーションリンクのコピーリンクがクリップボードにコピーされました!

1.3.6. スループットの問題のトラブルシューティング方法リンクのコピーリンクがクリップボードにコピーされました!

1.3.7. ルートの受付ポリシーの設定リンクのコピーリンクがクリップボードにコピーされました!

1.3.8. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.3.1. ルートのタイムアウトの設定
リンクのコピー

1.3.2. HTTP ヘッダーの設定
リンクのコピー

1.3.2.1. 優先順位
リンクのコピー

1.3.2.2. 特殊なケースのヘッダー
リンクのコピー

1.3.3. ルート内の HTTP リクエストおよびレスポンスヘッダーの設定または削除
リンクのコピー

1.3.4. Cookie の使用によるルートのステートフル性の維持
リンクのコピー

1.3.4.1. Cookie を使用したルートのアノテーション
リンクのコピー

1.3.5. ルート固有のアノテーション
リンクのコピー

1.3.6. スループットの問題のトラブルシューティング方法
リンクのコピー

1.3.7. ルートの受付ポリシーの設定
リンクのコピー

1.3.8. デュアルスタックネットワーク用の OpenShift Container Platform Ingress Controller の設定
リンクのコピー