5.3. Les puits d'événements
5.3.1. Les puits d'événements Copier lienLien copié sur presse-papiers!
Lorsque vous créez une source d'événements, vous pouvez spécifier un puits d'événements vers lequel les événements sont envoyés à partir de la source. Un puits d'événements est une ressource adressable ou appelable qui peut recevoir des événements d'autres ressources. Les services Knative, les canaux et les courtiers sont des exemples de puits d'événements. Il existe également un type de puits Apache Kafka spécifique.
Les objets adressables reçoivent et accusent réception d'un événement transmis par HTTP à une adresse définie dans leur champ status.address.url
. Dans un cas particulier, l'objet principal Kubernetes Service
remplit également l'interface adressable.
Les objets appelables sont capables de recevoir un événement transmis par HTTP et de le transformer, en renvoyant 0
ou 1
nouveaux événements dans la réponse HTTP. Ces événements renvoyés peuvent être traités de la même manière que les événements provenant d'une source externe.
5.3.1.1. Drapeau d'évitement de l'CLI Knative Copier lienLien copié sur presse-papiers!
Lorsque vous créez une source d'événements à l'aide de l'interface de programmation Knative (kn
), vous pouvez spécifier un puits vers lequel les événements sont envoyés à partir de cette ressource à l'aide de l'indicateur --sink
. Le récepteur peut être n'importe quelle ressource adressable ou appelable qui peut recevoir des événements entrants d'autres ressources.
L'exemple suivant crée une liaison de puits qui utilise un service, http://event-display.svc.cluster.local
, comme puits :
Exemple de commande utilisant l'indicateur d'évitement
kn source binding create bind-heartbeat \ --namespace sinkbinding-example \ --subject "Job:batch/v1:app=heartbeat-cron" \ --sink http://event-display.svc.cluster.local \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
svc
danshttp://event-display.svc.cluster.local
détermine que le puits est un service Knative. D'autres préfixes de puits par défaut incluentchannel
, etbroker
.
Vous pouvez configurer les CR qui peuvent être utilisés avec l'indicateur --sink
pour les commandes CLI Knative (kn
) en personnalisant kn
.
5.3.2. Création de puits d'événements Copier lienLien copié sur presse-papiers!
Lorsque vous créez une source d'événements, vous pouvez spécifier un puits d'événements vers lequel les événements sont envoyés à partir de la source. Un puits d'événements est une ressource adressable ou appelable qui peut recevoir des événements d'autres ressources. Les services Knative, les canaux et les courtiers sont des exemples de puits d'événements. Il existe également un type de puits Apache Kafka spécifique.
Pour plus d'informations sur la création de ressources pouvant être utilisées comme puits d'événements, voir la documentation suivante :
5.3.3. Sink pour Apache Kafka Copier lienLien copié sur presse-papiers!
Les puits Apache Kafka sont un type de puits d'événements disponibles si un administrateur de cluster a activé Apache Kafka sur votre cluster. Vous pouvez envoyer des événements directement d'une source d'événements à un sujet Kafka en utilisant un puits Kafka.
5.3.3.1. Créer un puits Apache Kafka en utilisant YAML Copier lienLien copié sur presse-papiers!
Vous pouvez créer un puits Kafka qui envoie des événements à un sujet Kafka. Par défaut, un sink Kafka utilise le mode de contenu binaire, qui est plus efficace que le mode structuré. Pour créer un puits Kafka à l'aide de YAML, vous devez créer un fichier YAML qui définit un objet KafkaSink
, puis l'appliquer à l'aide de la commande oc apply
.
Conditions préalables
-
L'opérateur OpenShift Serverless, Knative Eventing et la ressource personnalisée (CR)
KnativeKafka
sont installés sur votre 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.
- Vous avez accès à un cluster Red Hat AMQ Streams (Kafka) qui produit les messages Kafka que vous souhaitez importer.
-
Installez le CLI OpenShift (
oc
).
Procédure
Créer une définition d'objet
KafkaSink
sous forme de fichier YAML :Evier Kafka YAML
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour créer le puits Kafka, appliquez le fichier YAML
KafkaSink
:oc apply -f <filename>
$ oc apply -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configurer une source d'événements de manière à ce que le puits soit spécifié dans sa spécification :
Exemple d'un puits Kafka connecté à une source de serveur API
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3.2. Créer un puits d'événements pour Apache Kafka en utilisant la console web d'OpenShift Container Platform Copier lienLien copié sur presse-papiers!
Vous pouvez créer un puits Kafka qui envoie des événements à un sujet Kafka en utilisant la perspective Developer dans la console web d'OpenShift Container Platform. Par défaut, un sink Kafka utilise le mode de contenu binaire, qui est plus efficace que le mode structuré.
En tant que développeur, vous pouvez créer un puits d'événements pour recevoir des événements d'une source particulière et les envoyer à un sujet Kafka.
Conditions préalables
- Vous avez installé l'OpenShift Serverless Operator, avec Knative Serving, Knative Eventing, et Knative broker for Apache Kafka APIs, depuis l'OperatorHub.
- Vous avez créé un sujet Kafka dans votre environnement Kafka.
Procédure
- Dans la perspective Developer, accédez à la vue Add.
- Cliquez sur Event Sink dans la page Eventing catalog.
-
Recherchez
KafkaSink
dans les éléments du catalogue et cliquez dessus. - Cliquez sur Create Event Sink.
Dans la vue du formulaire, saisissez l'URL du serveur d'amorçage, qui est une combinaison du nom d'hôte et du port.
- Saisissez le nom de la rubrique à laquelle envoyer les données d'événement.
- Saisissez le nom du puits d'événement.
- Cliquez sur Create.
Vérification
- Dans la perspective Developer, accédez à la vue Topology.
- Cliquez sur le puits d'événement créé pour afficher ses détails dans le panneau de droite.
5.3.3.3. Configuration de la sécurité pour les puits Apache Kafka Copier lienLien copié sur presse-papiers!
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.
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
-
OpenShift Serverless Operator, Knative Eventing et les ressources personnalisées (CR)
KnativeKafka
sont installés sur votre cluster OpenShift Container Platform. -
Le puits Kafka est activé dans le CR
KnativeKafka
. - 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
. -
Vous avez installé le CLI OpenShift (
oc
). -
Vous avez choisi le mécanisme SASL à utiliser, par exemple
PLAIN
,SCRAM-SHA-256
, ouSCRAM-SHA-512
.
Procédure
Créez les fichiers de certificat en tant que secret dans le même espace de noms que votre objet
KafkaSink
:ImportantLes certificats et les clés doivent être au format PEM.
Pour l'authentification par SASL sans cryptage :
oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SASL_PLAINTEXT \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-literal=user=<username> \ --from-literal=password=<password>
$ oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SASL_PLAINTEXT \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-literal=user=<username> \ --from-literal=password=<password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pour l'authentification à l'aide de SASL et le cryptage à l'aide de TLS :
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L'adresse
ca.crt
peut être omise pour utiliser le jeu de CA racine du système si vous utilisez un service Kafka géré dans un nuage public, tel que Red Hat OpenShift Streams pour Apache Kafka.
Pour l'authentification et le cryptage à l'aide de TLS :
oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \ --from-file=user.crt=<my_cert.pem_file_path> \ --from-file=user.key=<my_key.pem_file_path>
$ oc create secret -n <namespace> generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \
1 --from-file=user.crt=<my_cert.pem_file_path> \ --from-file=user.key=<my_key.pem_file_path>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L'adresse
ca.crt
peut être omise pour utiliser le jeu de CA racine du système si vous utilisez un service Kafka géré dans un nuage public, tel que Red Hat OpenShift Streams pour Apache Kafka.
Créez ou modifiez un objet
KafkaSink
et ajoutez une référence à votre secret dans la spécificationauth
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquer l'objet
KafkaSink
:oc apply -f <filename>
$ oc apply -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow