Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

7.4. Commandes CLI de Knative Eventing

7.4.1. commandes kn source
Copier lien

Vous pouvez utiliser les commandes suivantes pour répertorier, créer et gérer les sources d'événements Knative.

Vous pouvez répertorier les types de sources d'événements qui peuvent être créés et utilisés sur votre cluster à l'aide de la commande CLI kn source list-types.

Conditions préalables

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

Procédure

  1. Liste les types de sources d'événements disponibles dans le terminal : 

    $ kn source list-types

    Exemple de sortie

    TYPE              NAME                                            DESCRIPTION
ApiServerSource   apiserversources.sources.knative.dev            Watch and send Kubernetes API events to a sink
PingSource        pingsources.sources.knative.dev                 Periodically send ping events to a sink
SinkBinding       sinkbindings.sources.knative.dev                Binding for connecting a PodSpecable to a sink

  2. Facultatif : vous pouvez également dresser la liste des types de sources d'événements disponibles au format YAML : 

    $ kn source list-types -o yaml

7.4.1.2. Drapeau d'évitement de l'CLI Knative
Copier lien

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 \
1 

  --ce-override "sink=bound"

1
svc dans http://event-display.svc.cluster.local détermine que le puits est un service Knative. D'autres préfixes de puits par défaut incluent channel, et broker.

Vous pouvez utiliser les commandes kn source container pour créer et gérer des sources de conteneurs en utilisant le CLI Knative (kn). L'utilisation de l'interface de programmation Knative pour créer des sources d'événements offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML.

Créer un conteneur source

$ kn source container create <container_source_name> --image <image_uri> --sink <sink>

Supprimer un conteneur source

kn source container delete <container_source_name>

Décrire la source d'un conteneur

kn source container describe <container_source_name>

Liste des sources de conteneurs existantes

$ kn source container list

Liste des sources de conteneurs existantes au format YAML

$ kn source container list -o yaml

Mise à jour d'un conteneur source

Cette commande met à jour l'URI de l'image d'un conteneur existant : 

$ kn source container update <container_source_name> --image <image_uri>

Vous pouvez utiliser la commande kn source apiserver create pour créer une source de serveur API à l'aide de l'interface de programmation kn. L'utilisation du CLI kn pour créer une source de serveur API offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML.

Conditions préalables

  • OpenShift Serverless Operator 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.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez installé le CLI Knative (kn).
Procédure

Si vous souhaitez réutiliser un compte de service existant, vous pouvez modifier votre ressource ServiceAccount existante pour y inclure les autorisations requises au lieu de créer une nouvelle ressource.

  1. Créez un compte de service, un rôle et une liaison de rôle pour la source d'événement sous la forme d'un fichier YAML : 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: events-sa
  namespace: default
    1 
    

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: event-watcher
  namespace: default
    2 
    
rules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - get
      - list
      - watch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k8s-ra-event-watcher
  namespace: default
    3 
    
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: event-watcher
subjects:
  - kind: ServiceAccount
    name: events-sa
    namespace: default
    4
    1 2 3 4
    Remplacez cet espace de noms par l'espace de noms que vous avez sélectionné pour l'installation de la source d'événements.

  2. Appliquer le fichier YAML : 

    $ oc apply -f <filename>

  3. Créez une source de serveur API dotée d'un puits d'événements. Dans l'exemple suivant, le puits est un courtier : 

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

  4. Pour vérifier que la source du serveur API est correctement configurée, créez un service Knative qui déverse les messages entrants dans son journal : 

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

  5. Si vous avez utilisé un courtier comme puits d'événements, créez un déclencheur pour filtrer les événements du courtier default vers le service : 

    kn trigger create <trigger_name> --sink ksvc:<service_name> $ kn trigger create <trigger_name>

  6. Créer des événements en lançant un pod dans l'espace de noms par défaut : 

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

  7. Vérifiez que le contrôleur est correctement mappé en inspectant la sortie générée par la commande suivante : 

    $ kn source apiserver describe <nom_de_la_source>

    Exemple de sortie

    Name:                mysource
Namespace:           default
Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
Age:                 3m
ServiceAccountName:  events-sa
Mode:                Resource
Sink:
  Name:       default
  Namespace:  default
  Kind:       Broker (eventing.knative.dev/v1)
Resources:
  Kind:        event (v1)
  Controller:  false
Conditions:
  OK TYPE                     AGE REASON
  ++ Ready                     3m
  ++ Deployed                  3m
  ++ SinkProvided              3m
  ++ SufficientPermissions     3m
  ++ EventTypesProvided        3m

Vérification

Vous pouvez vérifier que les événements Kubernetes ont été envoyés à Knative en consultant les journaux de la fonction dumper de messages.

  1. Obtenez les cosses : 

    $ oc get pods

  2. Affichez les journaux des fonctions de l'expéditeur de messages pour les modules : 

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    Exemple de sortie

    ☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.apiserver.resource.update
  datacontenttype: application/json
  ...
Data,
  {
    "apiVersion": "v1",
    "involvedObject": {
      "apiVersion": "v1",
      "fieldPath": "spec.containers{hello-node}",
      "kind": "Pod",
      "name": "hello-node",
      "namespace": "default",
       .....
    },
    "kind": "Event",
    "message": "Started container",
    "metadata": {
      "name": "hello-node.159d7608e3a3572c",
      "namespace": "default",
      ....
    },
    "reason": "Started",
    ...
  }

Suppression de la source du serveur API

  1. Supprimer le déclencheur : 

    kn trigger delete <trigger_name>

  2. Supprimer la source de l'événement : 

    $ kn source apiserver delete <nom_de_la_source>

  3. Supprimez le compte de service, le rôle de cluster et le lien de cluster : 

    $ oc delete -f authentication.yaml

Vous pouvez utiliser la commande kn source ping create pour créer une source de ping en utilisant le CLI Knative (kn). L'utilisation de l'interface de programmation Knative pour créer des sources d'événements offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML.

Conditions préalables

  • L'opérateur OpenShift Serverless, Knative Serving et Knative Eventing sont installés sur le cluster.
  • 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.
  • Facultatif : Si vous souhaitez utiliser les étapes de vérification pour cette procédure, installez l'OpenShift CLI (oc).

Procédure

  1. Pour vérifier que la source de ping fonctionne, créez un service Knative simple qui déverse les messages entrants dans les journaux du service : 

    $ kn service create event-display \
    --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

  2. Pour chaque ensemble d'événements ping que vous souhaitez demander, créez une source ping dans le même espace de noms que le consommateur d'événements : 

    $ kn source ping create test-ping-source \
    --schedule "*/2 * * * *" \
    --data '{"message": "Hello world!"}' \
    --sink ksvc:event-display

  3. Vérifiez que le contrôleur est correctement mappé en entrant la commande suivante et en inspectant la sortie : 

    $ kn source ping describe test-ping-source

    Exemple de sortie

    Name:         test-ping-source
Namespace:    default
Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
Age:          15s
Schedule:     */2 * * * *
Data:         {"message": "Hello world!"}

Sink:
  Name:       event-display
  Namespace:  default
  Resource:   Service (serving.knative.dev/v1)

Conditions:
  OK TYPE                 AGE REASON
  ++ Ready                 8s
  ++ Deployed              8s
  ++ SinkProvided         15s
  ++ ValidSchedule        15s
  ++ EventTypeProvided    15s
  ++ ResourcesCorrect     15s

Vérification

Vous pouvez vérifier que les événements Kubernetes ont été envoyés au puits d'événements Knative en examinant les journaux du pod de puits.

Par défaut, les services Knative terminent leurs pods si aucun trafic n'est reçu pendant une période de 60 secondes. L'exemple présenté dans ce guide crée une source ping qui envoie un message toutes les 2 minutes, chaque message doit donc être observé dans un pod nouvellement créé.

  1. Surveillez la création de nouvelles gousses : 

    $ watch oc get pods

  2. Annulez l'observation des pods en utilisant Ctrl C, puis regardez les journaux du pod créé : 

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    Exemple de sortie

    ☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.sources.ping
  source: /apis/v1/namespaces/default/pingsources/test-ping-source
  id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
  time: 2020-04-07T16:16:00.000601161Z
  datacontenttype: application/json
Data,
  {
    "message": "Hello world!"
  }

Suppression de la source de ping

  • Supprimer la source de ping : 

    $ kn delete pingsources.sources.knative.dev <nom_de_la_source_de_ping>

Vous pouvez utiliser la commande kn source kafka create pour créer une source Kafka en utilisant le CLI Knative (kn). L'utilisation du CLI Knative pour créer des sources d'événements offre une interface utilisateur plus rationnelle et intuitive que la modification directe des fichiers YAML.

Conditions préalables

  • OpenShift Serverless Operator, Knative Eventing, Knative Serving 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.
  • Vous avez installé le CLI Knative (kn).
  • Facultatif : Vous avez installé l'OpenShift CLI (oc) si vous voulez utiliser les étapes de vérification dans cette procédure.

Procédure

  1. Pour vérifier que la source d'événements Kafka fonctionne, créez un service Knative qui déverse les événements entrants dans les journaux du service : 

    $ kn service create event-display \
    --image quay.io/openshift-knative/knative-eventing-sources-event-display

  2. Créer un CR KafkaSource: 

    $ kn source kafka create <kafka_source_name> \
    --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \
    --topics <topic_name> --consumergroup my-consumer-group \
    --sink event-display
    Note

    Remplacez les valeurs de cette commande par les valeurs de votre nom de source, de vos serveurs d'amorçage et de vos rubriques.

    Les options --servers, --topics, et --consumergroup spécifient les paramètres de connexion au cluster Kafka. L'option --consumergroup est facultative.

  3. Facultatif : Affichez les détails de la CR KafkaSource que vous avez créée : 

    $ kn source kafka describe <kafka_source_name>

    Exemple de sortie

    Name:              example-kafka-source
Namespace:         kafka
Age:               1h
BootstrapServers:  example-cluster-kafka-bootstrap.kafka.svc:9092
Topics:            example-topic
ConsumerGroup:     example-consumer-group

Sink:
  Name:       event-display
  Namespace:  default
  Resource:   Service (serving.knative.dev/v1)

Conditions:
  OK TYPE            AGE REASON
  ++ Ready            1h
  ++ Deployed         1h
  ++ SinkProvided     1h

Verification steps

  1. Déclencher l'envoi par l'instance Kafka d'un message au sujet : 

    $ oc -n kafka run kafka-producer \
    -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \
    --restart=Never -- bin/kafka-console-producer.sh \
    --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic

    Saisissez le message dans l'invite. Cette commande suppose que :

    • Le cluster Kafka est installé dans l'espace de noms kafka.
    • L'objet KafkaSource a été configuré pour utiliser le sujet my-topic.

  2. Vérifiez que le message est arrivé en consultant les journaux : 

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    Exemple de sortie

    ☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.kafka.event
  source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic
  subject: partition:46#0
  id: partition:46/offset:0
  time: 2021-03-10T11:21:49.4Z
Extensions,
  traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00
Data,
  Hello!

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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2026 Red HatRetour au début