1.12.2. 既知の問題

  • OpenShift Serverless 1.16.0 にアップグレードする前に、OpenShift Container Platform をバージョン 4.6.30、4.7.11、またはそれ以降にアップグレードする必要があります。

  • AMQ Streams Operator は、OpenShift Serverless Operator のインストールまたはアップグレードを妨げる可能性があります。これが生じる場合、以下のエラーが Operator Lifecycle Manager (OLM) によって出力されます。 

    WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

    この問題を修正するには、OpenShift Serverless Operator をインストールまたはアップグレードする前に AMQ Streams Operator をアンインストールしてください。その後、AMQ Streams Operator を再インストールできます。

  • サービスメッシュが mTLS で有効にされている場合、サービスメッシュが Prometheus のメトリクスの収集を阻止するため、Knative Serving のメトリクスはデフォルトで無効にされます。Service Mesh および mTLS で使用する Knative Serving メトリクスを有効にする方法は、Serverless ドキュメントの Integrating Service Mesh with OpenShift Serverless セクションを参照してください。

  • Istio Ingress を有効にしてサービスメッシュ CR をデプロイする場合、istio-ingressgateway Pod に以下の警告が表示される可能性があります。 

    2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

    Knative サービスにもアクセスできない場合があります。

    以下の回避策を使用して、knative-local-gateway サービスを再作成することでこの問題を修正できます。

    1. istio-system namespace の既存の knative-local-gateway サービスを削除します。 

      $ oc delete services -n istio-system knative-local-gateway

    2. 以下の YAML が含まれる knative-local-gateway サービスを作成し、適用します。 

      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

  • クラスターに 1000 の Knative サービスがあり、Knative Serving の再インストールまたはアップグレードを実行する場合、KnativeServing カスタムリソース (CR) の状態が Ready になった後に最初の新しいサービスを作成すると遅延が生じます。

    3scale-kourier-control サービスは、新しいサービスの作成を処理する前に、既存のすべての Knative サービスを調整します。これにより、新規サービスは状態が Ready に更新されるまで、IngressNotConfigured または Unknown の状態で約 800 秒を費やすことになります。

  • Kafka チャネルまたは新しい Kafka ソースの新しいサブスクリプションを作成する場合は、新しく作成されたサブスクリプションまたはシンクが準備完了ステータスを報告した後、Kafka データプレーンがメッセージをディスパッチする準備ができるまでに遅延が生じる可能性があります。

    その結果、データプレーンが準備完了ステータスを報告していない間に送信されたメッセージは、サブスクライバーまたはシンクに配信されない場合があります。

    この問題および可能な回避策に関する詳細は、ナレッジアーティクル #6343981 を参照してください。