Sans serveur

• OpenShift Serverless utilise désormais Knative Serving 1.7.
• OpenShift Serverless utilise désormais Knative Eventing 1.7.
• OpenShift Serverless utilise désormais Kourier 1.7.
• OpenShift Serverless utilise désormais Knative (kn) CLI 1.7.
• OpenShift Serverless utilise désormais l'implémentation du courtier Knative pour Apache Kafka 1.7.
• Le plug-in kn func CLI utilise désormais la version 1.9.1 de func.
• Les moteurs d'exécution Node.js et TypeScript pour OpenShift Serverless Functions sont désormais généralement disponibles (GA).
• Le runtime Python pour OpenShift Serverless Functions est désormais disponible en tant qu'aperçu technologique.
• Le support multi-conteneurs pour Knative Serving est maintenant disponible en tant qu'aperçu technologique. Cette fonctionnalité vous permet d'utiliser un seul service Knative pour déployer un pod multi-conteneurs.

• Dans OpenShift Serverless 1.29 ou plus récent, les composants suivants de Knative Eventing seront réduits de deux pods à un seul :

  • imc-controller
  • imc-dispatcher
  • mt-broker-controller
  • mt-broker-filter
  • mt-broker-ingress

• L'annotation serverless.openshift.io/enable-secret-informer-filtering pour le CR Serving est maintenant obsolète. L'annotation n'est valable que pour Istio, et non pour Kourier.

  Avec OpenShift Serverless 1.28, l'opérateur OpenShift Serverless permet d'injecter la variable d'environnement ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID pour net-istio et net-kourier.

  Si vous activez le filtrage des secrets, tous vos secrets doivent être étiquetés avec networking.internal.knative.dev/certificate-uid: "<id>". Sinon, Knative Serving ne les détecte pas, ce qui entraîne des échecs. Vous devez étiqueter à la fois les nouveaux secrets et les secrets existants.

  Dans l'une des prochaines versions d'OpenShift Serverless, le filtrage des secrets sera activé par défaut. Pour éviter les échecs, étiquetez vos secrets à l'avance.

• Actuellement, les runtimes pour Python ne sont pas pris en charge pour OpenShift Serverless Functions sur IBM Power, IBM zSystems et IBM® LinuxONE.

  Les fonctions Node.js, TypeScript et Quarkus sont prises en charge sur ces architectures.

• Sur la plateforme Windows, les fonctions Python ne peuvent pas être construites, exécutées ou déployées localement à l'aide du constructeur Source-to-Image en raison des autorisations du fichier app.sh.

  Pour contourner ce problème, utilisez le sous-système Windows pour Linux.

• OpenShift Serverless utilise désormais Knative Serving 1.6.
• OpenShift Serverless utilise désormais Knative Eventing 1.6.
• OpenShift Serverless utilise désormais Kourier 1.6.
• OpenShift Serverless utilise désormais Knative (kn) CLI 1.6.
• OpenShift Serverless utilise désormais Knative Kafka 1.6.
• Le plug-in CLI kn func utilise désormais func 1.8.1.
• Les courtiers à espace de nommage sont désormais disponibles en tant qu'aperçu technologique. Ces courtiers peuvent être utilisés, par exemple, pour mettre en œuvre des politiques de contrôle d'accès basées sur les rôles (RBAC).
• KafkaSink utilise désormais par défaut le mode de contenu binaire CloudEvent. Le mode de contenu binaire est plus efficace que le mode structuré car il utilise des en-têtes dans son corps au lieu d'un CloudEvent. Par exemple, pour le protocole HTTP, il utilise les en-têtes HTTP.
• Vous pouvez désormais utiliser le framework gRPC sur le protocole HTTP/2 pour le trafic externe en utilisant OpenShift Route sur OpenShift Container Platform 4.10 et plus. Cela améliore l'efficacité et la vitesse des communications entre le client et le serveur.
• La version de l'API v1alpha1 des CRDs Knative Operator Serving et Eventings est obsolète dans la version 1.27. Elle sera supprimée dans les versions futures. Red Hat recommande fortement d'utiliser la version v1beta1 à la place. Cela n'affecte pas les installations existantes, car les CRD sont mis à jour automatiquement lors de la mise à niveau du Serverless Operator.
• La fonction de délai de livraison est désormais activée par défaut. Elle vous permet de spécifier le délai d'attente pour chaque requête HTTP envoyée. Cette fonctionnalité reste un aperçu technologique.

• Auparavant, les services Knative ne passaient pas toujours à l'état Ready, signalant qu'ils attendaient que l'équilibreur de charge soit prêt. Ce problème a été corrigé.

• L'intégration d'OpenShift Serverless avec Red Hat OpenShift Service Mesh fait en sorte que le pod net-kourier manque de mémoire au démarrage lorsque trop de secrets sont présents sur le cluster.

• Les courtiers à espace de noms peuvent laisser ClusterRoleBindings dans l'espace de noms de l'utilisateur même après la suppression des courtiers à espace de noms.

  Si cela se produit, supprimez le site ClusterRoleBinding nommé rbac-proxy-reviews-prom-rb-knative-kafka-broker-data-plane-{{.Namespace}} dans l'espace de noms de l'utilisateur.

• Si vous utilisez net-istio pour Ingress et activez mTLS via SMCP en utilisant security.dataPlane.mtls: true, Service Mesh déploie DestinationRules pour l'hôte *.local, ce qui n'autorise pas DomainMapping pour OpenShift Serverless.

  Pour contourner ce problème, activez mTLS en déployant PeerAuthentication au lieu d'utiliser security.dataPlane.mtls: true.

• OpenShift Serverless Functions with Quarkus est maintenant GA.
• OpenShift Serverless utilise désormais Knative Serving 1.5.
• OpenShift Serverless utilise désormais Knative Eventing 1.5.
• OpenShift Serverless utilise désormais Kourier 1.5.
• OpenShift Serverless utilise désormais Knative (kn) CLI 1.5.
• OpenShift Serverless utilise désormais Knative Kafka 1.5.
• OpenShift Serverless utilise désormais Knative Operator 1.3.
• Le plugin CLI kn func utilise désormais func 1.8.1.
• Les réclamations de volumes persistants (PVC) sont désormais des GA. Les PVC fournissent un stockage permanent des données pour vos services Knative.

• La nouvelle fonctionnalité des filtres de déclenchement est désormais disponible en avant-première pour les développeurs. Elle permet aux utilisateurs de spécifier un ensemble d'expressions de filtrage, où chaque expression est évaluée comme vraie ou fausse pour chaque événement.

  Pour activer les nouveaux filtres de déclenchement, ajoutez l'entrée new-trigger-filters: enabled dans la section du type KnativeEventing dans la carte de configuration de l'opérateur :

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...
  ...
  spec:
    config:
      features:
        new-trigger-filters: enabled
  ...

  Copy to Clipboard Toggle word wrap

• Knative Operator 1.3 ajoute la version mise à jour de v1beta1 de l'API pour operator.knative.dev.

  Pour passer de v1alpha1 à v1beta1 dans vos cartes de configuration des ressources personnalisées KnativeServing et KnativeEventing, modifiez la clé apiVersion:

  Exemple KnativeServing carte de configuration des ressources personnalisées

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  ...

  Copy to Clipboard Toggle word wrap

  Exemple KnativeEventing carte de configuration des ressources personnalisées

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...

  Copy to Clipboard Toggle word wrap

• Auparavant, le mode FIPS (Federal Information Processing Standards) était désactivé pour le courtier Kafka, la source Kafka et le puits Kafka. Ce problème a été corrigé et le mode FIPS est désormais disponible.

• Si vous utilisez net-istio pour Ingress et activez mTLS via SMCP en utilisant security.dataPlane.mtls: true, Service Mesh déploie DestinationRules pour l'hôte *.local, ce qui n'autorise pas DomainMapping pour OpenShift Serverless.

  Pour contourner ce problème, activez mTLS en déployant PeerAuthentication au lieu d'utiliser security.dataPlane.mtls: true.

• OpenShift Serverless utilise désormais Knative Serving 1.4.
• OpenShift Serverless utilise désormais Knative Eventing 1.4.
• OpenShift Serverless utilise désormais Kourier 1.4.
• OpenShift Serverless utilise désormais Knative (kn) CLI 1.4.
• OpenShift Serverless utilise désormais Knative Kafka 1.4.
• Le plugin CLI kn func utilise désormais func 1.7.0.
• Des plugins d'environnement de développement intégré (IDE) pour la création et le déploiement de fonctions sont désormais disponibles pour Visual Studio Code et IntelliJ.

• Knative Kafka broker est maintenant GA. Knative Kafka broker est une implémentation très performante de l'API Knative broker, ciblant directement Apache Kafka.

  Il est recommandé de ne pas utiliser le MT-Channel-Broker, mais plutôt le Knative Kafka Broker.

• Le Knative Kafka sink est maintenant GA. Un KafkaSink prend un CloudEvent et l'envoie à un sujet Apache Kafka. Les événements peuvent être spécifiés en mode de contenu structuré ou binaire.
• L'activation de TLS pour le trafic interne est désormais disponible en tant qu'aperçu technologique.

• Auparavant, Knative Serving avait un problème où la sonde de préparation échouait si le conteneur était redémarré après un échec de la sonde de durée de vie. Ce problème a été corrigé.

• Le mode Federal Information Processing Standards (FIPS) est désactivé pour le courtier Kafka, la source Kafka et le puits Kafka.
• L'objet SinkBinding ne prend pas en charge les noms de révision personnalisés pour les services.

• Le pod Knative Serving Controller ajoute un nouvel informateur pour surveiller les secrets dans le cluster. L'informateur inclut les secrets dans le cache, ce qui augmente la consommation de mémoire du pod contrôleur.

  Si le module manque de mémoire, vous pouvez contourner le problème en augmentant la limite de mémoire pour le déploiement.

• Si vous utilisez net-istio pour Ingress et activez mTLS via SMCP en utilisant security.dataPlane.mtls: true, Service Mesh déploie DestinationRules pour l'hôte *.local, ce qui n'autorise pas DomainMapping pour OpenShift Serverless.

  Pour contourner ce problème, activez mTLS en déployant PeerAuthentication au lieu d'utiliser security.dataPlane.mtls: true.

• OpenShift Serverless utilise désormais Knative Serving 1.3.
• OpenShift Serverless utilise désormais Knative Eventing 1.3.
• OpenShift Serverless utilise désormais Kourier 1.3.
• OpenShift Serverless utilise désormais Knative kn CLI 1.3.
• OpenShift Serverless utilise désormais Knative Kafka 1.3.
• Le plugin CLI kn func utilise désormais func 0.24.
• La prise en charge des services Knative par les conteneurs Init est désormais disponible de manière générale (GA).
• OpenShift Serverless logic est désormais disponible en tant que Developer Preview. Elle permet de définir des modèles de flux de travail déclaratifs pour gérer les applications sans serveur.
• Vous pouvez désormais utiliser le service de gestion des coûts avec OpenShift Serverless.

• L'intégration d'OpenShift Serverless avec Red Hat OpenShift Service Mesh fait en sorte que le pod net-istio-controller manque de mémoire au démarrage lorsque trop de secrets sont présents sur le cluster.

  Il est désormais possible d'activer le filtrage des secrets, ce qui permet à net-istio-controller de ne prendre en compte que les secrets portant une étiquette networking.internal.knative.dev/certificate-uid, réduisant ainsi la quantité de mémoire nécessaire.

• L'aperçu technologique d'OpenShift Serverless Functions utilise désormais par défaut les Buildpacks Cloud Native pour construire des images de conteneurs.

• Le mode Federal Information Processing Standards (FIPS) est désactivé pour le courtier Kafka, la source Kafka et le puits Kafka.

• Dans OpenShift Serverless 1.23, le support pour KafkaBindings et le webhook kafka-binding ont été supprimés. Cependant, un kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration existant peut subsister, pointant vers le service kafka-source-webhook, qui n'existe plus.

  Pour certaines spécifications de KafkaBindings sur le cluster, kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration peut être configuré pour transmettre tout événement de création et de mise à jour à diverses ressources, telles que Deployments, Knative Services ou Jobs, par le biais du webhook, qui échouerait alors.

  Pour contourner ce problème, supprimez manuellement kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration du cluster après avoir mis à jour OpenShift Serverless 1.23 :

  $ oc delete mutatingwebhookconfiguration kafkabindings.webhook.kafka.sources.knative.dev

  Copy to Clipboard Toggle word wrap

• Si vous utilisez net-istio pour Ingress et activez mTLS via SMCP en utilisant security.dataPlane.mtls: true, Service Mesh déploie DestinationRules pour l'hôte *.local, ce qui n'autorise pas DomainMapping pour OpenShift Serverless.

  Pour contourner ce problème, activez mTLS en déployant PeerAuthentication au lieu d'utiliser security.dataPlane.mtls: true.

• 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ésormais func 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 et kafka-webhook n'existent plus. Ils ont été remplacés par le composant kafka-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.

• 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:

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    deployments:
    - name: activator
      resources:
      - container: activator
        requests:
          cpu: 300m
          memory: 60Mi
        limits:
          cpu: 1000m
          memory: 1000Mi

  Copy to Clipboard Toggle word wrap
• 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 utilisant security.dataPlane.mtls: true, Service Mesh déploie DestinationRules pour l'hôte *.local, ce qui n'autorise pas DomainMapping pour OpenShift Serverless.

  Pour contourner ce problème, activez mTLS en déployant PeerAuthentication au lieu d'utiliser security.dataPlane.mtls: true.

• OpenShift Serverless utilise désormais Knative Serving 1.1.
• OpenShift Serverless utilise désormais Knative Eventing 1.1.
• OpenShift Serverless utilise désormais Kourier 1.1.
• OpenShift Serverless utilise désormais Knative (kn) CLI 1.1.
• OpenShift Serverless utilise désormais Knative Kafka 1.1.
• Le plugin CLI kn func utilise désormais func 0.23.
• Le support des conteneurs Init pour les services Knative est maintenant disponible en tant qu'aperçu technologique.
• La prise en charge des réclamations de volume persistantes (PVC) pour les services Knative est désormais disponible en tant qu'aperçu technologique.
• Les espaces de noms des systèmes knative-serving, knative-serving-ingress, knative-eventing et knative-kafka ont désormais l'étiquette knative.openshift.io/part-of: "openshift-serverless" par défaut.
• Le tableau de bord Knative Eventing - Kafka Broker/Trigger a été ajouté, ce qui permet de visualiser le courtier Kafka et les métriques de déclenchement dans la console web.
• Le tableau de bord Knative Eventing - KafkaSink a été ajouté, ce qui permet de visualiser les métriques de KafkaSink dans la console web.
• Le tableau de bord Knative Eventing - Broker/Trigger s'appelle désormais Knative Eventing - Channel-based Broker/Trigger.
• Le label knative.openshift.io/part-of: "openshift-serverless" a remplacé le label knative.openshift.io/system-namespace.
• Le style de nommage dans les fichiers de configuration YAML de Knative Serving est passé de la casse camel (ExampleName) au style trait d'union (example-name). À partir de cette version, utilisez la notation de style trait d'union lors de la création ou de l'édition des fichiers de configuration YAML de Knative Serving.

• Le mode Federal Information Processing Standards (FIPS) est désactivé pour le courtier Kafka, la source Kafka et le puits Kafka.

• 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 func utilise désormais func 0.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.

• Dans OpenShift Serverless 1.20.0, il y avait un problème de livraison d'événement affectant l'utilisation de kn event send pour envoyer des événements à un service. Ce problème est maintenant corrigé.
• Dans OpenShift Serverless 1.20.0 (func 0.20), les fonctions TypeScript créées avec le modèle http ne parvenaient pas à se déployer sur le cluster. Ce problème est maintenant corrigé.
• Dans OpenShift Serverless 1.20.0 (func 0.20), le déploiement d'une fonction utilisant le registre gcr.io échouait avec une erreur. Ce problème est maintenant corrigé.
• Dans OpenShift Serverless 1.20.0 (func 0.20), la création d'un répertoire de projet de fonction Springboot avec la commande kn func create et l'exécution de la commande kn func build ont échoué avec un message d'erreur. Ce problème est maintenant corrigé.
• Dans OpenShift Serverless 1.19.0 (func 0.19), certains runtimes étaient incapables de construire une fonction en utilisant podman. Ce problème est maintenant corrigé.

• 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) DomainMapping pour mapper un domaine personnalisé à un courtier, vous devez configurer la CR DomainMapping avec le service d'entrée du courtier et ajouter le chemin d'accès exact du courtier au domaine personnalisé :

  Exemple DomainMapping CR

  apiVersion: serving.knative.dev/v1alpha1
  kind: DomainMapping
  metadata:
    name: <domain-name>
    namespace: knative-eventing
  spec:
    ref:
      name: broker-ingress
      kind: Service
      apiVersion: v1

  Copy to Clipboard Toggle word wrap

  L'URI du courtier est alors <domain-name>/<broker-namespace>/<broker-name>.

• 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ésormais func 0.20.

• Le courtier Kafka est désormais disponible en tant qu'aperçu technologique.

  Important

  Le 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 commande kn service create sont obsolètes. Utilisez plutôt les drapeaux --scale-min et --scale-max.

• 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/

  Copy to Clipboard Toggle word wrap

  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

  Copy to Clipboard Toggle word wrap

  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 commande kn 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

  Copy to Clipboard Toggle word wrap

  Pour contourner le problème, vous pouvez remplacer la propriété builder par gcr.io/paketo-buildpacks/builder:base dans le fichier de configuration de la fonction func.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

  Copy to Clipboard Toggle word wrap

  Pour contourner le problème, utilisez un registre différent de celui de gcr.io, tel que quay.io ou docker.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: []

  Copy to Clipboard Toggle word wrap

  avec ceci :

  buildEnvs:
  - name: BP_NODE_RUN_SCRIPTS
    value: build

  Copy to Clipboard Toggle word wrap

• 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

  Copy to Clipboard Toggle word wrap

  • La solution suivante permet de résoudre ce problème :

    1. Mettez à jour le service podman en ajoutant --time=0 à la définition du service ExecStart:

       Exemple de configuration de service

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

       Copy to Clipboard Toggle word wrap

    2. Redémarrez le service podman en exécutant les commandes suivantes :

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • Vous pouvez également exposer l'API podman en utilisant TCP :

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

    Copy to Clipboard Toggle word wrap

• OpenShift Serverless utilise désormais Knative Serving 0.25.
• OpenShift Serverless utilise désormais Knative Eventing 0.25.
• OpenShift Serverless utilise désormais Kourier 0.25.
• OpenShift Serverless utilise désormais Knative (kn) CLI 0.25.
• OpenShift Serverless utilise désormais Knative Kafka 0.25.
• Le plugin CLI kn func utilise désormais func 0.19.
• L'API KafkaBinding est obsolète dans OpenShift Serverless 1.19.0 et sera supprimée dans une prochaine version.
• La redirection HTTPS est maintenant supportée et peut être configurée soit globalement pour un cluster, soit pour chaque service Knative.

• Dans les versions précédentes, le répartiteur du canal Kafka n'attendait que le succès du commit local avant de répondre, ce qui pouvait entraîner la perte d'événements en cas de défaillance d'un nœud Apache Kafka. Le répartiteur du canal Kafka attend désormais que toutes les répliques synchronisées s'engagent avant de répondre.

• Dans func version 0.19, 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

  Copy to Clipboard Toggle word wrap

  • La solution suivante permet de résoudre ce problème :

    1. Mettez à jour le service podman en ajoutant --time=0 à la définition du service ExecStart:

       Exemple de configuration de service

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

       Copy to Clipboard Toggle word wrap

    2. Redémarrez le service podman en exécutant les commandes suivantes :

       $ systemctl --user daemon-reload

       Copy to Clipboard Toggle word wrap

       $ systemctl restart --user podman.socket

       Copy to Clipboard Toggle word wrap

  • Vous pouvez également exposer l'API podman en utilisant TCP :

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

    Copy to Clipboard Toggle word wrap

• OpenShift Serverless utilise désormais Knative Serving 0.24.0.
• OpenShift Serverless utilise désormais Knative Eventing 0.24.0.
• OpenShift Serverless utilise désormais Kourier 0.24.0.
• OpenShift Serverless utilise maintenant Knative (kn) CLI 0.24.0.
• OpenShift Serverless utilise désormais Knative Kafka 0.24.7.
• Le plugin CLI kn func utilise désormais func 0.18.0.

• Dans la prochaine version OpenShift Serverless 1.19.0, le schéma d'URL des routes externes sera par défaut HTTPS pour une sécurité accrue.

  Si vous ne souhaitez pas que cette modification s'applique à vos charges de travail, vous pouvez remplacer le paramètre par défaut avant de passer à la version 1.19.0, en ajoutant le fichier YAML suivant à votre ressource personnalisée (CR) KnativeServing:

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "http"
  ...

  Copy to Clipboard Toggle word wrap

  Si vous voulez que le changement s'applique déjà à la version 1.18.0, ajoutez le YAML suivant :

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "https"
  ...

  Copy to Clipboard Toggle word wrap

• Dans la prochaine version OpenShift Serverless 1.19.0, le type de service par défaut par lequel la passerelle Kourier est exposée sera ClusterIP et non LoadBalancer.

  Si vous ne souhaitez pas que cette modification s'applique à vos charges de travail, vous pouvez remplacer le paramètre par défaut avant la mise à niveau vers la version 1.19.0, en ajoutant le fichier YAML suivant à votre ressource personnalisée (CR) KnativeServing:

  ...
  spec:
    ingress:
      kourier:
        service-type: LoadBalancer
  ...

  Copy to Clipboard Toggle word wrap
• Vous pouvez désormais utiliser les volumes emptyDir avec OpenShift Serverless. Voir la documentation OpenShift Serverless sur Knative Serving pour plus de détails.
• Les modèles Rust sont désormais disponibles lorsque vous créez une fonction à l'aide de kn func.

• La version précédente 1.4 de Camel-K n'était pas compatible avec OpenShift Serverless 1.17.0. Le problème dans Camel-K a été corrigé, et la version 1.4.1 de Camel-K peut être utilisée avec OpenShift Serverless 1.17.0.

• Auparavant, si vous créiez un nouvel abonnement pour un canal Kafka ou une nouvelle source Kafka, il était possible que le plan de données Kafka ne soit pas prêt à distribuer les messages après que l'abonnement ou le puits nouvellement créé ait signalé un statut prêt.

  Par conséquent, les messages envoyés pendant la période où le plan de données n'indiquait pas qu'il était prêt peuvent ne pas avoir été transmis à l'abonné ou au destinataire.

  Dans OpenShift Serverless 1.18.0, le problème est corrigé et les messages initiaux ne sont plus perdus. Pour plus d'informations sur ce problème, voir l'article #6343981 de la base de connaissances.

• Les anciennes versions du CLI Knative kn peuvent utiliser d'anciennes versions des API Knative Serving et Knative Eventing. Par exemple, la version 0.23.2 du CLI kn utilise la version de l'API v1alpha1.

  D'autre part, les nouvelles versions d'OpenShift Serverless peuvent ne plus prendre en charge les anciennes versions de l'API. Par exemple, OpenShift Serverless 1.18.0 ne prend plus en charge la version v1alpha1 de l'API kafkasources.sources.knative.dev.

  Par conséquent, l'utilisation d'une ancienne version de la CLI Knative kn avec une version plus récente d'OpenShift Serverless peut produire une erreur parce que kn ne peut pas trouver l'API obsolète. Par exemple, la version 0.23.2 du CLI kn ne fonctionne pas avec OpenShift Serverless 1.18.0.

  Pour éviter tout problème, utilisez la dernière version de kn CLI disponible pour votre version d'OpenShift Serverless. Pour OpenShift Serverless 1.18.0, utilisez Knative kn CLI 0.24.0.

• Source Kafka
• Canal Kafka
• Courtier Kafka
• Puits Kafka

• Quarkus
• Node.js
• TypeScript

• Commencer avec les fonctions.

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Votre cluster a la capacité Marketplace activée ou la source du catalogue Red Hat Operator configurée manuellement.
• Vous vous êtes connecté à la console web de OpenShift Container Platform.

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Votre cluster a la capacité Marketplace activée ou la source du catalogue Red Hat Operator configurée manuellement.
• Vous vous êtes connecté au cluster OpenShift Container Platform.

• Une fois l'OpenShift Serverless Operator installé, vous pouvez installer Knative Serving ou Knative Eventing.

Conditions préalables

• Vous vous êtes connecté à la console web de OpenShift Container Platform.

• OpenShift Serverless Operator et Knative Serving sont installés sur votre cluster OpenShift Container Platform.

  Important

  Si libc n'est pas disponible, vous risquez d'obtenir l'erreur suivante lorsque vous exécutez des commandes CLI :

  $ kn: No such file or directory

  Copy to Clipboard Toggle word wrap
• Si vous souhaitez utiliser les étapes de vérification pour cette procédure, vous devez installer le CLI OpenShift (oc).

Vérification

• Exécutez les commandes suivantes pour vérifier que les ressources et la route Knative CLI correctes ont été créées :

  $ oc get ConsoleCLIDownload

  Copy to Clipboard Toggle word wrap

  Exemple de sortie

  NAME                  DISPLAY NAME                                             AGE
  kn                    kn - OpenShift Serverless Command Line Interface (CLI)   2022-09-20T08:41:18Z
  oc-cli-downloads      oc - OpenShift Command Line Interface (CLI)              2022-09-20T08:00:20Z

  Copy to Clipboard Toggle word wrap

  $ oc get route -n openshift-serverless

  Copy to Clipboard Toggle word wrap

  Exemple de sortie

  NAME   HOST/PORT                                  PATH   SERVICES                      PORT       TERMINATION     WILDCARD
  kn     kn-openshift-serverless.apps.example.com          knative-openshift-metrics-3   http-cli   edge/Redirect   None

  Copy to Clipboard Toggle word wrap

Conditions préalables

• Vous disposez d'un abonnement OpenShift Container Platform actif sur votre compte Red Hat.

Conditions préalables

• Si vous n'utilisez pas RHEL ou Fedora, assurez-vous que libc est installé dans un répertoire de votre chemin de bibliothèque.

  Important

  Si libc n'est pas disponible, vous risquez d'obtenir l'erreur suivante lorsque vous exécutez des commandes CLI :

  $ kn: No such file or directory

  Copy to Clipboard Toggle word wrap

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Vous vous êtes connecté à la console web de OpenShift Container Platform.
• Vous avez installé OpenShift Serverless Operator.

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Vous avez installé OpenShift Serverless Operator.
• Installez le CLI OpenShift (oc).

• Si vous souhaitez utiliser l'architecture événementielle de Knative, vous pouvez installer Knative Eventing.

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Vous vous êtes connecté à la console web de OpenShift Container Platform.
• Vous avez installé OpenShift Serverless Operator.

Conditions préalables

• Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
• Vous avez installé OpenShift Serverless Operator.
• Installez le CLI OpenShift (oc).

Conditions préalables

• Vous avez installé OpenShift Serverless Operator et Knative Eventing sur votre cluster.
• Vous avez accès à un cluster Red Hat AMQ Streams.
• Installez le CLI OpenShift (oc) si vous souhaitez utiliser les étapes de vérification.

• Vous disposez des droits d'administrateur de cluster sur OpenShift Container Platform.

• Vous êtes connecté à la console web de OpenShift Container Platform.

• Si vous souhaitez utiliser les services Knative, vous pouvez installer Knative Serving.

• L'opérateur OpenShift Serverless et Knative Serving sont installés sur votre cluster.

  Note

  Les fonctions sont déployées en tant que service Knative. Si vous souhaitez utiliser une architecture pilotée par les événements avec vos fonctions, vous devez également installer Knative Eventing.

• Vous avez installé le CLIoc .
• Vous avez installé le CLI Knative (kn ). L'installation du CLI Knative permet d'utiliser les commandes kn func pour créer et gérer des fonctions.
• Vous avez installé Docker Container Engine ou Podman version 3.4.7 ou supérieure.
• Vous avez accès à un registre d'images disponible, tel que le OpenShift Container Registry.
• Si vous utilisez Quay.io comme registre d'images, vous devez vous assurer que le dépôt n'est pas privé, ou que vous avez suivi la documentation d'OpenShift Container Platform sur l'autorisation des pods à référencer des images à partir d'autres registres sécurisés.
• Si vous utilisez le OpenShift Container Registry, un administrateur de cluster doit exposer le registre.

• Pour plus d'informations sur Docker Container Engine ou Podman, voir Options d'outils de construction de conteneurs.
• Voir la section Démarrer avec les fonctions.

• Créez un service Knative à partir de la console web d'OpenShift Container Platform.

  Pour plus d'informations, voir Création d'applications à l'aide de la perspective du développeur.

• Créer un service Knative en utilisant le CLI Knative (kn).
• Créer et appliquer un objet Knative Service sous la forme d'un fichier YAML, en utilisant le CLI oc.

• Une limite souple est une limite de demande ciblée, plutôt qu'une limite strictement appliquée. Par exemple, en cas d'augmentation soudaine du trafic, la limite souple peut être dépassée.

• Une limite stricte est une limite supérieure de demandes strictement appliquée. Si la concurrence atteint la limite supérieure, les demandes excédentaires sont mises en mémoire tampon et doivent attendre qu'il y ait suffisamment de capacité libre pour les exécuter.

  Important

  L'utilisation d'une configuration de limite stricte n'est recommandée que s'il existe un cas d'utilisation clair pour votre application. Le fait de spécifier une limite basse et stricte peut avoir un impact négatif sur le débit et la latence d'une application, et peut provoquer des démarrages à froid.