第26章 ルートの作成
26.1. ルート設定
26.1.1. HTTP ベースのルートの作成
ルートを使用すると、公開された URL でアプリケーションをホストできます。これは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティー保護または保護なしを指定できます。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
以下の手順では、hello-openshift
アプリケーションを例に、Web アプリケーションへのシンプルな HTTP ベースのルートを作成する方法を説明します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshift
Copy to Clipboard Copied! 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
Copy to Clipboard Copied! 以下のコマンドを実行して、
hello-openshift
というサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshift
Copy to Clipboard Copied! 次のコマンドを実行して、
hello-openshift
アプリケーションに対して、セキュアではないルートを作成します。oc expose svc hello-openshift
$ oc expose svc hello-openshift
Copy to Clipboard Copied!
検証
作成した
route
リソースを確認するには、次のコマンドを実行します。oc get routes -o yaml <name of resource>
$ oc get routes -o yaml <name of resource>
1 Copy to Clipboard Copied! - 1
- この例では、ルートの名前は
hello-openshift
です。
上記で作成されたセキュアでないルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift spec: host: www.example.com port: targetPort: 8080 to: kind: Service name: hello-openshift
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: hello-openshift
spec:
host: www.example.com
port:
targetPort: 8080
to:
kind: Service
name: hello-openshift
- 1
host
フィールドは、サービスを指すエイリアス DNS レコードです。このフィールドには、www.example.com
などの有効な DNS 名を指定できます。DNS 名は DNS952 サブドメイン規則に従う必要があります。指定しない場合は、ルート名が自動的に生成されます。- 2
targetPort
フィールドは、このルートが指すサービスによって選択される Pod 上のターゲットポートです。注記デフォルトの Ingress ドメインを表示するには、以下のコマンドを実行します。
oc get ingresses.config/cluster -o jsonpath={.spec.domain}
$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
Copy to Clipboard Copied!
26.1.2. Ingress Controller シャーディングのルート作成
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift
アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法を説明します。
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshift
Copy to Clipboard Copied! 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
Copy to Clipboard Copied! 以下のコマンドを実行して、
hello-openshift
というサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshift
Copy to Clipboard Copied! hello-openshift-route.yaml
というルート定義を作成します。シャーディング用に作成されたルートの YAML 定義:
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
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
Copy to Clipboard Copied! 次のコマンドを実行し、
hello-openshift-route.yaml
を使用してhello-openshift
アプリケーションへのルートを作成します。oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yaml
Copy to Clipboard Copied!
検証
次のコマンドを使用して、ルートのステータスを取得します。
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
Copy to Clipboard Copied! 結果の
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> routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> routerName: sharded
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 Copy to Clipboard Copied!
26.1.3. ルートのタイムアウトの設定
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 Copied! - 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 Copied!
26.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 またはパススルールートには適していません。
26.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-terminated または re-encrypt ルートに追加します。これを実行するには、oc annotate
ツールを使用してこれを実行できます。oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ includeSubDomains;preload"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\
1 includeSubDomains;preload"
Copy to Clipboard Copied! - 1
- この例では、最長期間は
31536000
ミリ秒 (約 8 時間および半分) に設定されます。
注記この例では、等号 (
=
) が引用符で囲まれています。これは、annotate コマンドを正しく実行するために必要です。アノテーションで設定されたルートの例
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload ... spec: host: def.abc.com tls: termination: "reencrypt" ... wildcardPolicy: "Subdomain"
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"
Copy to Clipboard Copied! - 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 回対話している必要があります。
26.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"
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
Copy to Clipboard Copied! ヒントまたは、以下の YAML を適用して config map を作成できます。
ルートごとに HSTS を無効にする例
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0
metadata: annotations: haproxy.router.openshift.io/hsts_header: max-age=0
Copy to Clipboard Copied! namespace のすべてのルートで HSTS を無効にするには、following コマンドを入力します。
oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
Copy to Clipboard Copied!
検証
すべてのルートのアノテーションをクエリーするには、以下のコマンドを入力します。
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}}'
$ 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}}'
Copy to Clipboard Copied! 出力例
Name: routename HSTS: max-age=0
Name: routename HSTS: max-age=0
Copy to Clipboard Copied!
26.1.4.3. ドメインごとの HTTP Strict Transport Security の適用
セキュアなルートに対してドメインごとに HTTP Strict Transport Security (HSTS) を適用するには、Ingress 仕様に requiredHSTSPolicies
レコードを追加して、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
$ oc edit ingresses.config.openshift.io/cluster
Copy to Clipboard Copied! HSTS ポリシーの例
apiVersion: config.openshift.io/v1 kind: Ingress metadata: name: cluster spec: domain: 'hello-openshift-default.apps.username.devcluster.openshift.com' requiredHSTSPolicies: - domainPatterns: - '*hello-openshift-default.apps.username.devcluster.openshift.com' - '*hello-openshift-default2.apps.username.devcluster.openshift.com' namespaceSelector: matchLabels: myPolicy: strict maxAge: smallestMaxAge: 1 largestMaxAge: 31536000 preloadPolicy: RequirePreload includeSubDomainsPolicy: RequireIncludeSubDomains - domainPatterns: - 'abc.example.com' - '*xyz.example.com' namespaceSelector: matchLabels: {} maxAge: {} preloadPolicy: NoOpinion includeSubDomainsPolicy: RequireNoIncludeSubDomains
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
Copy to Clipboard Copied! - 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"
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
Copy to Clipboard Copied! 特定の namespace のすべてのルートに HSTS を適用するには、
oc annotate command
を実行します。以下に例を示します。oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
$ oc annotate route --all -n my-namespace --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000"
Copy to Clipboard Copied!
検証
設定した HSTS ポリシーを確認できます。以下に例を示します。
必要な HSTS ポリシーの
maxAge
セットを確認するには、以下のコマンドを入力します。oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
$ oc get clusteroperator/ingress -n openshift-ingress-operator -o jsonpath='{range .spec.requiredHSTSPolicies[*]}{.spec.requiredHSTSPolicies.maxAgePolicy.largestMaxAge}{"\n"}{end}'
Copy to Clipboard Copied! すべてのルートで 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}}'
$ 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}}'
Copy to Clipboard Copied! 出力例
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Name: <_routename_> HSTS: max-age=31536000;preload;includeSubDomains
Copy to Clipboard Copied!
26.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>
$ tcpdump -s 0 -i any -w /tmp/dump.pcap host <podip 1> && host <podip 2>
1 Copy to Clipboard Copied! - 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
$ tcpdump -s 0 -i any -w /tmp/dump.pcap port 4789
Copy to Clipboard Copied! ストリーミングのスループットおよび UDP スループットを測定するために
iperf
などの帯域幅測定ツールを使用します。最初に Pod からツールを実行し、次にノードから実行して、ボトルネックを特定します。-
iperf
のインストールおよび使用についての詳細は、こちらの Red Hat ソリューション を参照してください。
-
- 場合によっては、レイテンシーの問題が原因で、クラスターがルーター Pod を含むノードを異常としてマークすることがあります。ワーカーレイテンシープロファイルを使用して、アクションを実行する前にクラスターがノードからステータスの最新情報を受け取る頻度を調節します。
-
クラスターでレイテンシーの低いノードとレイテンシーの高いノードが指定されている場合は、Ingress Controller の
spec.nodePlacement
フィールドを設定して、ルーター Pod の配置を制御します。
26.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 に送られます。
26.1.6.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 Copied! ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
<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 Copied! 変数でルートのホスト名を取得します。
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 Copied! ここでは、以下のようになります。
<route_name>
- Pod の名前を指定します。
cookie を保存してからルートにアクセスします。
curl $ROUTE_NAME -k -c /tmp/cookie_jar
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
Copy to Clipboard Copied! ルートに接続する際に、直前のコマンドによって保存される cookie を使用します。
curl $ROUTE_NAME -k -b /tmp/cookie_jar
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
Copy to Clipboard Copied!
26.1.7. パスベースのルート
パスベースのルートは、URL に対して比較できるパスコンポーネントを指定します。この場合、ルートのトラフィックは HTTP ベースである必要があります。そのため、それぞれが異なるパスを持つ同じホスト名を使用して複数のルートを提供できます。ルーターは、最も具体的なパスの順に基づいてルートと一致する必要があります。
以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。
ルート | 比較対象 | アクセス可能 |
---|---|---|
www.example.com/test | www.example.com/test | はい |
www.example.com | いいえ | |
www.example.com/test および www.example.com | www.example.com/test | はい |
www.example.com | はい | |
www.example.com | www.example.com/text | Yes (ルートではなく、ホストで一致) |
www.example.com | はい |
パスが 1 つでセキュリティー保護されていないルート
apiVersion: route.openshift.io/v1 kind: Route metadata: name: route-unsecured spec: host: www.example.com path: "/test" to: kind: Service name: service-name
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: route-unsecured
spec:
host: www.example.com
path: "/test"
to:
kind: Service
name: service-name
- 1
- パスは、パスベースのルートに唯一追加される属性です。
ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、パススルー TLS を使用する場合には利用できません。
26.1.8. HTTP ヘッダーの設定
OpenShift Container Platform は、HTTP ヘッダーを操作するためのさまざまな方法を提供します。ヘッダーを設定または削除する場合、Ingress Controller の特定のフィールドまたは個々のルートを使用して、リクエストヘッダーと応答ヘッダーを変更できます。ルートアノテーションを使用して特定のヘッダーを設定することもできます。ヘッダーを設定するさまざまな方法は、連携時に課題となる可能性があります。
IngressController
または Route
CR 内のヘッダーは設定または削除のみ可能で、追加はできません。HTTP ヘッダーに値が設定されている場合、その値は完全である必要があるため、今後追加する必要はありません。X-Forwarded-For ヘッダーなどのヘッダーを追加することが適切な状況では、spec.httpHeaders.actions
の代わりに spec.httpHeaders.forwardedHeaderPolicy
フィールドを使用します。
26.1.8.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
ルート所有者は、クラスター管理者が 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
IngressController
仕様と Route
仕様の両方で X-Frame-Options ヘッダーを設定している場合、特定のルートでフレームが許可されている場合でも、Ingress Controller のグローバルレベルでこのヘッダーに設定された値が優先されます。
この優先順位付けは、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'
さらに、Ingress Controller またはルートのいずれかで定義されたアクションは、ルートアノテーションを使用して設定された値をオーバーライドします。
26.1.8.2. 特殊なケースのヘッダー
次のヘッダーは、設定または削除が完全に禁止されているか、特定の状況下で許可されています。
ヘッダー名 | IngressController 仕様を使用して設定可能かどうか | Route 仕様を使用して設定可能かどうか | 不許可の理由 | 別の方法で設定可能かどうか |
---|---|---|---|---|
| いいえ | いいえ |
| いいえ |
| いいえ | はい |
| いいえ |
| いいえ | いいえ |
|
はい: |
| いいえ | いいえ | HAProxy が設定する Cookie は、クライアント接続を特定のバックエンドサーバーにマップするセッション追跡に使用されます。これらのヘッダーの設定を許可すると、HAProxy のセッションアフィニティーが妨げられ、HAProxy の Cookie の所有権が制限される可能性があります。 | はい:
|
26.1.9. ルート内の 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 または TCP エンドポイントがある。
手順
ルート定義を作成し、
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 Copied! - 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 Copied!
HTTP リクエストヘッダーの場合、ルート定義で指定されたアクションは、Ingress Controller の HTTP リクエストヘッダーに対して実行されたアクションの後に実行されます。これは、ルート内のこれらのリクエストヘッダーに設定された値が、Ingress Controller に設定された値よりも優先されることを意味します。HTTP ヘッダーの処理順序の詳細は、HTTP ヘッダーの設定 を参照してください。
26.1.10. ルート固有のアノテーション
Ingress Controller は、公開するすべてのルートのデフォルトオプションを設定できます。個別のルートは、アノテーションに個別の設定を指定して、デフォルトの一部を上書きできます。Red Hat では、ルートアノテーションの Operator 管理ルートへの追加はサポートしません。
複数の送信元 IP またはサブネットのホワイトリストを作成するには、スペースで区切られたリストを使用します。他の区切りタイプを使用すると、リストが警告やエラーメッセージなしに無視されます。
変数 | 説明 | デフォルトで使用される環境変数 |
---|---|---|
|
ロードバランシングアルゴリズムを設定します。使用できるオプションは、 |
パススルールートの |
|
関連の接続を追跡する cookie の使用を無効にします。 | |
| このルートに使用するオプションの cookie を指定します。名前は、大文字、小文字、数字、"_" または "-" を任意に組み合わせて指定する必要があります。デフォルトは、ルートのハッシュ化された内部キー名です。 | |
|
ルーターからバッキングされる Pod に対して許容される接続最大数を設定します。 | |
|
| |
|
同じ送信元 IP アドレスで行われる同時 TCP 接続の数を制限します。数値を受け入れます。 | |
|
同じ送信元 IP アドレスを持つクライアントが HTTP 要求を実行できるレートを制限します。数値を受け入れます。 | |
|
同じ送信元 IP アドレスを持つクライアントが TCP 接続を確立するレートを制限します。数値を受け入れます。 | |
| ルートのサーバー側のタイムアウトを設定します。(TimeUnits) |
|
| このタイムアウトは、クリアテキスト、エッジ、再暗号化、またはパススルーのルートを介した WebSocket などトンネル接続に適用されます。cleartext、edge、または reencrypt のルートタイプでは、このアノテーションは、タイムアウト値がすでに存在するタイムアウトトンネルとして適用されます。パススルーのルートタイプでは、アノテーションは既存のタイムアウト値の設定よりも優先されます。 |
|
|
設定できるのは、IngressController または Ingress config です。このアノテーションでは、ルーターを再デプロイし、HA プロキシーが haproxy |
|
| バックエンドのヘルスチェックの間隔を設定します。(TimeUnits) |
|
| ルートの許可リストを設定します。許可リストは、承認したソースアドレスの IP アドレスおよび CIDR 範囲のリストをスペース区切りにしたリストです。許可リストに含まれていない IP アドレスからの要求は破棄されます。
| |
| edge terminated または re-encrypt ルートの Strict-Transport-Security ヘッダーを設定します。 | |
| バックエンドの要求の書き換えパスを設定します。 | |
| Cookie を制限するために値を設定します。値は以下のようになります。
この値は、re-encrypt および edge ルートにのみ適用されます。詳細は、SameSite cookie のドキュメント を参照してください。 | |
|
ルートごとに
|
|
-
デフォルトでは、ルーターは 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
)
変数 | デフォルト | 説明 |
---|---|---|
|
| バックエンドでの後続の liveness チェックの時間の長さ。 |
|
| クライアントがルートに接続する場合の TCP FIN タイムアウトの期間を制御します。接続切断のために送信された FIN が指定の時間内に応答されない場合は、HAProxy が接続を切断します。小さい値を設定し、ルーターでリソースをあまり使用していない場合には、リスクはありません。 |
|
| クライアントがデータを確認するか、送信するための時間の長さ。 |
|
| 最大接続時間。 |
|
| ルーターからルートをバッキングする Pod の TCP FIN タイムアウトを制御します。 |
|
| サーバーがデータを確認するか、送信するための時間の長さ。 |
|
| TCP または WebSocket 接続が開放された状態で保つ時間数。このタイムアウト期間は、HAProxy が再読み込みされるたびにリセットされます。 |
|
|
新しい HTTP 要求が表示されるまで待機する最大時間を設定します。この値が低すぎる場合には、ブラウザーおよびアプリケーションの
有効なタイムアウト値には、想定した個別のタイムアウトではなく、特定の変数を合計した値に指定することができます。たとえば、 |
|
| HTTP 要求の伝送にかかる時間。 |
|
| ルーターがリロードし、新規の変更を受け入れる最小の頻度を許可します。 |
|
| HAProxy メトリクスの収集タイムアウト。 |
ルート設定のカスタムタイムアウト
apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: haproxy.router.openshift.io/timeout: 5500ms ...
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
haproxy.router.openshift.io/timeout: 5500ms
...
- 1
- HAProxy 対応の単位 (
us
、ms
、s
、m
、h
、d
) で新規のタイムアウトを指定します。単位が指定されていない場合は、ms
がデフォルトになります。
パススルールートのサーバー側のタイムアウト値を低く設定し過ぎると、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
複数の 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
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
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
書き換えターゲットを指定するルート
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
- バックエンドの要求の書き換えパスとして
/
を設定します。
ルートに haproxy.router.openshift.io/rewrite-target
アノテーションを設定すると、要求をバックエンドアプリケーションに転送する前に Ingress Controller がこのルートを使用して HTTP 要求のパスを書き換える必要があることを指定します。spec.path
で指定されたパスに一致する要求パスの一部は、アノテーションで指定された書き換えターゲットに置き換えられます。
以下の表は、spec.path
、要求パス、および書き換えターゲットの各種の組み合わせに関するパスの書き換え動作の例を示しています。
Route.spec.path | 要求パス | 書き換えターゲット | 転送された要求パス |
---|---|---|---|
/foo | /foo | / | / |
/foo | /foo/ | / | / |
/foo | /foo/bar | / | /bar |
/foo | /foo/bar/ | / | /bar/ |
/foo | /foo | /bar | /bar |
/foo | /foo/ | /bar | /bar/ |
/foo | /foo/bar | /baz | /baz/bar |
/foo | /foo/bar/ | /baz | /baz/bar/ |
/foo/ | /foo | / | 該当なし (要求パスがルートパスに一致しない) |
/foo/ | /foo/ | / | / |
/foo/ | /foo/bar | / | /bar |
26.1.11. ルートの受付ポリシーの設定
管理者およびアプリケーション開発者は、同じドメイン名を持つ複数の 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 Copied! イメージコントローラー設定例
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
spec: routeAdmission: namespaceOwnership: InterNamespaceAllowed ...
Copy to Clipboard Copied! ヒントまたは、以下の 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 Copied!
26.1.12. Ingress オブジェクトを使用したルートの作成
一部のエコシステムコンポーネントには Ingress リソースとの統合機能がありますが、ルートリソースとは統合しません。これに対応するために、OpenShift Container Platform は Ingress オブジェクトの作成時に管理されるルートオブジェクトを自動的に作成します。これらのルートオブジェクトは、対応する Ingress オブジェクトが削除されると削除されます。
手順
OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、
oc create
コマンドを実行します。Ingress の YAML 定義
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: secret-ca-cert spec: rules: - host: www.example.com http: paths: - backend: service: name: frontend port: number: 443 path: / pathType: Prefix tls: - hosts: - www.example.com secretName: example-com-tls-certificate
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
Copy to Clipboard Copied! - 1
route.openshift.io/termination
アノテーションは、Route
のspec.tls.termination
フィールドを設定するために使用できます。Ingress
にはこのフィールドがありません。許可される値はedge
、passthrough
、およびreencrypt
です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edge
がデフォルトルートになります。デフォルトのエッジルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。- 3
Ingress
オブジェクトを操作する場合、ルートを操作する場合とは異なり、明示的なホスト名を指定する必要があります。<host_name>.<cluster_ingress_domain>
構文 (apps.openshiftdemos.com
など) を使用して、*.<cluster_ingress_domain>
ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。route.openshift.io/termination
アノテーションでpassthrough
の値を指定する場合は、仕様でpath
を''
に設定し、pathType
をImplementationSpecific
に設定します。spec: rules: - host: www.example.com http: paths: - path: '' pathType: ImplementationSpecific backend: service: name: frontend port: number: 443
spec: rules: - host: www.example.com http: paths: - path: '' pathType: ImplementationSpecific backend: service: name: frontend port: number: 443
Copy to Clipboard Copied! oc apply -f ingress.yaml
$ oc apply -f ingress.yaml
Copy to Clipboard Copied!
- 2
route.openshift.io/destination-ca-certificate-secret
を Ingress オブジェクトで使用して、カスタム宛先証明書 (CA) でルートを定義できます。アノテーションは、生成されたルートに挿入される kubernetes シークレットsecret-ca-cert
を参照します。-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
data.tls.crt
指定子に PEM エンコード形式の証明書を使用してkubernetes.io/tls
またはOpaque
タイプのシークレットを作成する必要があります。
-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
ルートを一覧表示します。
oc get routes
$ oc get routes
Copy to Clipboard Copied! 結果には、
frontend-
で始まる名前の自動生成ルートが含まれます。NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None
Copy to Clipboard Copied! このルートを検査すると、以下のようになります。
自動生成されるルートの 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
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
Copy to Clipboard Copied!
26.1.13. 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: - {}
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend ... spec: rules: ... tls: - {}
1 Copy to Clipboard Copied! - 1
- この正確な構文を使用して、カスタム証明書を指定せずに TLS を指定します。
次のコマンドを実行して、Ingress オブジェクトを作成します。
oc create -f example-ingress.yaml
$ oc create -f example-ingress.yaml
Copy to Clipboard Copied!
検証
以下のコマンドを実行して、OpenShift Container Platform が Ingress オブジェクトの予期されるルートを作成したことを確認します。
oc get routes -o yaml
$ oc get routes -o yaml
Copy to Clipboard Copied! 出力例
apiVersion: v1 items: - apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-j9sdd ... spec: ... tls: insecureEdgeTerminationPolicy: Redirect termination: edge ...
apiVersion: v1 items: - apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-j9sdd
1 ... spec: ... tls:
2 insecureEdgeTerminationPolicy: Redirect termination: edge
3 ...
Copy to Clipboard Copied!
26.1.14. Ingress アノテーションでの宛先 CA 証明書を使用したルート作成
route.openshift.io/destination-ca-certificate-secret
アノテーションを Ingress オブジェクトで使用して、カスタム宛先 CA 証明書でルートを定義できます。
前提条件
- PEM エンコードされたファイルで証明書/キーのペアを持つことができます。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
手順
次のコマンドを入力して、宛先 CA 証明書のシークレットを作成します。
oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>
$ oc create secret generic dest-ca-cert --from-file=tls.crt=<file_path>
Copy to Clipboard Copied! 以下に例を示します。
oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt
$ oc -n test-ns create secret generic dest-ca-cert --from-file=tls.crt=tls.crt
Copy to Clipboard Copied! 出力例
secret/dest-ca-cert created
secret/dest-ca-cert created
Copy to Clipboard Copied! 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 ...
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 ...
Copy to Clipboard Copied! - 1
- アノテーションは kubernetes シークレットを参照します。
このアノテーションで参照されているシークレットは、生成されたルートに挿入されます。
出力例
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend annotations: route.openshift.io/termination: reencrypt route.openshift.io/destination-ca-certificate-secret: secret-ca-cert spec: ... tls: insecureEdgeTerminationPolicy: Redirect termination: reencrypt destinationCACertificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- ...
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----- ...
Copy to Clipboard Copied!
26.1.15. デュアルスタックネットワーク用の 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 Copied! これらのリソースは、対応する
endpoints
を生成します。Ingress Controller は、endpointslices
を監視するようになりました。endpoints
を表示するには、以下のコマンドを入力します。oc get endpoints
$ oc get endpoints
Copy to Clipboard Copied! endpointslices
を表示するには、以下のコマンドを入力します。oc get endpointslices
$ oc get endpointslices
Copy to Clipboard Copied!