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 func
utilise désormaisfunc
0.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 event
est désormais disponible en tant qu'aperçu technologique. -
Les drapeaux
--min-scale
et--max-scale
de la commandekn service create
sont obsolètes. Utilisez plutôt les drapeaux--scale-min
et--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-display
Copy 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 lifecycle
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour contourner le problème, vous pouvez remplacer la propriété
builder
pargcr.io/paketo-buildpacks/builder:base
dans 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: 404
Copy 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.io
oudocker.io
.Les fonctions TypeScript créées avec le modèle
http
ne 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: build
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans
func
version 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": EOF
Copy 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=0
Copy 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-reload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl restart --user podman.socket
$ systemctl restart --user podman.socket
Copy 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:5534
Copy to Clipboard Copied! Toggle word wrap Toggle overflow