第5章 Kourier と Istio Ingress
OpenShift Serverless は、次の 2 つの Ingress ソリューションをサポートします。
- Kourier
- Red Hat OpenShift Service Mesh を使用した Istio
デフォルトは Kourier です。
5.1. Kourier および Istio Ingress ソリューション
5.1.1. Kourier
Kourier は、OpenShift Serverless のデフォルトの Ingress ソリューションです。次のような特性があります。
- Envoy プロキシーをベースとしています。
- シンプルで軽量です。
- Serverless が一連の機能を提供するために必要な基本的なルーティング機能を提供します。
- 基本的な可観測性とメトリクスをサポートします。
- Knative Service ルーティングの基本的な TLS Termination をサポートします。
- 限られた設定および拡張オプションのみが提供されます。
5.1.2. OpenShift Service Mesh を使用した Istio
OpenShift Serverless の Ingress ソリューションとして Istio を使用すると、Red Hat OpenShift Service Mesh が提供するものに基づく追加の機能セットが有効になります。
- すべての接続間のネイティブ mTLS
- サービスメッシュの一部である Serverless コンポーネント
- 追加の可観測性とメトリクス
- 認可と認証のサポート
- Red Hat OpenShift Service Mesh でサポートされるカスタムルールと設定
ただし、追加機能には、より高いオーバーヘッドとリソース消費が伴います。詳細は、Red Hat OpenShift Service Mesh のドキュメントを参照してください。
Istio の要件とインストール手順は、Serverless ドキュメントの「Service Mesh と OpenShift Serverless の統合」セクションを参照してください。
5.1.3. トラフィックの設定とルーティング
Kourier と Istio のどちらを使用するかに関係なく、Knative Service のトラフィックは、それぞれ net-kourier-controller または net-istio-controller によって knative-serving namespace に設定されます。
コントローラーは KnativeService とその子カスタムリソースを読み取り、Ingress ソリューションを設定します。どちらの Ingress ソリューションも、トラフィックパスの一部となる Ingress ゲートウェイ Pod を提供します。どちらの Ingress ソリューションも Envoy をベースとしています。デフォルトでは、Serverless には各 KnativeService オブジェクトに対して 2 つのルートがあります。
-
OpenShift ルーターによって転送される cluster-external ルート (例:
myapp-namespace.example.com)。 -
クラスタードメインを含む cluster-local ルート (例:
myapp.namespace.svc.cluster.local)。このドメインは、Knative または他のユーザーワークロードから Knative サービスを呼び出すために使用できるため、使用する必要があります。
Ingress ゲートウェイは、serve モードまたはプロキシーモードのいずれかでリクエストを転送できます。
- serve モードでは、リクエストは Knative サービスの Queue-Proxy サイドカーコンテナーに直接送信されます。
-
プロキシーモードでは、リクエストはまず
knative-servingnamespace の Activator コンポーネントを通過します。
モードの選択は、Knative の設定、Knative サービス、および現在のトラフィックによって異なります。たとえば、Knative サービスがゼロにスケーリングされた場合、リクエストは Activator コンポーネントに送信され、新しい Knative サービス Pod が開始されるまでバッファーとして機能します。
