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
サービスを再作成することでこの問題を修正できます。istio-system
namespace の既存のknative-local-gateway
サービスを削除します。$ oc delete services -n istio-system knative-local-gateway
以下の 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 を参照してください。