1.11. Notes de version pour Red Hat OpenShift Serverless 1.21.0
OpenShift Serverless 1.21.0 est maintenant disponible. Les nouvelles fonctionnalités, les changements et les problèmes connus qui concernent OpenShift Serverless sur OpenShift Container Platform sont inclus dans cette rubrique.
1.11.1. Nouvelles fonctionnalités
- OpenShift Serverless utilise désormais Knative Serving 1.0
- OpenShift Serverless utilise désormais Knative Eventing 1.0.
- OpenShift Serverless utilise désormais Kourier 1.0.
-
OpenShift Serverless utilise désormais Knative (
kn) CLI 1.0. - OpenShift Serverless utilise désormais Knative Kafka 1.0.
-
Le plugin CLI
kn funcutilise désormaisfunc0.21. - Le puits Kafka est maintenant disponible en tant qu'aperçu technologique.
-
Le projet open source Knative a commencé à déprécier les clés de configuration à base de camel en faveur de l'utilisation cohérente de clés à base de kebab. Par conséquent, la clé
defaultExternalScheme, précédemment mentionnée dans les notes de version 1.18.0 d'OpenShift Serverless, est maintenant obsolète et remplacée par la clédefault-external-scheme. Les instructions d'utilisation de la clé restent les mêmes.
1.11.2. Problèmes corrigés
-
Dans OpenShift Serverless 1.20.0, il y avait un problème de livraison d'événement affectant l'utilisation de
kn event sendpour envoyer des événements à un service. Ce problème est maintenant corrigé. -
Dans OpenShift Serverless 1.20.0 (
func0.20), les fonctions TypeScript créées avec le modèlehttpne parvenaient pas à se déployer sur le cluster. Ce problème est maintenant corrigé. -
Dans OpenShift Serverless 1.20.0 (
func0.20), le déploiement d'une fonction utilisant le registregcr.ioéchouait avec une erreur. Ce problème est maintenant corrigé. -
Dans OpenShift Serverless 1.20.0 (
func0.20), la création d'un répertoire de projet de fonction Springboot avec la commandekn func createet l'exécution de la commandekn func buildont échoué avec un message d'erreur. Ce problème est maintenant corrigé. -
Dans OpenShift Serverless 1.19.0 (
func0.19), certains runtimes étaient incapables de construire une fonction en utilisant podman. Ce problème est maintenant corrigé.
1.11.3. Problèmes connus
Actuellement, le contrôleur de mappage de domaine ne peut pas traiter l'URI d'un courtier qui contient un chemin qui n'est actuellement pas pris en charge.
Cela signifie que si vous souhaitez utiliser une ressource personnalisée (CR)
DomainMappingpour mapper un domaine personnalisé à un courtier, vous devez configurer la CRDomainMappingavec le service d'entrée du courtier et ajouter le chemin d'accès exact du courtier au domaine personnalisé :Exemple
DomainMappingCRapiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain-name> namespace: knative-eventing spec: ref: name: broker-ingress kind: Service apiVersion: v1L'URI du courtier est alors
<domain-name>/<broker-namespace>/<broker-name>.
