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.
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
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
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 :
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
.
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
Créez un objet
Trigger
sous la forme d'un fichier YAML comportant l'annotationeventing.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.
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.
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
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 :
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.
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.
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
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 :
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
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é.
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
-
Dans la perspective Developer, naviguez vers Add
Broker. La page Broker s'affiche. -
Facultatif. Mettez à jour le site Name du courtier. Si vous ne mettez pas à jour le nom, le courtier généré s'appelle
default
. - 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.
- Dans la perspective Developer, naviguez jusqu'à Topology.
Consultez les composants
mt-broker-ingress
,mt-broker-filter
, etmt-broker-controller
.
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.
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
-
Dans la perspective Administrator de la console web OpenShift Container Platform, naviguez vers Serverless
Eventing. - Dans la liste Create, sélectionnez Broker. Vous serez dirigé vers la page Create Broker.
- En option : Modifier la configuration YAML du courtier.
- Cliquez sur Create.
5.4.3.7. Prochaines étapes
- Configurez les paramètres de livraison d'événements qui sont appliqués dans les cas où un événement n'est pas livré à un récepteur d'événements. Voir Exemples de configuration des paramètres de livraison d'événements.
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
Modifier la ressource personnalisée (CR)
KnativeEventing
pour ajouter des détails de configuration pour la carte de configurationconfig-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.
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 configurationconfig-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ètresspec.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
estMTChannelBasedBroker
. 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.
ImportantLa 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
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.
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
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 ...
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é
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
etkafka-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.
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é
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
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 ...
Appliquer le fichier YAML du courtier basé sur Apache Kafka :
$ oc apply -f <filename>
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
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 à.
ImportantLa 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 valeurdefault.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"
Appliquer la carte de configuration :
oc apply -f <config_map_filename> $ oc apply -f <config_map_filename>
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.
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.
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
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
ImportantUtilisez les noms de clés
ca.crt
,user.crt
, etuser.key
. Ne les modifiez pas.Modifiez le CR
KnativeKafka
et ajoutez une référence à votre secret dans la spécificationbroker
: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
, ouSCRAM-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
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
, etsasl.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'argumentca.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"
-
Utilisez les noms de clés
Modifiez le CR
KnativeKafka
et ajoutez une référence à votre secret dans la spécificationbroker
: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ètrebackoffDelay
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 eitherlinear
orexponential
. When using thelinear
back off policy, the back off delay is equal tobackoffDelay * <numberOfRetries>
. When using theexponential
backoff policy, the back off delay is equal tobackoffDelay*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
Créer ou modifier un objet
Trigger
et définir l'annotationkafka.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
.
Appliquer l'objet
Trigger
:$ oc apply -f <filename>