第17章 Routes (ルート)

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

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

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

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

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

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

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

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

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

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

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

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

$ 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

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 終端に使用されます。

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

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

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

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