31- 第8章：OpenShift ネットワークの概念を説明・探索する-3：ルートの作成の説明

type

status

date

slug

summary

category

icon

password

ルートの作成

目標

このセクションを終えた後、学生は OpenShift のルーティングがどのように機能するかを説明し、ルートを作成できるようになるべきです。

OpenShift ルーターの説明

OpenShift のサービスは、OpenShift インスタンス内のポッド間でのネットワークアクセスを提供しますが、OpenShift のルートは、OpenShift インスタンスの外部からポッドへのネットワークアクセスを提供します。

ルートの作成

ルートは、公開されているIPアドレスおよびDNSホスト名を内部向けのサービスIPアドレスに接続する役割を果たします。少なくとも、このような概念で理解されます。実際には、パフォーマンス向上とレイテンシの低減を目的として、OpenShiftルーターはOpenShiftコンテナプラットフォームによって作成されたネットワークを通じてポッドに直接接続し、サービスはエンドポイント（サービスによって公開されたポッド）を見つけるためにのみ使用されます。

OpenShiftのルートは、OpenShiftインスタンス内でポッドとして実行され、通常のポッドと同様にスケールやレプリケートが可能な共有ルーターサービスによって実装されます。このルーターサービスは、オープンソースソフトウェアであるHAProxyに基づいています。

OpenShiftの管理者にとって重要な考慮事項は、ルートに設定された公開DNSホスト名が、ルーターを実行しているノードの公開IPアドレスを指し示す必要があるということです。ルーターポッドは通常のアプリケーションポッドとは異なり、内部ポッドネットワークではなく、ノードの公開IPアドレスにバインドします。これは通常、DNSワイルドカードを使用して設定されます。

次に、YAML構文で定義された最小限のルートの例を示します：

kind: Kubernetesリソースの種類。この場合は、Route。

name: ルートの一意の名前。

host: ルートに関連付けられた完全修飾ドメイン名（FQDN）。これは、OpenShiftルーターポッドが実行されているノードのIPアドレスを解決するように事前設定する必要があります。

to: ルートが指すリソースの種類と、そのリソースの名前。この場合、Serviceリソースの名前は quoteapp です。

注意

異なるリソースタイプの名前は衝突しません。同じ名前のルート（例えば、quoteapp）とサービス（quoteapp）があっても問題ありません。

重要

サービスはセレクターを使用して、特定のラベルを持つポッドリソースにリンクしますが、ルートはサービスリソース名に直接リンクします。

ルートの作成

ルートを作成する最も簡単で推奨される方法は、oc expose コマンドを使用してサービスリソース名を入力として渡すことです。--name オプションを使用してルートリソースの名前を制御し、--hostname オプションを使用してカスタムホスト名を指定できます。例えば、次のように入力します：

テンプレートから作成されたルートや、oc expose コマンドで --hostname オプションを明示的に指定せずに作成されたルートは、以下の形式のDNS名を生成します。

ここで：

route-name はルートに明示的に指定された名前、または oc new-app や oc expose コマンドで使用される元のリソース（テンプレートやサービス）の名前です。-name オプションを使って指定することもできます。

project-name はリソースが所属するプロジェクトの名前です。

default-domain は OpenShift マスターで設定されているもので、OpenShift のインストール前提条件としてリストされたワイルドカード DNS ドメインに対応しています。

例えば、OpenShift クラスターでサブドメインが apps.example.com に設定されている場合、test というプロジェクト内で quote という名前のルートを作成すると、FQDN（完全修飾ドメイン名）は quote-test.apps.example.com になります。

注意

ワイルドカードドメインをホストする DNS サーバーは、ルートホスト名に関する情報を持っていません。単に設定された IP アドレスに対して名前を解決するだけです。ルートホスト名について知っているのは OpenShift ルーターのみで、各ルートホスト名を HTTP バーチャルホストとして扱います。無効なワイルドカードドメインホスト名（つまり、ルートに対応しないホスト名）は OpenShift ルーターによってブロックされ、HTTP 404 エラーが返されます。

ルートリソースは、JSON または YAML のリソース定義ファイルを提供して oc create コマンドで作成することもできます。

oc new-app コマンドは、コンテナイメージ、Dockerfile、またはアプリケーションソースコードからポッドを作成する際に、ルートリソースを作成しません。oc new-app コマンドは、ポッドが OpenShift インスタンス外部からアクセス可能であるかどうかを認識しません。oc new-app コマンドがテンプレートからポッドのグループを作成する場合、アプリケーションの一部としてルートリソースがテンプレートに含まれていることを妨げるものはありません。ウェブコンソールでも同様です。

デフォルトのルーティングサブドメインの確認

デフォルトのルーティングサブドメインは、OpenShift の設定ファイル master-config.yaml の routingConfig セクションで、subdomain キーワードによって定義されています。例えば：

OpenShift の HAProxy ルーターは、デフォルトでホストポート 80（HTTP）と 443（HTTPS）にバインドされます。これらのポートは、他の用途で使用されていないノードに配置する必要があります。あるいは、ルーターを他のポートでリッスンするように設定することもでき、その場合はルーターのデプロイメント設定で ROUTER_SERVICE_HTTP_PORT と ROUTER_SERVICE_HTTPS_PORT 環境変数を設定します。

ルーターは以下のプロトコルをサポートします：

HTTP

SNI を使用した HTTPS

WebSockets

SNI を使用した TLS

ルートのオプションとタイプ

ルートには、セキュア（暗号化された）ルートと、セキュアでない（暗号化されない）ルートの2種類があります。セキュアルートは通信を暗号化して、より安全にしますが、設定が少し複雑です。セキュアでないルートは、設定が簡単で証明書などは必要ありません。

セキュアルートのタイプ

セキュアなルートでは、TLS（Transport Layer Security）という暗号化技術を使って通信を守ります。TLS終了の方法は以下の3つです。

エッジ終了（Edge Termination）

ルーターで暗号化通信を解除し、その後普通の通信としてポッドに送ります。

ルーターが証明書を持ち、暗号化はルーターで行います。ポッド間の通信は暗号化されません。

パススルー終了（Pass-through Termination）

暗号化されたまま、通信は直接ポッドに送られます。

ルーターは証明書を持たず、ポッド側が証明書を使って通信を暗号化します。

クライアント証明書（双方向認証）が必要な場合は、この方法を使います。

再暗号化終了（Re-encryption Termination）

ルーターで暗号化された通信を解除した後、再度暗号化してポッドに送ります。

通信の途中全てが暗号化されるので、より安全です。

セキュアルートの作り方

セキュアルートを作るには、まずTLS証明書を用意する必要があります。以下の手順で自己署名証明書を作り、その証明書を使ってセキュアルートを作ります。

秘密鍵を作成する

*証明書署名要求（CSR）**を作成する

証明書を生成する

証明書が準備できたら、エッジ終了のルートを作成します。

これで、https://test.example.comというURLで、セキュアなルートにアクセスできるようになります。

サブドメイン用のワイルドカードルート

ワイルドカードポリシーを使用すると、ドメイン内のすべてのホストをカバーするルートを定義できます。ルートは、wildcardPolicy フィールドを使ってその構成の一部としてワイルドカードポリシーを指定できます。

OpenShiftのルーターはワイルドカードルートをサポートしており、ルーターのデプロイメント設定で ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を true に設定することで有効化できます。wildcardPolicy 属性が Subdomain に設定されているルートは、ルーターによって処理されます。ルーターは、そのルートのワイルドカードポリシーに従って関連するサービスを公開します。

例えば、a.lab.example.com、b.lab.example.com、c.lab.example.com という3つの異なるルートがあり、それらが test というOpenShiftサービスにルーティングされるべき場合、以下のようにワイルドカードポリシーを設定してルートを作成できます。