一部のアプリは、クラスタの外でアクセスできなくても便利ですが、通常は 1 つ以上の HTTP エンドポイントでクラスタの外部で使用できるようにする必要があります。Kf では、これはルートの役割です。
デフォルトでは、各アプリは、クラスタの内部アプリアドレス app-name.space-name を使用してクラスタ内の他のプロセスにアクセスできます。このアドレスを使用すると、相互に通信が必要なクラスタに 1 つ以上のアプリをデプロイできます。それにより、あるアプリから別のアプリへのトラフィックを、クラスタの外に出して戻すのではなく、直接送信できるようになります。こうすることで、通信が安全かつ高速になり、ローカル クラスタでのサービスの使用が保証されます。
クラスタ外からアプリにアクセスできるようにする必要がある場合は、そのアプリのルートを作成する必要があります。
クラスタ内部ドメイン
各アプリのクラスタ内部ドメインには、いくつかの特徴があります。
- これをアプリで使用すると、東西（ポイント ツー ポイント）ルーティングが可能になります。
- 受信したトラフィックは、実行中のアプリ Pod 間で負荷分散されます。
- HTTP 以外のエンドポイントには、内部ドメインを使用して接続できます。
ルートを使用すると、クラスタ内部ドメイン上にバニティ URL を作成できます。
アプリの負荷分散
トラフィックは、ラウンドロビン ポリシーを使用して Istio からアプリの正常なインスタンスにルーティングされます。現在、このポリシーは変更できません。
ルートの機能
ルートにより、クラスタの上り（内向き）ゲートウェイにトラフィックを配信する場所と、指定されたアドレスで利用できるアプリがない場合の処理が指示されます。デフォルトでは、ルート上に使用可能なアプリがない場合、ルートはリクエストを受信すると、HTTP 503 のステータス コードを返します。
ルートは、ホスト、ドメイン、パスの 3 要素で構成されます。たとえば、URI payroll.mydatacenter.example.com/login では次のようになります。
- ホストは
payrollです。 - ドメインは
mydatacenter.example.comです。 - パスは
/loginです。
ルートにはホストとドメインを含める必要がありますが、パスは省略可能です。複数のパスを指定すると、複数のルートで同じホストとドメインを共有できます。複数のアプリが同じルートを共有できます。トラフィックはそれらの間で分割されます。これは、従来の Blue/Green デプロイをサポートする必要がある場合に役立ちます。複数のアプリが異なるパスにバインドされている場合、長いパスが短いパスより優先されます。
ルートの使用
続くセクションでは、kf CLI を使用してルートを管理する方法について説明します。
ルートの一覧表示
開発者は、kf routes コマンドを使用して現在のスペースのルートを一覧表示できます。
$ kf routes
Getting Routes in Space: my-space
Found 2 Routes in Space my-space
HOST DOMAIN PATH APPS
echo example.com / echo
* example.com /login uaa
ルートの作成
開発者は kf create-route コマンドを使用してルートを作成できます。
# Create a Route in the targeted Space to match traffic for myapp.example.com/*
$ kf create-route example.com --hostname myapp
# Create a Route in the Space myspace to match traffic for myapp.example.com/*
$ kf create-route -n myspace example.com --hostname myapp
# Create a Route in the targeted Space to match traffic for myapp.example.com/mypath*
$ kf create-route example.com --hostname myapp --path /mypath
# You can also supply the Space name as the first parameter if you have
# scripts that rely on the old cf style API.
$ kf create-route myspace example.com --hostname myapp # myapp.example.com
ルートが作成された後、ルートにアプリがバインドされていない場合は、一致するリクエストに対して HTTP 503 のステータス コードが返されます。
アプリにルートをマッピングする
開発者は、kf map-route コマンドを使用してアプリをルートでアクセス可能にできます。
$ kf map-route MYAPP mycluster.example.com --host myapp --path mypath
ルートのマッピング解除
開発者は、kf
unmap-route コマンドを使用してアプリをルートでアクセス不可にできます。
$ kf unmap-route MYAPP mycluster.example.com --host myapp --path mypath
ルートの削除
開発者は kf delete-route コマンドを使用してルートを削除できます。
$ kf delete-route mycluster.example.com --host myapp --path mypath
ルートを削除すると、ルートをリッスンしているすべてのアプリにトラフィックがルーティングされなくなります。
アプリ マニフェストの宣言型ルート
ルートはアプリ マニフェスト ファイルで宣言的に管理できます。ルートがまだ存在しない場合は、作成されます。
---
applications:
- name: my-app
# ...
routes:
- route: example.com
- route: www.example.com/path
サポートされているルート プロパティの詳細については、マニフェストのドキュメントをご覧ください。
高度なトピック
CRD のルーティング
ルーティング関連では、次の 4 つのタイプがあります。
- VirtualService
- Route
- Service
- App
各アプリには、アプリのすべての実行中のインスタンスに指定する抽象名である Service があります。Service の名前はアプリと同じです。Route は単一の外部 URL を表します。Route は、Apps への変更を常に監視します。Apps が Route への追加をリクエストすると、Route は Apps のリストを更新し、それから VirtualService を更新します。VirtualService は単一のドメインを表し、そのドメインに属するスペース内のすべての Route のリストをマージします。
Istio は VirtualService の構成を読み取り、トラフィックのルーティング方法を決定します。