第16章 Routes (ルート)

16.1. 概要

OpenShift Container Platform のルートは、外部クライアントが名前で到達できるように www.example.com などのホスト名でサービスを公開します。

ホスト名の DNS 解決はルーティングとは別に処理されます。管理者は常に OpenShift Container Platform ルーターに対して正常に解決されるクラウドドメインを設定している場合がありますが、関連性のないホスト名を使用する場合には、ルーターに対して解決されるようにその DNS レコードを別途変更する必要がある場合があります。

16.2. ルートの作成

Web コンソールまたは CLI を使用して、セキュリティー保護されていないルートとセキュリティー保護されているルートを作成できます。

Web コンソールを使用してナビゲーションの Applications セクションの下にある Routes ページに移動します。

Create Route をクリックしてプロジェクト内でルートを定義し、作成します。

図16.1 Web コンソールを使用したルートの作成

Creating a Route Using the Web Console

以下の例では、CLI を使用して非セキュアなルートを作成します。

$ oc expose svc/frontend --hostname=www.example.com

新規ルートは、--name オプションを使用して名前を指定しない限りサービスから名前を継承します。

上記で作成された非セキュアなルートの YAML 定義

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  path: "/test" 1
  to:
    kind: Service
    name: frontend

1
パスベースのルーティングについては、URL に対して比較対象となるパスコンポーネントを指定します。

CLI を使用したルートの設定についての情報は、「ルートタイプ」を参照してください。

非セキュアなルートはデフォルト設定であるため、これが最も簡単なセットアップになります。ただし、セキュリティー保護されたルートは、接続がプライベートのままになるようにセキュリティーを提供します。キーと証明書 (別々に生成し、署名する必要のある PEM 形式のファイル) で暗号化されたセキュリティー保護された HTTPS ルートを作成するには、create route コマンドを使用し、オプションで証明書およびキーを指定できます。

注記

TLS は、HTTPS および他の暗号化されたプロトコルにおける SSL の代わりとして使用されます。

$ oc create route edge --service=frontend \
    --cert=${MASTER_CONFIG_DIR}/ca.crt \
    --key=${MASTER_CONFIG_DIR}/ca.key \
    --ca-cert=${MASTER_CONFIG_DIR}/ca.crt \
    --hostname=www.example.com

上記で作成されたセキュリティー保護されたルートの YAML 定義

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

現時点で、パスワードで保護されたキーファイルはサポートされていません。HAProxy は開始時にパスワードを求めるプロンプトを出しますが、このプロセスを自動化する方法はありません。キーファイルからパスフレーズを削除するために、以下を実行できます。

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

キーと証明書を指定せずにセキュリティー保護されたルートを作成できます。この場合、ルーターのデフォルト証明書が TLS 終端に使用されます。

注記

OpenShift Container Platform での TLS 終端は、カスタム証明書の提供について SNI に依存します。ポート 443 で受信される SNI 以外のトラフィックは TLS 終端で処理され、要求されるホスト名に一致しない可能性のあるデフォルト証明書により検証エラーが生じる可能性があります。

すべてのタイプの TLS 終端およびパスベースのルーティングについての詳細は、「アーキテクチャー」セクションで参照してください。

16.3. ルートエンドポイントによる Cookie 名の制御の許可

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

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

ルート用に自動生成されるデフォルト名を上書きするために Cookie 名を設定できます。Cookie を削除すると、次の要求でエンドポイントの再選択が強制的に実行される可能性があります。そのためサーバーがオーバーロードしている場合には、クライアントからの要求を取り除き、それらの再分配を試行します。

  1. 必要な Cookie 名でルートにアノテーションを付けます。

    $ oc annotate route <route_name> router.openshift.io/cookie_name="<your_cookie_name>"

    たとえば、my_cookie を新規の Cookie 名として指定するには、以下を実行します。

    $ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
  2. Cookie を保存し、ルートにアクセスします。

    $ curl $my_route -k -c /tmp/my_cookie