1.12. Notes de version pour Red Hat OpenShift Serverless 1.20.0
OpenShift Serverless 1.20.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.12.1. Nouvelles fonctionnalités Copier lienLien copié sur presse-papiers!
- OpenShift Serverless utilise désormais Knative Serving 0.26.
- OpenShift Serverless utilise désormais Knative Eventing 0.26.
- OpenShift Serverless utilise désormais Kourier 0.26.
-
OpenShift Serverless utilise désormais Knative (
kn) CLI 0.26. - OpenShift Serverless utilise désormais Knative Kafka 0.26.
-
Le plugin CLI
kn funcutilise désormaisfunc0.20. Le courtier Kafka est désormais disponible en tant qu'aperçu technologique.
ImportantLe courtier Kafka, qui est actuellement en avant-première technologique, n'est pas pris en charge par FIPS.
-
Le plugin
kn eventest désormais disponible en tant qu'aperçu technologique. -
Les drapeaux
--min-scaleet--max-scalede la commandekn service createsont obsolètes. Utilisez plutôt les drapeaux--scale-minet--scale-max.
1.12.2. Problèmes connus Copier lienLien copié sur presse-papiers!
OpenShift Serverless déploie les services Knative avec une adresse par défaut qui utilise HTTPS. Lors de l'envoi d'un événement à une ressource à l'intérieur du cluster, l'expéditeur n'a pas l'autorité de certification (CA) du cluster configurée. Cela entraîne l'échec de la livraison de l'événement, à moins que le cluster n'utilise des certificats globalement acceptés.
Par exemple, la livraison d'un événement à une adresse accessible au public fonctionne :
kn event send --to-url https://ce-api.foo.example.com/
$ kn event send --to-url https://ce-api.foo.example.com/Copy to Clipboard Copied! Toggle word wrap Toggle overflow En revanche, cette livraison échoue si le service utilise une adresse publique avec un certificat HTTPS délivré par une autorité de certification personnalisée :
kn event send --to Service:serving.knative.dev/v1:event-display
$ kn event send --to Service:serving.knative.dev/v1:event-displayCopy to Clipboard Copied! Toggle word wrap Toggle overflow L'envoi d'un événement à d'autres objets adressables, tels que les courtiers ou les canaux, n'est pas concerné par ce problème et fonctionne comme prévu.
- Le courtier Kafka ne fonctionne pas actuellement sur un cluster avec le mode Federal Information Processing Standards (FIPS) activé.
Si vous créez un répertoire de projet de fonction Springboot avec la commande
kn func create, l'exécution ultérieure de la commandekn func buildéchoue avec ce message d'erreur :[analyzer] no stack metadata found at path '' [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle
[analyzer] no stack metadata found at path '' [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pour contourner le problème, vous pouvez remplacer la propriété
builderpargcr.io/paketo-buildpacks/builder:basedans le fichier de configuration de la fonctionfunc.yaml.Le déploiement d'une fonction à l'aide du registre
gcr.ioéchoue avec ce message d'erreur :Error: failed to get credentials: failed to verify credentials: status code: 404
Error: failed to get credentials: failed to verify credentials: status code: 404Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour contourner le problème, utilisez un registre différent de celui de
gcr.io, tel quequay.iooudocker.io.Les fonctions TypeScript créées avec le modèle
httpne se déploient pas sur le cluster.Pour contourner le problème, remplacez la section suivante dans le fichier
func.yaml:buildEnvs: []
buildEnvs: []Copy to Clipboard Copied! Toggle word wrap Toggle overflow avec ceci :
buildEnvs: - name: BP_NODE_RUN_SCRIPTS value: build
buildEnvs: - name: BP_NODE_RUN_SCRIPTS value: buildCopy to Clipboard Copied! Toggle word wrap Toggle overflow Dans
funcversion 0.20, certains runtimes peuvent être incapables de construire une fonction en utilisant podman. Vous pouvez voir un message d'erreur similaire au suivant :ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow La solution suivante permet de résoudre ce problème :
Mettez à jour le service podman en ajoutant
--time=0à la définition du serviceExecStart:Exemple de configuration de service
ExecStart=/usr/bin/podman $LOGGING system service --time=0
ExecStart=/usr/bin/podman $LOGGING system service --time=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow Redémarrez le service podman en exécutant les commandes suivantes :
systemctl --user daemon-reload
$ systemctl --user daemon-reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl restart --user podman.socket
$ systemctl restart --user podman.socketCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Vous pouvez également exposer l'API podman en utilisant TCP :
podman system service --time=0 tcp:127.0.0.1:5534 &
$ podman system service --time=0 tcp:127.0.0.1:5534 & export DOCKER_HOST=tcp://127.0.0.1:5534Copy to Clipboard Copied! Toggle word wrap Toggle overflow