第9章 統合
9.1. サービスメッシュと OpenShift Serverless の統合
OpenShift Serverless Operator は、Knative のデフォルト Ingress として Kourier を提供します。ただし、Kourier が有効であるかどうかにかかわらず、OpenShift Serverless でサービスメッシュを使用できます。Kourier を無効にして統合すると、mTLS 機能など、Kourier イングレスがサポートしない追加のネットワークおよびルーティングオプションを設定できます。
OpenShift Serverless は、本書で明示的に文書化されている Red Hat OpenShift Service Mesh 機能の使用のみをサポートし、文書化されていない他の機能はサポートしません。
9.1.1. 前提条件
以下の手順の例では、ドメイン
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 ドキュメントのカスタムドメインマッピングの作成を参照してください。
9.1.2. 着信外部トラフィックを暗号化する証明書の作成
デフォルトでは、サービスメッシュ mTLS 機能は、Ingress ゲートウェイとサイドカーを持つ個々の Pod 間で、サービスメッシュ自体内のトラフィックのみを保護します。OpenShift Container Platform クラスターに流入するトラフィックを暗号化するには、OpenShift Serverless とサービスメッシュの統合を有効にする前に証明書を生成する必要があります。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Serverless Operator および Knative Serving がインストールされていること。
-
OpenShift CLI (
oc
) をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
Knative サービスの証明書に署名する root 証明書と秘密鍵を作成します。
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \ -subj '/O=Example Inc./CN=example.com' \ -keyout root.key \ -out root.crt
ワイルドカード証明書を作成します。
$ openssl req -nodes -newkey rsa:2048 \ -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \ -keyout wildcard.key \ -out wildcard.csr
ワイルドカード証明書を署名します。
$ openssl x509 -req -days 365 -set_serial 0 \ -CA root.crt \ -CAkey root.key \ -in wildcard.csr \ -out wildcard.crt
ワイルドカード証明書を使用してシークレットを作成します。
$ oc create -n istio-system secret tls wildcard-certs \ --key=wildcard.key \ --cert=wildcard.crt
この証明書は、OpenShift Serverless をサービスメッシュと統合する際に作成されるゲートウェイによって取得され、Ingress ゲートウェイはこの証明書でトラフィックを提供します。
9.1.3. サービスメッシュと OpenShift Serverless の統合
Kourier をデフォルトのイングレスとして使用せずに、Service Mesh を OpenShift Serverless と統合できます。このため、以下の手順を完了する前に、Knative Serving コンポーネントをインストールしないでください。Knative Serving をサービスメッシュと統合するために KnativeServing
カスタムリソース定義 (CRD) を作成する際に必要な追加の手順があります。これは、一般的な Knative Serving のインストール手順では説明されていません。この手順は、サービスメッシュをデフォルトとして統合し、OpenShift Serverless インストールの唯一のイングレスとして統合する場合に役立ちます。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
Red Hat OpenShift Service Mesh Operator をインストールし、
istio-system
namespace にServiceMeshControlPlane
リソースを作成します。mTLS 機能を使用する場合は、ServiceMeshControlPlane
リソースのspec.security.dataPlane.mtls
フィールドもtrue
に設定する必要があります。重要Service Mesh での OpenShift Serverless の使用は、Red Hat OpenShift Service Mesh バージョン 2.0.5 以降でのみサポートされます。
- OpenShift Serverless Operator をインストールします。
-
OpenShift CLI (
oc
) をインストールしている。
手順
サービスメッシュと統合する必要のある namespace をメンバーとして
ServiceMeshMemberRoll
オブジェクトに追加します。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: members: 1 - knative-serving - <namespace>
- 1
- サービスメッシュと統合する namespace の一覧。
重要この namespace の一覧には、
knative-serving
namespace が含まれる必要があります。ServiceMeshMemberRoll
リソースを適用します。$ oc apply -f <filename>
サービスメッシュがトラフィックを受け入れることができるように、必要なゲートウェイを作成します。
HTTP を使用した
knative-local-gateway
オブジェクトの例apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: knative-ingress-gateway namespace: knative-serving spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*" tls: mode: SIMPLE credentialName: <wildcard_certs> 1 --- apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: knative-local-gateway namespace: knative-serving spec: selector: istio: ingressgateway servers: - port: number: 8081 name: http protocol: HTTP 2 hosts: - "*" --- apiVersion: v1 kind: Service metadata: name: knative-local-gateway namespace: istio-system labels: experimental.istio.io/disable-gateway-port-translation: "true" spec: type: ClusterIP selector: istio: ingressgateway ports: - name: http2 port: 80 targetPort: 8081
HTTPS を使用した
knative-local-gateway
オブジェクトの例apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: knative-local-gateway namespace: knative-serving spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*" tls: mode: SIMPLE credentialName: <wildcard_certs>
Gateway
リソースを適用します。$ oc apply -f <filename>
以下の
KnativeServing
カスタムリソース定義 (CRD) を作成して Knative Serving をインストールします。これにより、Istio 統合も有効化されます。apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: ingress: istio: enabled: true 1 deployments: 2 - name: activator annotations: "sidecar.istio.io/inject": "true" "sidecar.istio.io/rewriteAppHTTPProbers": "true" - name: autoscaler annotations: "sidecar.istio.io/inject": "true" "sidecar.istio.io/rewriteAppHTTPProbers": "true"
KnativeServing
リソースを適用します。$ oc apply -f <filename>
サイドカー挿入が有効で、パススルールートを使用する Knative サービスを作成します。
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: <service_name> namespace: <namespace> 1 annotations: serving.knative.openshift.io/enablePassthrough: "true" 2 spec: template: metadata: annotations: sidecar.istio.io/inject: "true" 3 sidecar.istio.io/rewriteAppHTTPProbers: "true" spec: containers: - image: <image_url>
Service
リソースを適用します。$ oc apply -f <filename>
検証
CA によって信頼されるようになった安全な接続を使用して、サーバーレスアプリケーションにアクセスします。
$ curl --cacert root.crt <service_url>
コマンドの例
$ curl --cacert root.crt https://hello-default.apps.openshift.example.com
出力例
Hello Openshift!
9.1.4. mTLS で Service Mesh を使用する場合の Knative Serving メトリクスの有効化
サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。このセクションでは、Service Mesh および mTLS を使用する際に Knative Serving メトリクスを有効にする方法を説明します。
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- mTLS 機能を有効にして Red Hat OpenShift Service Mesh をインストールしています。
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc
) をインストールしている。 - OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
手順
prometheus
を Knative Serving カスタムリソース (CR) のobservability
仕様でmetrics.backend-destination
として指定します。apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: observability: metrics.backend-destination: "prometheus" ...
この手順により、メトリクスがデフォルトで無効になることを防ぎます。
以下のネットワークポリシーを適用して、Prometheus namespace からのトラフィックを許可します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring-ns namespace: knative-serving spec: ingress: - from: - namespaceSelector: matchLabels: name: "openshift-monitoring" podSelector: {} ...
istio-system
namespace のデフォルトのサービスメッシュコントロールプレーンを変更して再適用し、以下の仕様が含まれるようにします。... spec: proxy: networking: trafficControl: inbound: excludedPorts: - 8444 ...
9.1.5. Kourier が有効にされている場合のサービスメッシュの OpenShift Serverless との統合
Kourier が既に有効になっている場合でも、OpenShift Serverless で Service Mesh を使用できます。この手順は、Kourier を有効にして Knative Serving を既にインストールしているが、後で Service Mesh 統合を追加することにした場合に役立つ可能性があります。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift CLI (
oc
) をインストールしている。 - OpenShift Serverless Operator と Knative Serving をクラスターにインストールします。
- Red Hat OpenShift Service Mesh をインストールします。OpenShift Serverless with Service Mesh and Kourier は、Red Hat OpenShift Service Mesh バージョン 1.x および 2.x の両方での使用がサポートされています。
手順
サービスメッシュと統合する必要のある namespace をメンバーとして
ServiceMeshMemberRoll
オブジェクトに追加します。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: members: - <namespace> 1 ...
- 1
- サービスメッシュと統合する namespace の一覧。
ServiceMeshMemberRoll
リソースを適用します。$ oc apply -f <filename>
Knative システム Pod から Knative サービスへのトラフィックフローを許可するネットワークポリシーを作成します。
サービスメッシュと統合する必要のある namespace ごとに、
NetworkPolicy
リソースを作成します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-serving-system-namespace namespace: <namespace> 1 spec: ingress: - from: - namespaceSelector: matchLabels: knative.openshift.io/part-of: "openshift-serverless" podSelector: {} policyTypes: - Ingress ...
- 1
- サービスメッシュと統合する必要のある namespace を追加します。
注記knative.openshift.io/part-of: "openshift-serverless"
ラベルが OpenShift Serverless 1.22.0 で追加されました。OpenShift Serverless 1.21.1 以前を使用している場合は、knative.openshift.io/part-of
ラベルをknative-serving
およびknative-serving-ingress
ネームスペースに追加します。knative-serving
namespace にラベルを追加します。$ oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless
knative-serving-ingress
namespace にラベルを追加します。$ oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless
NetworkPolicy
リソースを適用します。$ oc apply -f <filename>
9.1.6. Service Mesh のシークレットフィルターリングを使用した net-istio のメモリー使用量の改善
デフォルトでは、Kubernetes client-go
ライブラリーの informers の実装は、特定のタイプのすべてのリソースをフェッチします。これにより、多くのリソースが使用可能な場合にかなりのオーバーヘッドが発生する可能性があり、メモリーリークが原因で大規模なクラスターで Knative net-istio
イングレスコントローラーが失敗する可能性があります。ただし、Knative net-istio
イングレスコントローラーではフィルターリングメカニズムを使用できます。これにより、コントローラーは Knative 関連のシークレットのみを取得できます。このメカニズムを有効にするには、KnativeServing
カスタムリソース (CR) にアノテーションを追加します。
シークレットフィルターリングを有効にする場合は、すべてのシークレットに networking.internal.knative.dev/certificate-uid: "<id>" でラベルを付ける必要が
あります。それ以外の場合、Knative Serving はそれらを検出しないため、エラーが発生します。新規および既存のシークレットの両方にラベルを付ける必要があります。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
- Red Hat OpenShift Service Mesh をインストールします。OpenShift Serverless with Service Mesh は、Red Hat OpenShift Service Mesh バージョン 2.0.5 以降での使用でのみサポートされます。
- OpenShift Serverless Operator および Knative Serving をインストールします。
-
OpenShift CLI (
oc
) をインストールしている。
手順
serverless.openshift.io/enable-secret-informer-filtering
アノテーションをKnativeServing
CR に追加します。KnativeServing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving annotations: serverless.openshift.io/enable-secret-informer-filtering: "true" 1 spec: ingress: istio: enabled: true deployments: - annotations: sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" name: activator - annotations: sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" name: autoscaler
- 1
- このアノテーションを追加すると、環境変数
ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true
がnet-istio
コントローラー Pod に挿入されます。
注記このアノテーションは、デプロイメントを上書きして別の値を設定した場合は無視されます。