1.9. Notes de version pour Red Hat OpenShift Serverless 1.23.0
OpenShift Serverless 1.23.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.9.1. Nouvelles fonctionnalités Copier lienLien copié sur presse-papiers!
- OpenShift Serverless utilise désormais Knative Serving 1.2.
- OpenShift Serverless utilise désormais Knative Eventing 1.2.
- OpenShift Serverless utilise désormais Kourier 1.2.
-
OpenShift Serverless utilise désormais Knative (
kn
) CLI 1.2. - OpenShift Serverless utilise désormais Knative Kafka 1.2.
-
Le plugin CLI
kn func
utilise désormaisfunc
0.24. -
Il est désormais possible d'utiliser l'annotation
kafka.eventing.knative.dev/external.topic
avec le courtier Kafka. Cette annotation permet d'utiliser un topic existant géré en externe au lieu que le broker crée son propre topic interne. -
Les composants Kafka
kafka-ch-controller
etkafka-webhook
n'existent plus. Ils ont été remplacés par le composantkafka-webhook-eventing
. - L'aperçu technologique d'OpenShift Serverless Functions utilise désormais Source-to-Image (S2I) par défaut pour construire des images de conteneurs.
1.9.2. Problèmes connus Copier lienLien copié sur presse-papiers!
- Le mode Federal Information Processing Standards (FIPS) est désactivé pour le courtier Kafka, la source Kafka et le puits Kafka.
-
Si vous supprimez un espace de noms qui inclut un courtier Kafka, la suppression du finalisateur de l'espace de noms peut échouer si le secret
auth.secret.ref.name
du courtier est supprimé avant le courtier. L'exécution d'OpenShift Serverless avec un grand nombre de services Knative peut faire en sorte que les pods activateurs Knative s'approchent de leur limite de mémoire par défaut de 600 Mo. Ces pods peuvent être redémarrés si la consommation de mémoire atteint cette limite. Les requêtes et les limites pour le déploiement de l'activateur peuvent être configurées en modifiant la ressource personnalisée
KnativeServing
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Si vous utilisez Cloud Native Buildpacks comme stratégie de construction locale pour une fonction,
kn func
n'est pas en mesure de démarrer automatiquement podman ou d'utiliser un tunnel SSH vers un démon distant. Pour résoudre ces problèmes, il faut qu'un démon Docker ou podman soit déjà en cours d'exécution sur l'ordinateur de développement local avant de déployer une fonction. - Les constructions de fonctions sur le cluster échouent actuellement pour les systèmes d'exécution Quarkus et Golang. Elles fonctionnent correctement pour les exécutions Node, Typescript, Python et Springboot.
Si vous utilisez
net-istio
pour Ingress et activez mTLS via SMCP en utilisantsecurity.dataPlane.mtls: true
, Service Mesh déploieDestinationRules
pour l'hôte*.local
, ce qui n'autorise pasDomainMapping
pour OpenShift Serverless.Pour contourner ce problème, activez mTLS en déployant
PeerAuthentication
au lieu d'utilisersecurity.dataPlane.mtls: true
.