5.4. Courtiers


5.4.1. Courtiers

Les courtiers peuvent être utilisés en combinaison avec des déclencheurs pour transmettre des événements d'une source d'événements à un puits d'événements. Les événements sont envoyés d'une source d'événements à un broker sous la forme d'une requête HTTP POST. Une fois que les événements sont entrés dans le courtier, ils peuvent être filtrés par les attributs CloudEvent à l'aide de déclencheurs, puis envoyés sous la forme d'une requête HTTP POST à un puits d'événements.

Broker event delivery overview

5.4.2. Types de courtiers

Les administrateurs de clusters peuvent définir l'implémentation par défaut des courtiers pour un cluster. Lorsque vous créez un courtier, l'implémentation du courtier par défaut est utilisée, à moins que vous ne fournissiez des configurations définies dans l'objet Broker.

5.4.2.1. Mise en œuvre par défaut du courtier à des fins de développement

Knative fournit une implémentation par défaut d'un courtier basé sur un canal. Ce courtier peut être utilisé à des fins de développement et de test, mais il ne fournit pas de garanties suffisantes en matière de livraison d'événements pour les environnements de production. Le courtier par défaut est soutenu par l'implémentation du canal InMemoryChannel par défaut.

Si vous souhaitez utiliser Apache Kafka pour réduire les sauts de réseau, utilisez l'implémentation du courtier Knative pour Apache Kafka. Ne configurez pas le courtier basé sur les canaux pour qu'il soit soutenu par l'implémentation du canal KafkaChannel.

5.4.2.2. Mise en œuvre d'un courtier Knative pour Apache Kafka, prêt pour la production

Pour les déploiements Knative Eventing prêts pour la production, Red Hat recommande d'utiliser l'implémentation du courtier Knative pour Apache Kafka. Le courtier est une implémentation native d'Apache Kafka du courtier Knative, qui envoie les CloudEvents directement à l'instance Kafka.

Le courtier Knative dispose d'une intégration native avec Kafka pour le stockage et l'acheminement des événements. Cela permet une meilleure intégration avec Kafka pour le modèle de courtier et de déclencheur par rapport à d'autres types de courtiers, et réduit les sauts de réseau. Les autres avantages de la mise en œuvre du courtier Knative sont les suivants :

  • Garanties de livraison au moins une fois
  • Livraison ordonnée des événements, basée sur l'extension de partitionnement CloudEvents
  • Haute disponibilité du plan de contrôle
  • Un plan de données extensible horizontalement

L'implémentation du courtier Knative pour Apache Kafka stocke les CloudEvents entrants en tant qu'enregistrements Kafka, en utilisant le mode de contenu binaire. Cela signifie que tous les attributs et extensions de CloudEvent sont mappés en tant qu'en-têtes sur l'enregistrement Kafka, tandis que la spécification data du CloudEvent correspond à la valeur de l'enregistrement Kafka.

5.4.3. Création de courtiers

Knative fournit une implémentation par défaut d'un courtier basé sur un canal. Ce courtier peut être utilisé à des fins de développement et de test, mais il n'offre pas de garanties suffisantes en matière de livraison d'événements pour les environnements de production.

Si un administrateur de cluster a configuré votre déploiement OpenShift Serverless pour utiliser Apache Kafka comme type de courtier par défaut, la création d'un courtier en utilisant les paramètres par défaut crée un courtier Knative pour Apache Kafka.

Si votre déploiement OpenShift Serverless n'est pas configuré pour utiliser le courtier Knative pour Apache Kafka comme type de courtier par défaut, le courtier basé sur les canaux est créé lorsque vous utilisez les paramètres par défaut dans les procédures suivantes.

5.4.3.1. Créer un courtier en utilisant le CLI Knative

Les courtiers peuvent être utilisés en combinaison avec des déclencheurs pour transmettre des événements d'une source d'événements à un puits d'événements. L'utilisation de la CLI Knative (kn) pour créer des courtiers offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML. Vous pouvez utiliser la commande kn broker create pour créer un courtier.

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez installé le CLI Knative (kn).
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

  • Créer un courtier :

    $ kn broker create <nom_du_courtier>

Vérification

  1. La commande kn permet d'obtenir la liste de tous les courtiers existants :

    $ kn broker list

    Exemple de sortie

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

  2. Facultatif : Si vous utilisez la console web de OpenShift Container Platform, vous pouvez naviguer vers la vue Topology dans la perspective Developer, et observer que le courtier existe :

    View the broker in the web console Topology view

5.4.3.2. Création d'un courtier par l'annotation d'un déclencheur

Les courtiers peuvent être utilisés en combinaison avec des déclencheurs pour transmettre des événements d'une source d'événements à un puits d'événements. Vous pouvez créer un broker en ajoutant l'annotation eventing.knative.dev/injection: enabled à un objet Trigger.

Important

Si vous créez un courtier en utilisant l'annotation eventing.knative.dev/injection: enabled, vous ne pouvez pas supprimer ce courtier sans les autorisations de l'administrateur de la grappe. Si vous supprimez le courtier sans qu'un administrateur de cluster ait d'abord supprimé cette annotation, le courtier est à nouveau créé après la suppression.

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Installez le CLI OpenShift (oc).
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

  1. Créez un objet Trigger sous la forme d'un fichier YAML comportant l'annotation eventing.knative.dev/injection: enabled:

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      annotations:
        eventing.knative.dev/injection: enabled
      name: <trigger_name>
    spec:
      broker: default
      subscriber: 1
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: <service_name>
    1
    Spécifiez les détails du puits d'événements, ou subscriber, vers lequel le déclencheur envoie des événements.
  2. Appliquer le fichier YAML Trigger:

    $ oc apply -f <filename>

Vérification

Vous pouvez vérifier que le courtier a été créé avec succès en utilisant le CLI oc, ou en l'observant dans la vue Topology de la console web.

  1. Entrez la commande suivante oc pour obtenir le courtier :

    oc -n <namespace> get broker default

    Exemple de sortie

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. Facultatif : Si vous utilisez la console web de OpenShift Container Platform, vous pouvez naviguer vers la vue Topology dans la perspective Developer, et observer que le courtier existe :

    View the broker in the web console Topology view

5.4.3.3. Créer un courtier en étiquetant un espace de noms

Les courtiers peuvent être utilisés en combinaison avec des déclencheurs pour transmettre des événements d'une source d'événements à un puits d'événements. Vous pouvez créer automatiquement le courtier default en étiquetant un espace de noms dont vous êtes le propriétaire ou pour lequel vous disposez de droits d'écriture.

Note

Les courtiers créés à l'aide de cette méthode ne sont pas supprimés si vous retirez l'étiquette. Vous devez les supprimer manuellement.

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Installez le CLI OpenShift (oc).
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

  • Étiqueter un espace de noms avec eventing.knative.dev/injection=enabled:

    oc label namespace <namespace> eventing.knative.dev/injection=enabled

Vérification

Vous pouvez vérifier que le courtier a été créé avec succès en utilisant le CLI oc, ou en l'observant dans la vue Topology de la console web.

  1. Utilisez la commande oc pour obtenir le courtier :

    oc -n <namespace> get broker <broker_name>

    Example command

    $ oc -n default get broker default

    Exemple de sortie

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. Facultatif : Si vous utilisez la console web de OpenShift Container Platform, vous pouvez naviguer vers la vue Topology dans la perspective Developer, et observer que le courtier existe :

    View the broker in the web console Topology view

5.4.3.4. Suppression d'un courtier créé par injection

Si vous créez un courtier par injection et que vous souhaitez ensuite le supprimer, vous devez le faire manuellement. Les courtiers créés à l'aide d'une étiquette d'espace de noms ou d'une annotation de déclenchement ne sont pas supprimés définitivement si vous supprimez l'étiquette ou l'annotation.

Conditions préalables

  • Installez le CLI OpenShift (oc).

Procédure

  1. Supprimer l'étiquette eventing.knative.dev/injection=enabled de l'espace de noms :

    oc label namespace <namespace> eventing.knative.dev/injection-

    La suppression de l'annotation empêche Knative de recréer le courtier après l'avoir supprimé.

  2. Supprime le courtier de l'espace de noms sélectionné :

    oc -n <namespace> delete broker <broker_name>

Vérification

  • Utilisez la commande oc pour obtenir le courtier :

    oc -n <namespace> get broker <broker_name>

    Example command

    $ oc -n default get broker default

    Exemple de sortie

    No resources found.
    Error from server (NotFound): brokers.eventing.knative.dev "default" not found

5.4.3.5. Création d'un courtier à l'aide de la console web

Une fois Knative Eventing installé sur votre cluster, vous pouvez créer un broker en utilisant la console web. L'utilisation de la console web d'OpenShift Container Platform offre une interface utilisateur rationalisée et intuitive pour créer un broker.

Conditions préalables

  • Vous vous êtes connecté à la console web de OpenShift Container Platform.
  • L'opérateur OpenShift Serverless, Knative Serving et Knative Eventing sont installés sur le cluster.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.

Procédure

  1. Dans la perspective Developer, naviguez vers Add Broker. La page Broker s'affiche.
  2. Facultatif. Mettez à jour le site Name du courtier. Si vous ne mettez pas à jour le nom, le courtier généré s'appelle default.
  3. Cliquez sur Create.

Vérification

Vous pouvez vérifier que le courtier a été créé en affichant les composants du courtier dans la page Topology.

  1. Dans la perspective Developer, naviguez jusqu'à Topology.
  2. Consultez les composants mt-broker-ingress, mt-broker-filter, et mt-broker-controller.

    View the broker components in the Topology view

5.4.3.6. Création d'un courtier en utilisant la perspective de l'administrateur

Les courtiers peuvent être utilisés en combinaison avec des déclencheurs pour transmettre des événements d'une source d'événements à un puits d'événements. Les événements sont envoyés d'une source d'événements à un broker sous la forme d'une requête HTTP POST. Une fois que les événements sont entrés dans le courtier, ils peuvent être filtrés par les attributs CloudEvent à l'aide de déclencheurs, puis envoyés sous la forme d'une requête HTTP POST à un puits d'événements.

Broker event delivery overview

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Vous vous êtes connecté à la console web et vous vous trouvez dans la perspective Administrator.
  • Vous disposez des droits d'administrateur de cluster pour OpenShift Container Platform.

Procédure

  1. Dans la perspective Administrator de la console web OpenShift Container Platform, naviguez vers Serverless Eventing.
  2. Dans la liste Create, sélectionnez Broker. Vous serez dirigé vers la page Create Broker.
  3. En option : Modifier la configuration YAML du courtier.
  4. Cliquez sur Create.

5.4.3.7. Prochaines étapes

5.4.3.8. Ressources supplémentaires

5.4.4. Configuration du canal d'accompagnement du courtier par défaut

Si vous utilisez un courtier basé sur des canaux, vous pouvez définir le type de canal de soutien par défaut pour le courtier sur InMemoryChannel ou KafkaChannel.

Conditions préalables

  • Vous disposez de droits d'administrateur sur OpenShift Container Platform.
  • Vous avez installé OpenShift Serverless Operator et Knative Eventing sur votre cluster.
  • Vous avez installé le CLI OpenShift (oc).
  • Si vous souhaitez utiliser les canaux Apache Kafka comme type de canal de sauvegarde par défaut, vous devez également installer le CR KnativeKafka sur votre cluster.

Procédure

  1. Modifier la ressource personnalisée (CR) KnativeEventing pour ajouter des détails de configuration pour la carte de configuration config-br-default-channel:

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        config-br-default-channel:
          channel-template-spec: |
            apiVersion: messaging.knative.dev/v1beta1
            kind: KafkaChannel 2
            spec:
              numPartitions: 6 3
              replicationFactor: 3 4
    1
    Dans spec.config, vous pouvez spécifier les cartes de configuration pour lesquelles vous souhaitez ajouter des configurations modifiées.
    2
    La configuration du type de canal de sauvegarde par défaut. Dans cet exemple, l'implémentation du canal par défaut pour le cluster est KafkaChannel.
    3
    Le nombre de partitions pour le canal Kafka qui soutient le courtier.
    4
    Le facteur de réplication pour le canal Kafka qui soutient le courtier.
  2. Appliquer la mise à jour de KnativeEventing CR :

    $ oc apply -f <filename>

5.4.5. Configuration de la classe de courtier par défaut

Vous pouvez utiliser la carte de configuration config-br-defaults pour spécifier les paramètres de la classe de courtier par défaut pour Knative Eventing. Vous pouvez spécifier la classe de courtier par défaut pour l'ensemble du cluster ou pour un ou plusieurs espaces de noms. Actuellement, les types de courtiers MTChannelBasedBroker et Kafka sont pris en charge.

Conditions préalables

  • Vous disposez de droits d'administrateur sur OpenShift Container Platform.
  • Vous avez installé OpenShift Serverless Operator et Knative Eventing sur votre cluster.
  • Si vous souhaitez utiliser le courtier Knative pour Apache Kafka comme courtier par défaut, vous devez également installer le CR KnativeKafka sur votre cluster.

Procédure

  • Modifier la ressource personnalisée KnativeEventing pour ajouter des détails de configuration pour la carte de configuration config-br-defaults:

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      defaultBrokerClass: Kafka 1
      config: 2
        config-br-defaults: 3
          default-br-config: |
            clusterDefault: 4
              brokerClass: Kafka
              apiVersion: v1
              kind: ConfigMap
              name: kafka-broker-config 5
              namespace: knative-eventing 6
            namespaceDefaults: 7
              my-namespace:
                brokerClass: MTChannelBasedBroker
                apiVersion: v1
                kind: ConfigMap
                name: config-br-default-channel 8
                namespace: knative-eventing 9
    ...
    1
    La classe de courtier par défaut pour Knative Eventing.
    2
    Dans spec.config, vous pouvez spécifier les cartes de configuration pour lesquelles vous souhaitez ajouter des configurations modifiées.
    3
    La carte de configuration config-br-defaults spécifie les paramètres par défaut pour tout courtier qui ne spécifie pas de paramètres spec.config ou de classe de courtier.
    4
    La configuration de la classe de courtage par défaut à l'échelle du cluster. Dans cet exemple, l'implémentation de la classe de courtage par défaut pour le cluster est Kafka.
    5
    La carte de configuration kafka-broker-config spécifie les paramètres par défaut du courtier Kafka. Voir "Configurer le courtier Knative pour les paramètres Apache Kafka" dans la section "Ressources supplémentaires".
    6
    L'espace de noms dans lequel la carte de configuration kafka-broker-config existe.
    7
    La configuration de la classe de courtage par défaut de l'espace de noms. Dans cet exemple, l'implémentation de la classe de courtage par défaut pour l'espace de noms my-namespace est MTChannelBasedBroker. Vous pouvez spécifier des implémentations de classe de courtage par défaut pour plusieurs espaces de noms.
    8
    La carte de configuration config-br-default-channel spécifie le canal d'appui par défaut du courtier. Voir "Configurer le canal d'appui par défaut du courtier" dans la section "Ressources supplémentaires".
    9
    L'espace de noms dans lequel la carte de configuration config-br-default-channel existe.
    Important

    La configuration d'une valeur par défaut spécifique à l'espace de nommage est prioritaire sur les paramètres applicables à l'ensemble du cluster.

5.4.6. Mise en œuvre d'un courtier Knative pour Apache Kafka

Pour les déploiements Knative Eventing prêts pour la production, Red Hat recommande d'utiliser l'implémentation du courtier Knative pour Apache Kafka. Le courtier est une implémentation native d'Apache Kafka du courtier Knative, qui envoie les CloudEvents directement à l'instance Kafka.

Le courtier Knative dispose d'une intégration native avec Kafka pour le stockage et l'acheminement des événements. Cela permet une meilleure intégration avec Kafka pour le modèle de courtier et de déclencheur par rapport à d'autres types de courtiers, et réduit les sauts de réseau. Les autres avantages de la mise en œuvre du courtier Knative sont les suivants :

  • Garanties de livraison au moins une fois
  • Livraison ordonnée des événements, basée sur l'extension de partitionnement CloudEvents
  • Haute disponibilité du plan de contrôle
  • Un plan de données extensible horizontalement

L'implémentation du courtier Knative pour Apache Kafka stocke les CloudEvents entrants en tant qu'enregistrements Kafka, en utilisant le mode de contenu binaire. Cela signifie que tous les attributs et extensions de CloudEvent sont mappés en tant qu'en-têtes sur l'enregistrement Kafka, tandis que la spécification data du CloudEvent correspond à la valeur de l'enregistrement Kafka.

5.4.6.1. Création d'un courtier Apache Kafka lorsqu'il n'est pas configuré comme type de courtier par défaut

Si votre déploiement OpenShift Serverless n'est pas configuré pour utiliser le courtier Kafka comme type de courtier par défaut, vous pouvez utiliser l'une des procédures suivantes pour créer un courtier basé sur Kafka.

5.4.6.1.1. Créer un courtier Apache Kafka en utilisant YAML

La création de ressources Knative à l'aide de fichiers YAML utilise une API déclarative, qui permet de décrire des applications de manière déclarative et reproductible. Pour créer un courtier Kafka à l'aide de YAML, vous devez créer un fichier YAML qui définit un objet Broker, puis l'appliquer à l'aide de la commande oc apply.

Conditions préalables

  • OpenShift Serverless Operator, Knative Eventing et la ressource personnalisée KnativeKafka sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Créer un courtier basé sur Kafka sous la forme d'un fichier YAML :

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
      name: example-kafka-broker
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: kafka-broker-config 2
        namespace: knative-eventing
    1
    La classe du courtier. Si elle n'est pas spécifiée, les courtiers utilisent la classe par défaut, telle qu'elle est configurée par les administrateurs du cluster. Pour utiliser le courtier Kafka, cette valeur doit être Kafka.
    2
    La carte de configuration par défaut des courtiers Knative pour Apache Kafka. Cette carte de configuration est créée lorsque la fonctionnalité de courtier Kafka est activée sur le cluster par un administrateur de cluster.
  2. Appliquer le fichier YAML du courtier basé sur Kafka :

    $ oc apply -f <filename>
5.4.6.1.2. Création d'un courtier Apache Kafka qui utilise un sujet Kafka géré en externe

Si vous souhaitez utiliser un courtier Kafka sans lui permettre de créer son propre sujet interne, vous pouvez utiliser un sujet Kafka géré de manière externe. Pour ce faire, vous devez créer un objet Kafka Broker qui utilise l'annotation kafka.eventing.knative.dev/external.topic.

Conditions préalables

  • OpenShift Serverless Operator, Knative Eventing et la ressource personnalisée KnativeKafka sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez accès à une instance Kafka telle que Red Hat AMQ Streams, et avez créé un sujet Kafka.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Créer un courtier basé sur Kafka sous la forme d'un fichier YAML :

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka 1
        kafka.eventing.knative.dev/external.topic: <topic_name> 2
    ...
    1
    La classe du courtier. Si elle n'est pas spécifiée, les courtiers utilisent la classe par défaut, telle qu'elle est configurée par les administrateurs du cluster. Pour utiliser le courtier Kafka, cette valeur doit être Kafka.
    2
    Le nom du sujet Kafka que vous souhaitez utiliser.
  2. Appliquer le fichier YAML du courtier basé sur Kafka :

    $ oc apply -f <filename>
5.4.6.1.3. Mise en œuvre d'un courtier Knative pour Apache Kafka avec un plan de données isolé
Important

L'implémentation de Knative Broker pour Apache Kafka avec un plan de données isolé est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

L'implémentation de Knative Broker pour Apache Kafka comporte 2 plans :

Control plane
Il s'agit de contrôleurs qui communiquent avec l'API Kubernetes, surveillent les objets personnalisés et gèrent le plan de données.
Plan de données
L'ensemble des composants qui écoutent les événements entrants, communiquent avec Apache Kafka et envoient des événements aux puits d'événements. L'implémentation Knative Broker pour le plan de données Apache Kafka est l'endroit où les événements circulent. L'implémentation consiste en des déploiements kafka-broker-receiver et kafka-broker-dispatcher.

Lorsque vous configurez une classe Broker de Kafka, l'implémentation Knative Broker pour Apache Kafka utilise un plan de données partagé. Cela signifie que les déploiements kafka-broker-receiver et kafka-broker-dispatcher dans l'espace de noms knative-eventing sont utilisés pour tous les Brokers Apache Kafka dans le cluster.

Cependant, lorsque vous configurez une classe Broker de KafkaNamespaced, le contrôleur de courtier Apache Kafka crée un nouveau plan de données pour chaque espace de noms dans lequel un courtier existe. Ce plan de données est utilisé par tous les courtiers KafkaNamespaced dans cet espace de noms. Cela permet d'isoler les plans de données, de sorte que les déploiements kafka-broker-receiver et kafka-broker-dispatcher dans l'espace de noms de l'utilisateur ne sont utilisés que pour le courtier de cet espace de noms.

Important

En raison de la séparation des plans de données, cette fonction de sécurité crée plus de déploiements et utilise plus de ressources. À moins que vous n'ayez de telles exigences en matière d'isolation, utilisez un regular Broker avec une classe de Kafka.

5.4.6.1.4. Créer un courtier Knative pour Apache Kafka qui utilise un plan de données isolé
Important

L'implémentation de Knative Broker pour Apache Kafka avec un plan de données isolé est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Pour créer un courtier KafkaNamespaced, vous devez définir l'annotation eventing.knative.dev/broker.class en KafkaNamespaced.

Conditions préalables

  • OpenShift Serverless Operator, Knative Eventing et la ressource personnalisée KnativeKafka sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez accès à une instance Apache Kafka, telle que Red Hat AMQ Streams, et avez créé un sujet Kafka.
  • Vous avez créé un projet, ou avez accès à un projet, avec les rôles et permissions appropriés pour créer des applications et autres charges de travail dans OpenShift Container Platform.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Créer un courtier basé sur Apache Kafka en utilisant un fichier YAML :

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: KafkaNamespaced 1
      name: default
      namespace: my-namespace 2
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: my-config 3
    ...
    1
    Pour utiliser le courtier Apache Kafka avec des plans de données isolés, la valeur de la classe de courtier doit être KafkaNamespaced.
    2 3
    L'objet ConfigMap référencé my-config doit se trouver dans le même espace de noms que l'objet Broker, en l'occurrence my-namespace.
  2. Appliquer le fichier YAML du courtier basé sur Apache Kafka :

    $ oc apply -f <filename>
Important

L'objet ConfigMap dans spec.config doit être dans le même espace de noms que l'objet Broker:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
  namespace: my-namespace
data:
  ...

Après la création du premier objet Broker avec la classe KafkaNamespaced, les déploiements kafka-broker-receiver et kafka-broker-dispatcher sont créés dans l'espace de noms. Par la suite, tous les courtiers de la classe KafkaNamespaced dans le même espace de noms utiliseront le même plan de données. Si aucun courtier de la classe KafkaNamespaced n'existe dans l'espace de noms, le plan de données de l'espace de noms est supprimé.

5.4.6.2. Configuration des paramètres du courtier Apache Kafka

Vous pouvez configurer le facteur de réplication, les serveurs d'amorçage et le nombre de partitions de sujets pour un courtier Kafka, en créant une carte de configuration et en y faisant référence dans l'objet Kafka Broker.

Conditions préalables

  • Vous avez des permissions d'administrateur de cluster ou dédié sur OpenShift Container Platform.
  • OpenShift Serverless Operator, Knative Eventing et KnativeKafka custom resource (CR) sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez créé un projet ou avez accès à un projet qui a les rôles et les autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Modifiez la carte de configuration kafka-broker-config ou créez votre propre carte de configuration qui contient la configuration suivante :

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <config_map_name> 1
      namespace: <namespace> 2
    data:
      default.topic.partitions: <integer> 3
      default.topic.replication.factor: <integer> 4
      bootstrap.servers: <list_of_servers> 5
    1
    Le nom de la carte de configuration.
    2
    L'espace de noms dans lequel la carte de configuration existe.
    3
    Le nombre de partitions de sujets pour le courtier Kafka. Cela permet de contrôler la vitesse à laquelle les événements peuvent être envoyés au courtier. Un nombre plus élevé de partitions nécessite davantage de ressources informatiques.
    4
    Le facteur de réplication des messages thématiques. Cela permet d'éviter les pertes de données. Un facteur de réplication plus élevé nécessite davantage de ressources informatiques et de stockage.
    5
    Une liste de serveurs d'amorçage séparés par des virgules. Cela peut être à l'intérieur ou à l'extérieur du cluster OpenShift Container Platform, et c'est une liste de clusters Kafka que le courtier reçoit des événements de et envoie des événements à.
    Important

    La valeur default.topic.replication.factor doit être inférieure ou égale au nombre d'instances de courtiers Kafka dans votre cluster. Par exemple, si vous n'avez qu'un seul courtier Kafka, la valeur default.topic.replication.factor ne doit pas être supérieure à "1".

    Exemple de carte de configuration du courtier Kafka

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: kafka-broker-config
      namespace: knative-eventing
    data:
      default.topic.partitions: "10"
      default.topic.replication.factor: "3"
      bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"

  2. Appliquer la carte de configuration :

    oc apply -f <config_map_filename> $ oc apply -f <config_map_filename>
  3. Spécifiez la carte de configuration pour l'objet Kafka Broker:

    Exemple d'objet Broker

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      name: <broker_name> 1
      namespace: <namespace> 2
      annotations:
        eventing.knative.dev/broker.class: Kafka 3
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: <config_map_name> 4
        namespace: <namespace> 5
    ...

    1
    Le nom du courtier.
    2
    L'espace de noms dans lequel le courtier existe.
    3
    L'annotation de la classe du courtier. Dans cet exemple, le courtier est un courtier Kafka qui utilise la valeur de classe Kafka.
    4
    Le nom de la carte de configuration.
    5
    L'espace de noms dans lequel la carte de configuration existe.
  4. Appliquer le courtier :

    oc apply -f <broker_filename>

5.4.6.3. Configuration de la sécurité pour l'implémentation du courtier Knative pour Apache Kafka

Les clusters Kafka sont généralement sécurisés en utilisant les méthodes d'authentification TLS ou SASL. Vous pouvez configurer un courtier ou un canal Kafka pour travailler avec un cluster Red Hat AMQ Streams protégé en utilisant TLS ou SASL.

Note

Red Hat recommande d'activer à la fois SASL et TLS.

5.4.6.3.1. Configuration de l'authentification TLS pour les brokers Apache Kafka

Transport Layer Security (TLS) est utilisé par les clients et les serveurs Apache Kafka pour chiffrer le trafic entre Knative et Kafka, ainsi que pour l'authentification. TLS est la seule méthode de cryptage du trafic prise en charge par l'implémentation du courtier Knative pour Apache Kafka.

Conditions préalables

  • Vous avez des permissions d'administrateur de cluster ou dédié sur OpenShift Container Platform.
  • OpenShift Serverless Operator, Knative Eventing et KnativeKafka CR sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous disposez d'un certificat d'autorité de certification pour le cluster Kafka stocké dans un fichier .pem.
  • Vous disposez d'un certificat client pour le cluster Kafka et d'une clé stockée sous forme de fichiers .pem.
  • Installez le CLI OpenShift (oc).

Procédure

  1. Créez les fichiers de certificat en tant que secret dans l'espace de noms knative-eventing:

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SSL \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem
    Important

    Utilisez les noms de clés ca.crt, user.crt, et user.key. Ne les modifiez pas.

  2. Modifiez le CR KnativeKafka et ajoutez une référence à votre secret dans la spécification broker:

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...
5.4.6.3.2. Configuration de l'authentification SASL pour les brokers Apache Kafka

Simple Authentication and Security Layer (SASL) est utilisé par Apache Kafka pour l'authentification. Si vous utilisez l'authentification SASL sur votre cluster, les utilisateurs doivent fournir des informations d'identification à Knative pour communiquer avec le cluster Kafka ; sinon, les événements ne peuvent pas être produits ou consommés.

Conditions préalables

  • Vous avez des permissions d'administrateur de cluster ou dédié sur OpenShift Container Platform.
  • OpenShift Serverless Operator, Knative Eventing et KnativeKafka CR sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous disposez d'un nom d'utilisateur et d'un mot de passe pour un cluster Kafka.
  • Vous avez choisi le mécanisme SASL à utiliser, par exemple PLAIN, SCRAM-SHA-256, ou SCRAM-SHA-512.
  • Si TLS est activé, vous avez également besoin du fichier de certificat ca.crt pour le cluster Kafka.
  • Installez le CLI OpenShift (oc).

Procédure

  1. Créez les fichiers de certificat en tant que secret dans l'espace de noms knative-eventing:

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SASL_SSL \
      --from-literal=sasl.mechanism=<sasl_mechanism> \
      --from-file=ca.crt=caroot.pem \
      --from-literal=password="SecretPassword" \
      --from-literal=user="my-sasl-user"
    • Utilisez les noms de clés ca.crt, password, et sasl.mechanism. Ne les modifiez pas.
    • Si vous souhaitez utiliser SASL avec des certificats d'autorité de certification publique, vous devez utiliser l'indicateur tls.enabled=true, plutôt que l'argument ca.crt, lors de la création du secret. Par exemple :

      $ oc create secret -n <namespace> generic <kafka_auth_secret> \
        --from-literal=tls.enabled=true \
        --from-literal=password="SecretPassword" \
        --from-literal=saslType="SCRAM-SHA-512" \
        --from-literal=user="my-sasl-user"
  2. Modifiez le CR KnativeKafka et ajoutez une référence à votre secret dans la spécification broker:

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...

5.4.6.4. Ressources supplémentaires

5.4.7. Gestion des courtiers

Le CLI de Knative (kn) fournit des commandes qui peuvent être utilisées pour décrire et répertorier les courtiers existants.

5.4.7.1. Lister les courtiers existants en utilisant le CLI Knative

L'utilisation de la CLI Knative (kn) pour lister les courtiers offre une interface utilisateur simplifiée et intuitive. Vous pouvez utiliser la commande kn broker list pour lister les courtiers existants dans votre cluster en utilisant la CLI Knative.

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez installé le CLI Knative (kn).

Procédure

  • Dressez la liste de tous les courtiers existants :

    $ kn broker list

    Exemple de sortie

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

5.4.7.2. Décrire un courtier existant en utilisant le CLI Knative

L'utilisation de la CLI Knative (kn) pour décrire les courtiers offre une interface utilisateur simplifiée et intuitive. Vous pouvez utiliser la commande kn broker describe pour imprimer des informations sur les courtiers existants dans votre cluster en utilisant la CLI Knative.

Conditions préalables

  • OpenShift Serverless Operator et Knative Eventing sont installés sur votre cluster OpenShift Container Platform.
  • Vous avez installé le CLI Knative (kn).

Procédure

  • Décrire un courtier existant :

    $ kn broker describe <nom_du_courtier>

    Exemple de commande utilisant le courtier par défaut

    $ kn broker describe default

    Exemple de sortie

    Name:         default
    Namespace:    default
    Annotations:  eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ...
    Age:          22s
    
    Address:
      URL:    http://broker-ingress.knative-eventing.svc.cluster.local/default/default
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                  22s
      ++ Addressable            22s
      ++ FilterReady            22s
      ++ IngressReady           22s
      ++ TriggerChannelReady    22s

5.4.8. Livraison de l'événement

Vous pouvez configurer les paramètres de distribution des événements qui sont appliqués dans les cas où un événement ne parvient pas à être distribué à un récepteur d'événements. La configuration des paramètres d'acheminement des événements, y compris d'un puits de lettres mortes, garantit que les événements qui ne sont pas acheminés vers un puits d'événements sont réessayés. Dans le cas contraire, les événements non livrés sont abandonnés.

5.4.8.1. Modèles de comportement de livraison d'événements pour les canaux et les courtiers

Les différents types de canaux et de courtiers ont leurs propres modèles de comportement qui sont suivis pour la livraison des événements.

5.4.8.1.1. Canaux et courtiers Knative pour Apache Kafka

Si un événement est transmis avec succès à un canal Kafka ou à un récepteur de courtier, le récepteur répond par un code d'état 202, ce qui signifie que l'événement a été stocké en toute sécurité dans un sujet Kafka et qu'il n'est pas perdu.

Si le récepteur répond par un autre code d'état, l'événement n'est pas stocké en toute sécurité et l'utilisateur doit prendre des mesures pour résoudre le problème.

5.4.8.2. Paramètres de livraison d'événements configurables

Les paramètres suivants peuvent être configurés pour l'envoi d'événements :

Lettre morte pour l'évier
Vous pouvez configurer le paramètre de livraison deadLetterSink de sorte que si un événement n'est pas livré, il soit stocké dans le puits d'événements spécifié. Les événements non livrés qui ne sont pas stockés dans un puits de lettres mortes sont abandonnés. Le puits d'événements peut être n'importe quel objet adressable conforme au contrat de puits d'événements Knative, tel qu'un service Knative, un service Kubernetes ou un URI.
Tentatives
Vous pouvez définir un nombre minimum de tentatives de livraison avant que l'événement ne soit envoyé au puits de lettres mortes, en configurant le paramètre de livraison retry avec une valeur entière.
Délai de recul
Vous pouvez définir le paramètre de livraison backoffDelay pour spécifier le délai avant qu'une nouvelle tentative de livraison d'un événement ne soit effectuée après un échec. La durée du paramètre backoffDelay est spécifiée au format ISO 8601. Par exemple, PT1S indique un délai de 1 seconde.
Reculer dans la politique
The backoffPolicy delivery parameter can be used to specify the retry back off policy. The policy can be specified as either linear or exponential. When using the linear back off policy, the back off delay is equal to backoffDelay * <numberOfRetries>. When using the exponential backoff policy, the back off delay is equal to backoffDelay*2^<numberOfRetries>.

5.4.8.3. Exemples de configuration des paramètres de distribution des événements

Vous pouvez configurer les paramètres de livraison d'événements pour les objets Broker, Trigger, Channel et Subscription. Si vous configurez des paramètres de distribution d'événements pour un courtier ou un canal, ces paramètres sont propagés aux déclencheurs ou aux abonnements créés pour ces objets. Vous pouvez également définir des paramètres de livraison d'événements pour les déclencheurs ou les abonnements afin de remplacer les paramètres du courtier ou du canal.

Exemple d'objet Broker

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
...
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: eventing.knative.dev/v1alpha1
        kind: KafkaSink
        name: <sink_name>
    backoffDelay: <duration>
    backoffPolicy: <policy_type>
    retry: <integer>
...

Exemple d'objet Trigger

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
...
spec:
  broker: <broker_name>
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration>
    backoffPolicy: <policy_type>
    retry: <integer>
...

Exemple d'objet Channel

apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
...
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration>
    backoffPolicy: <policy_type>
    retry: <integer>
...

Exemple d'objet Subscription

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
...
spec:
  channel:
    apiVersion: messaging.knative.dev/v1
    kind: Channel
    name: <channel_name>
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration>
    backoffPolicy: <policy_type>
    retry: <integer>
...

5.4.8.4. Configuration de l'ordre de livraison des événements pour les déclencheurs

Si vous utilisez un courtier Kafka, vous pouvez configurer l'ordre de livraison des événements des déclencheurs aux puits d'événements.

Conditions préalables

  • OpenShift Serverless Operator, Knative Eventing et Knative broker implementation for Apache Kafka sont installés sur votre cluster OpenShift Container Platform.
  • L'utilisation du courtier Kafka est activée sur votre cluster et vous avez créé un courtier Kafka.
  • Vous avez créé un projet ou avez accès à un projet avec les rôles et autorisations appropriés pour créer des applications et d'autres charges de travail dans OpenShift Container Platform.
  • Vous avez installé le CLI OpenShift (oc).

Procédure

  1. Créer ou modifier un objet Trigger et définir l'annotation kafka.eventing.knative.dev/delivery.order:

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: <trigger_name>
      annotations:
         kafka.eventing.knative.dev/delivery.order: ordered
    ...

    Les garanties de livraison aux consommateurs prises en charge sont les suivantes :

    unordered
    Un consommateur non ordonné est un consommateur non bloquant qui délivre des messages non ordonnés, tout en préservant une bonne gestion des décalages.
    ordered

    Un consommateur ordonné est un consommateur bloquant par partition qui attend une réponse positive de l'abonné CloudEvent avant de délivrer le message suivant de la partition.

    La garantie de commande par défaut est unordered.

  2. Appliquer l'objet Trigger:

    $ oc apply -f <filename>
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.