Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.3. ルートの設定

アノテーション、ヘッダー、Cookie などを使用して、ルート設定をカスタマイズできます。

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

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

重要

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

前提条件

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

手順

  • oc annotate コマンドを使用して、ルートにタイムアウトを追加します。 

    $ 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
    Copy to Clipboard Toggle word wrap

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

OpenShift Dedicated は、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
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
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'
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 Dedicated クラスターにログインしている。
  • ポートを公開する Web アプリケーションと、そのポート上のトラフィックをリッスンする HTTP または TLS エンドポイントがある。

手順

  1. ルート定義を作成し、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:
    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 の動的値構文を使用して解釈される動的値にすることもできます。この場合、値はコンテンツの相対位置に設定されます。

  2. 新しく作成したルート定義を使用して、既存の Web アプリケーションへのルートを作成します。 

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

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

注記

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

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

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

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

重要

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

Expand
表1.3 ルートアノテーション
変数説明

haproxy.router.openshift.io/balance

ロードバランシングアルゴリズムを設定します。使用できるオプションは、random、source、roundrobin[1]、leastconn です。デフォルト値は、TLS passthrough ルートの場合、source です。他のすべてのルートの場合、デフォルトは random です。

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 接続を確立するレートを制限します。数値を受け入れます。

router.openshift.io/haproxy.health.check.interval

バックエンドのヘルスチェックの間隔を設定します。(TimeUnits)

haproxy.router.openshift.io/ip_allowlist

ルートの許可リストを設定します。許可リストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにしたリストです。許可リストに含まれていない IP アドレスからの要求は破棄されます。

haproxy.config ファイルで直接表示される IP アドレスと CIDR 範囲の最大数は 61 です [2]。

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: ヘッダーがまだ設定されていない場合にこれを設定します。

  1. デフォルトでは、ルーターは 5 秒ごとにリロードされ、最初から Pod 間の接続のバランスがリセットされます。その結果、roundrobin 状態はリロード間で保持されません。このアルゴリズムは、Pod のコンピューティング能力とストレージ容量がほぼ同じである場合に最適に機能します。たとえば、CI/CD パイプラインの使用により、アプリケーションまたはサービスのエンドポイントが継続的に変更される場合、結果的にバランスが不均一になる可能性があります。その場合は別のアルゴリズムを使用します。

  2. 許可リストの IP アドレスと CIDR 範囲の数が 61 を超えると、それらは別のファイルに書き込まれます。これは haproxy.config ファイルから参照されます。このファイルは、/var/lib/haproxy/router/allowlists フォルダーに保存されます。

    注記

    アドレスが許可リストに書き込まれることを確認するには、CIDR 範囲の完全なリストが Ingress Controller 設定ファイルに記載されていることを確認します。etcd オブジェクトサイズ制限は、ルートアノテーションのサイズを制限します。このため、許可リストに追加できる IP アドレスと CIDR 範囲の最大数のしきい値が作成されます。

特定の IP アドレスを 1 つだけ許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.10
Copy to Clipboard Toggle word wrap

複数の IP アドレスを許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 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_allowlist: 192.168.1.0/24
Copy to Clipboard Toggle word wrap

IP アドレスと IP アドレスの CIDR ネットワークの両方を許可するルート

metadata:
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 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: /
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 Dedicated を使用してデプロイされるアプリケーションでは、特定のサービス間で非常に長い待ち時間が発生するなど、ネットワークのスループットの問題が発生する可能性があります。

Pod のログが問題の原因を指摘しない場合は、以下の方法を使用してパフォーマンスの問題を分析します。

  • ping または tcpdump などのパケットアナライザーを使用して Pod とそのノード間のトラフィックを分析します。

    たとえば、問題を生じさせる動作を再現している間に各ノードで tcpdump ツールを実行 します。両サイトでキャプチャーしたデータを確認し、送信および受信タイムスタンプを比較して Pod への/からのトラフィックの待ち時間を分析します。待ち時間は、ノードのインターフェイスが他の Pod やストレージデバイス、またはデータプレーンからのトラフィックでオーバーロードする場合に OpenShift Dedicated で発生する可能性があります。 

    $ 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
    Copy to Clipboard Toggle word wrap
  • ストリーミングのスループットおよび UDP スループットを測定するために iperf などの帯域幅測定ツールを使用します。最初に Pod からツールを実行し、次にノードから実行して、ボトルネックを特定します。
  • 場合によっては、レイテンシーの問題が原因で、クラスターがルーター Pod を含むノードを異常としてマークすることがあります。ワーカーレイテンシープロファイルを使用して、アクションを実行する前にクラスターがノードからステータスの最新情報を受け取る頻度を調節します。
  • クラスターでレイテンシーの低いノードとレイテンシーの高いノードが指定されている場合は、Ingress Controller の spec.nodePlacement フィールドを設定して、ルーター Pod の配置を制御します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat