第1章 サービスメッシュと OpenShift Serverless の統合
OpenShift Serverless Operator は、Knative のデフォルト Ingress として Kourier を提供します。ただし、Kourier が有効であるかどうかにかかわらず、OpenShift Serverless でサービスメッシュを使用できます。Kourier を無効にして統合すると、mTLS 機能など、Kourier イングレスがサポートしない追加のネットワークおよびルーティングオプションを設定できます。
次の前提条件と制限事項に注意してください。
- すべての Knative 内部コンポーネントと Knative Services は Service Mesh の一部であり、サイドカーインジェクションが有効になっています。これは、メッシュ全体で厳密な mTLS が適用されることを意味します。Knative Services へのすべてのリクエストには mTLS 接続が必要で、OpenShift Routing からの呼び出しを除き、クライアントは証明書を送信する必要があります。
- OpenShift Serverless と Service Mesh の統合では、1 つの サービスメッシュのみをターゲットにできます。クラスター内には複数のメッシュが存在できますが、OpenShift Serverless はそのうちの 1 つでのみ使用できます。
-
OpenShift Serverless が含まれているターゲット
ServiceMeshMemberRollの変更、つまり OpenShift Serverless を別のメッシュに移動することはサポートされていません。ターゲットの Service Mesh を変更する唯一の方法は、OpenShift Serverless をアンインストールして再インストールすることです。
1.1. 前提条件
- クラスター管理者アクセス権を持つ Red Hat OpenShift Serverless アカウントにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。 - Serverless Operator がインストールされている。
- Red Hat OpenShift Service Mesh Operator がインストールされている。
以下の手順の例では、ドメイン
example.comを使用します。このドメインの証明書のサンプルは、サブドメイン証明書に署名する認証局 (CA) として使用されます。お使いのデプロイメントでこの手順を完了し、検証するには、一般に信頼されているパブリック CA によって署名された証明書、または組織が提供する CA のいずれかが必要です。コマンドの例は、ドメイン、サブドメイン、および CA に合わせて調整する必要があります。
-
ワイルドカード証明書を OpenShift Container Platform クラスターのドメインに一致するように設定する必要があります。たとえば、OpenShift Container Platform コンソールアドレスが
https://console-openshift-console.apps.openshift.example.comの場合は、ドメインが*.apps.openshift.example.comになるようにワイルドカード証明書を設定する必要があります。ワイルドカード証明書の設定に関する詳細は、着信外部トラフィックを暗号化する証明書の作成のトピックを参照してください。 - デフォルトの OpenShift Container Platform クラスタードメインのサブドメインではないものを含むドメイン名を使用する必要がある場合は、これらのドメインのドメインマッピングを設定する必要があります。詳細は、OpenShift Serverless ドキュメントのカスタムドメインマッピングの作成を参照してください。
OpenShift Serverless は、本書で明示的に文書化されている Red Hat OpenShift Service Mesh 機能の使用のみをサポートし、文書化されていない他の機能はサポートしません。
Service Mesh での Serverless 1.31 の使用は、Service Mesh バージョン 2.2 以降でのみサポートされます。1.31 以外のバージョンの詳細と情報は、「Red Hat OpenShift Serverless でサポートされる構成」ページを参照してください。
