第25章 ルートの作成


25.1. ルート設定

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

ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。

以下の手順では、hello-openshift アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者としてログインしている。
  • あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。

手順

  1. 次のコマンドを実行して、hello-openshift というプロジェクトを作成します。

    $ oc new-project hello-openshift
  2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

    $ oc expose pod/hello-openshift
  4. 次のコマンドを実行して、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 を設定している。

手順

  1. 次のコマンドを実行して、hello-openshift というプロジェクトを作成します。

    $ oc new-project hello-openshift
  2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

    $ oc expose pod/hello-openshift
  4. 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

    1
    ラベルキーとそれに対応するラベル値の両方が、Ingress Controller で指定されたものと一致する必要があります。この例では、Ingress コントローラーにはラベルキーと値 type: sharded があります。
    2
    ルートは、subdomain フィールドの値を使用して公開されます。subdomain フィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。host フィールドと subdomain フィールドの両方を指定すると、ルートは host フィールドの値を使用し、subdomain フィールドを無視します。
  5. 次のコマンドを実行し、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

    1
    Ingress Controller またはルーターがルートを公開するために使用するホスト名。host フィールドの値は、Ingress コントローラーによって自動的に決定され、そのドメインを使用します。この例では、Ingress コントローラーのドメインは <apps-sharded.basedomain.example.net> です。
    2
    Ingress Controller のホスト名。
    3
    Ingress Controller の名前。この例では、Ingress コントローラーの名前は sharded です。

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

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

前提条件

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

手順

  1. 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 より大きい場合、preloadhaproxy.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"

検証

  1. すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。

    $ 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 がインストールされている。

手順

  1. 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_headerpreload を含めることで、外部サービスがこのサイトをそれぞれの HSTS プリロード一覧に含めることができます。ブラウザーはこれらの一覧を使用し、サイトと対話する前でも HTTPS 経由で通信できるサイトを判別できます。preload 設定がない場合、ブラウザーは少なくともサイトと通信してヘッダーを取得する必要があります。preload は、以下のいずれかで設定できます。
    • RequirePreload: preloadRequiredHSTSPolicy で必要になります。
    • RequireNoPreload: preloadRequiredHSTSPolicy によって禁止されます。
    • NoOpinion: preloadRequiredHSTSPolicy に重要ではありません。
    6
    任意。includeSubDomainsPolicy は、以下のいずれかで設定できます。
    • RequireIncludeSubDomains: includeSubDomainsRequiredHSTSPolicy で必要です。
    • RequireNoIncludeSubDomains: includeSubDomainsRequiredHSTSPolicy によって禁止されています。
    • NoOpinion: includeSubDomainsRequiredHSTSPolicy に重要ではありません。
  2. 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 からツールを実行し、次にノードから実行して、ボトルネックを特定します。

  • 場合によっては、レイテンシーの問題が原因で、クラスターがルーター 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.7. パスベースのルート

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

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

表25.1 ルートの可用性
ルート比較対象アクセス可能

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

表25.2 ルートアノテーション
変数説明デフォルトで使用される環境変数

haproxy.router.openshift.io/balance

ロードバランシングアルゴリズムを設定します。使用できるオプションは、randomsourceroundrobin、および leastconn です。デフォルト値は、TLS パススルールートの場合、source です。他のすべてのルートの場合、デフォルトは 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 で実装されるレート制限機能が有効になります。
注記: このアノテーションを使用すると、サービス拒否攻撃に対する基本的な保護が提供されます。

 

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

このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した WebSocket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。

ROUTER_DEFAULT_TUNNEL_TIMEOUT

ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after

設定できるのは、IngressController または Ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxyhard-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 です [1]。

 

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

  1. 許可リストの 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)

変数デフォルト説明

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 に設定されています。この場合、全体的なタイムアウトは 300s5s を加えたことになります。

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 対応の単位 (usmssmhd) で新規のタイムアウトを指定します。単位が指定されていない場合は、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、要求パス、および書き換えターゲットの各種の組み合わせについてのパスの書き換え動作の例を示しています。

表25.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

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 オブジェクトが削除されると削除されます。

手順

  1. 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 アノテーションは、Routespec.tls.termination フィールドを設定するために使用できます。Ingress にはこのフィールドがありません。許可される値は edgepassthrough、および reencrypt です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edge がデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。
    3
    Ingress オブジェクトを操作する場合、ルートを操作する場合とは異なり、明示的なホスト名を指定する必要があります。<host_name>.<cluster_ingress_domain> 構文 (apps.openshiftdemos.com など) を使用して、*.<cluster_ingress_domain> ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。
    1. route.openshift.io/termination アノテーションで passthrough の値を指定する場合は、仕様で path'' に設定し、pathTypeImplementationSpecific に設定します。

        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 を参照します。
    1. Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの data.tls.crt 指定子に PEM エンコード形式の証明書を使用して kubernetes.io/tls または Opaque タイプのシークレットを作成する必要があります。
  2. ルートを一覧表示します。

    $ 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) にアクセスできる。

手順

  1. Ingress オブジェクトの YAML ファイルを作成します。この例では、ファイルの名前は example-ingress.yaml です。

    Ingress オブジェクトの YAML 定義

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      ...
    spec:
      rules:
        ...
      tls:
      - {} 1

    1
    この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。
  2. 次のコマンドを実行して、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 の終了ポリシーを指定する必要があります。

25.1.12. Ingress アノテーションでの宛先 CA 証明書を使用したルート作成

route.openshift.io/destination-ca-certificate-secret アノテーションを Ingress オブジェクトで使用して、カスタム宛先 CA 証明書でルートを定義できます。

前提条件

  • PEM エンコードされたファイルで証明書/キーのペアを持つことができます。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。

手順

  1. 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 シークレットを参照します。
  2. このアノテーションで参照されているシークレットは、生成されたルートに挿入されます。

    出力例

    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) がインストールされている。

手順

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

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

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

  2. endpoints を表示するには、以下のコマンドを入力します。

    $ oc get endpoints
  3. endpointslices を表示するには、以下のコマンドを入力します。

    $ oc get endpointslices
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.