Procédure

1. Créez un fichier YAML contenant l'exemple de code suivant :

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-delivery
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. Naviguez jusqu'au répertoire où se trouve le fichier YAML et déployez l'application en appliquant le fichier YAML :

   $ oc apply -f <filename>

Procédure

1. Naviguez jusqu'à la page Serverless → Serving.
2. Dans la liste Create, sélectionnez Service.
3. Saisir manuellement des définitions YAML ou JSON, ou glisser-déposer un fichier dans l'éditeur.
4. Cliquez sur Create.

Procédure

1. En mode déconnecté, créez un fichier de descripteurs de service Knative local :

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

   Exemple de sortie

   Service 'event-display' created in namespace 'test'.

   • L'option --target ./ active le mode hors ligne et spécifie ./ comme répertoire de stockage de la nouvelle arborescence.

     Si vous n'indiquez pas de répertoire existant, mais que vous utilisez un nom de fichier, tel que --target my-service.yaml, aucune arborescence n'est créée. Seul le fichier de descripteurs de service my-service.yaml est créé dans le répertoire actuel.

     Le nom de fichier peut avoir l'extension .yaml, .yml, ou .json. Le choix de .json crée le fichier du descripteur de service au format JSON.

   • L'option --namespace test place le nouveau service dans l'espace de noms test.

     Si vous n'utilisez pas --namespace, et que vous êtes connecté à un cluster OpenShift Container Platform, le fichier de descripteurs est créé dans l'espace de noms actuel. Sinon, le fichier de descripteurs est créé dans l'espace de noms default.

2. Examinez la structure de répertoire créée :

   $ tree ./

   Exemple de sortie

   ./
   └── test
       └── ksvc
           └── event-display.yaml
   
   2 directories, 1 file

   • Le répertoire actuel ./ spécifié avec --target contient le nouveau répertoire test/ qui porte le nom de l'espace de noms spécifié.
   • Le répertoire test/ contient le répertoire ksvc, nommé d'après le type de ressource.
   • Le répertoire ksvc contient le fichier descripteur event-display.yaml, nommé d'après le nom du service spécifié.

3. Examinez le fichier de descripteurs de service généré :

   $ cat test/ksvc/event-display.yaml

   Exemple de sortie

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     creationTimestamp: null
     name: event-display
     namespace: test
   spec:
     template:
       metadata:
         annotations:
           client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
         creationTimestamp: null
       spec:
         containers:
         - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
           name: ""
           resources: {}
   status: {}

4. Liste des informations sur le nouveau service :

   $ kn service describe event-display --target ./ --namespace test

   Exemple de sortie

   Name:       event-display
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   • L'option --target ./ spécifie le répertoire racine de la structure de répertoires contenant les sous-répertoires de l'espace de noms.

     Vous pouvez également spécifier directement un nom de fichier YAML ou JSON à l'aide de l'option --target. Les extensions de fichier acceptées sont .yaml, .yml, et .json.

   • L'option --namespace spécifie l'espace de noms, qui communique à kn le sous-répertoire contenant le fichier de descripteur de service nécessaire.

     Si vous n'utilisez pas --namespace et que vous êtes connecté à un cluster OpenShift Container Platform, kn recherche le service dans le sous-répertoire portant le nom de l'espace de noms actuel. Sinon, kn effectue la recherche dans le sous-répertoire default/.

5. Utilisez le fichier descripteur de service pour créer le service sur le cluster :

   $ kn service create -f test/ksvc/event-display.yaml

   Exemple de sortie

   Creating service 'event-display' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "event-display" is waiting for a Revision to become ready.
    23.377s ...
    23.419s Ingress has not yet been reconciled.
    23.534s Waiting for load balancer to be ready
    23.723s Ready to serve.
   
   Service 'event-display' created to latest revision 'event-display-00001' is available at URL:
   http://event-display-test.apps.example.com

Procédure

1. Recherchez l'URL de l'application :

   oc get ksvc -YRFFGUNA nom_du_service>

   Exemple de sortie

   NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

2. Envoyez une requête à votre cluster et observez le résultat.

   Exemple de demande HTTP

   $ curl http://event-delivery-default.example.com

   Exemple de demande HTTPS

   $ curl https://event-delivery-default.example.com

   Exemple de sortie

   Hello Serverless!

3. Facultatif. Si vous recevez une erreur concernant un certificat auto-signé dans la chaîne de certificats, vous pouvez ajouter le drapeau --insecure à la commande curl pour ignorer l'erreur :

   $ curl https://event-delivery-default.example.com --insecure

   Exemple de sortie

   Hello Serverless!

   Important

   Les certificats auto-signés ne doivent pas être utilisés dans un déploiement de production. Cette méthode ne doit être utilisée qu'à des fins de test.

4. Facultatif. Si votre cluster OpenShift Container Platform est configuré avec un certificat signé par une autorité de certification (CA) mais pas encore configuré globalement pour votre système, vous pouvez le spécifier avec la commande curl. Le chemin d'accès au certificat peut être transmis à la commande curl à l'aide de l'indicateur --cacert:

   $ curl https://event-delivery-default.example.com --cacert <file>

   Exemple de sortie

   Hello Serverless!

Procédure

1. Modifiez votre service pour inclure des conteneurs supplémentaires. Un seul conteneur peut traiter les requêtes, il faut donc spécifier ports pour un seul conteneur. Voici un exemple de configuration avec deux conteneurs :

   Configuration de plusieurs conteneurs

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
     template:
       spec:
         containers:
           - name: first-container 1
             image: gcr.io/knative-samples/helloworld-go
             ports:
               - containerPort: 8080 2
           - name: second-container 3
             image: gcr.io/knative-samples/helloworld-java

   1

   Première configuration du conteneur.

   2

   Spécification du port pour le premier conteneur.

   3

   Deuxième configuration du conteneur.

Procédure

1. Pour permettre à Knative Serving d'utiliser les PVC et d'y écrire, modifiez la ressource personnalisée (CR) KnativeServing pour inclure le YAML suivant :

   Activation des PVC avec accès en écriture

   ...
   spec:
     config:
       features:
         "kubernetes.podspec-persistent-volume-claim": enabled
         "kubernetes.podspec-persistent-volume-write": enabled
   ...

   • L'extension kubernetes.podspec-persistent-volume-claim détermine si les volumes persistants (PV) peuvent être utilisés avec Knative Serving.
   • L'extension kubernetes.podspec-persistent-volume-write détermine si les PV sont disponibles pour Knative Serving avec l'accès en écriture.

2. Pour réclamer un PV, modifiez votre service pour inclure la configuration du PV. Par exemple, vous pouvez avoir une demande de volume persistant avec la configuration suivante :

   Note

   Utilisez la classe de stockage qui prend en charge le mode d'accès que vous demandez. Par exemple, vous pouvez utiliser la classe ocs-storagecluster-cephfs pour le mode d'accès ReadWriteMany.

   Configuration de PersistentVolumeClaim

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: example-pv-claim
     namespace: my-ns
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ocs-storagecluster-cephfs
     resources:
       requests:
         storage: 1Gi

   Dans ce cas, pour réclamer un PV avec accès en écriture, modifiez votre service comme suit :

   Configuration du service Knative PVC

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     namespace: my-ns
   ...
   spec:
    template:
      spec:
        containers:
            ...
            volumeMounts: 1
              - mountPath: /data
                name: mydata
                readOnly: false
        volumes:
          - name: mydata
            persistentVolumeClaim: 2
              claimName: example-pv-claim
              readOnly: false 3

   1

   Spécification de montage de volume.

   2

   Spécification de la demande de volume persistant.

   3

   Indicateur permettant l'accès en lecture seule.

   Note

   Pour utiliser avec succès le stockage persistant dans les services Knative, vous avez besoin d'une configuration supplémentaire, telle que les autorisations de l'utilisateur du conteneur Knative.

Procédure

1. Créer un service Knative qui inclut le champ internal-encryption: "true" dans la spécification :

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. Redémarrez les pods activateurs dans l'espace de noms knative-serving pour charger les certificats :

   $ oc delete pod -n knative-serving --selector app=activator

Procédure

1. Ajoutez l'étiquette knative.openshift.io/system-namespace=true à chaque espace de noms du système Knative qui nécessite un accès à votre application :

   1. Étiqueter l'espace de noms knative-serving:

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. Étiqueter l'espace de noms knative-serving-ingress:

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. Étiqueter l'espace de noms knative-eventing:

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. Étiqueter l'espace de noms knative-kafka:

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. Créez un objet NetworkPolicy dans l'espace de noms de votre application afin d'autoriser l'accès à partir des espaces de noms portant l'étiquette knative.openshift.io/system-namespace:

   Exemple d'objet NetworkPolicy

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 1
     namespace: <namespace> 2
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   Donnez un nom à votre politique de réseau.

   2

   L'espace de noms dans lequel votre application existe.

1. Cliquez sur le service Knative pour voir son aperçu dans le panneau latéral.

2. Cliquez sur l'onglet Resources pour obtenir une liste de Revisions et Routes pour le service.

   Figure 4.1. Application sans serveur

   
3. Cliquez sur le service, indiqué par l'icône S en haut du panneau latéral, pour obtenir une vue d'ensemble des détails du service.
4. Cliquez sur l'onglet YAML et modifiez la configuration du service dans l'éditeur YAML, puis cliquez sur Save. Par exemple, changez le timeoutseconds de 300 à 301 . Cette modification de la configuration déclenche une nouvelle révision. Dans la vue Topology, la dernière révision est affichée et l'onglet Resources du service affiche maintenant les deux révisions.

5. Dans l'onglet Resources, cliquez sur Définir la distribution du trafic pour afficher la boîte de dialogue de distribution du trafic :

   1. Ajoutez le pourcentage de trafic divisé pour les deux révisions dans le champ Splits.
   2. Ajoutez des balises pour créer des URL personnalisées pour les deux révisions.

   3. Cliquez sur Save pour voir apparaître deux nœuds représentant les deux révisions dans la vue Topologie.

      Figure 4.2. Révisions d'applications sans serveur

      

Procédure

1. Créer et déployer une application en tant que service Knative.

2. Trouvez le nom de la première révision qui a été créée lorsque vous avez déployé le service, en consultant la sortie de la commande suivante :

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   Example command

   $ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

   Exemple de sortie

   $ example-service-00001

3. Ajoutez le fichier YAML suivant au service spec pour envoyer le trafic entrant à la révision :

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic goes to this revision
   ...

4. Vérifiez que vous pouvez voir votre application à l'URL que vous obtenez en exécutant la commande suivante :

   oc get ksvc -YRFFGUNA nom_du_service>

5. Déployez une deuxième révision de votre application en modifiant au moins un champ de la spécification template du service et en le redéployant. Par exemple, vous pouvez modifier l'adresse image du service, ou une variable d'environnement env. Vous pouvez redéployer le service en appliquant le fichier YAML du service, ou en utilisant la commande kn service update si vous avez installé le CLI Knative (kn).

6. Recherchez le nom de la deuxième révision, la plus récente, qui a été créée lorsque vous avez redéployé le service, en exécutant la commande :

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   À ce stade, les première et deuxième révisions du service sont déployées et fonctionnent.

7. Mettez à jour votre service existant pour créer un nouveau point d'arrivée test pour la deuxième révision, tout en continuant à envoyer tout le reste du trafic vers la première révision :

   Exemple de spécification de service mise à jour avec point final de test

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second_revision_name>
         percent: 0 # No traffic is routed to the second revision
         tag: v2 # A named route
   ...

   Après avoir redéployé ce service en réappliquant la ressource YAML, la deuxième révision de l'application est maintenant mise en scène. Aucun trafic n'est acheminé vers la deuxième révision à l'URL principale, et Knative crée un nouveau service nommé v2 pour tester la nouvelle révision déployée.

8. Obtenez l'URL du nouveau service pour la deuxième révision, en exécutant la commande suivante :

   $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

   Vous pouvez utiliser cette URL pour vérifier que la nouvelle version de l'application se comporte comme prévu avant d'y acheminer du trafic.

9. Mettez à nouveau à jour votre service existant, de sorte que 50 % du trafic soit envoyé à la première révision et 50 % à la seconde :

   Exemple de spécification de service actualisée divisant le trafic 50/50 entre les révisions

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 50
       - revisionName: <second_revision_name>
         percent: 50
         tag: v2
   ...

10. Lorsque vous êtes prêt à acheminer tout le trafic vers la nouvelle version de l'application, mettez à nouveau à jour le service pour envoyer 100 % du trafic vers la deuxième révision :

    Exemple de spécification de service mise à jour envoyant tout le trafic à la deuxième révision

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    Astuce

    Vous pouvez supprimer la première révision au lieu de la fixer à 0 % du trafic si vous ne prévoyez pas de revenir en arrière. Les objets de révision non acheminables sont alors mis au rebut.

11. Visitez l'URL de la première révision pour vérifier qu'aucun trafic n'est plus envoyé vers l'ancienne version de l'application.

Procédure

1. Créez un service Knative qui contient l'étiquette ou l'annotation que vous souhaitez propager à la route OpenShift Container Platform :

   • Pour créer un service en utilisant YAML :

     Exemple de service créé à l'aide de YAML

     apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: <service_name>
       labels:
         <label_name>: <label_value>
       annotations:
         <annotation_name>: <annotation_value>
     ...

   • Pour créer un service en utilisant le CLI Knative (kn), entrez :

     Exemple de service créé à l'aide d'une commande kn

     $ kn service create <service_name> \
       --image=<image> \
       --annotation <annotation_name>=<annotation_value> \
       --label <label_value>=<label_value>

2. Vérifiez que la route OpenShift Container Platform a été créée avec l'annotation ou l'étiquette que vous avez ajoutée en inspectant la sortie de la commande suivante :

   Exemple de commande de vérification

   $ oc get routes.route.openshift.io \
        -l serving.knative.openshift.io/ingressName=<service_name> \ 1
        -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2
        -n knative-serving-ingress -o yaml \
            | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" 3

   1

   Utilisez le nom de votre service.

   2

   Utilisez l'espace de noms dans lequel votre service a été créé.

   3

   Utilisez vos valeurs pour les noms et valeurs de l'étiquette et de l'annotation.

Procédure

1. Créer un service Knative qui inclut l'annotation serving.knative.openshift.io/disableRoute=true:

   Important

   L'annotation serving.knative.openshift.io/disableRoute=true indique à OpenShift Serverless de ne pas créer automatiquement une route pour vous. Cependant, le service affiche toujours une URL et atteint un statut de Ready. Cette URL ne fonctionne pas en externe jusqu'à ce que vous créiez votre propre route avec le même nom d'hôte que le nom d'hôte dans l'URL.

   1. Créer une ressource Knative Service:

      Exemple de ressource

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        annotations:
          serving.knative.openshift.io/disableRoute: "true"
      spec:
        template:
          spec:
            containers:
            - image: <image>
      ...

   2. Appliquer la ressource Service:

      $ oc apply -f <filename>

   3. Facultatif. Créez un service Knative à l'aide de la commande kn service create:

      Exemple de commande kn

      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true

2. Vérifiez qu'aucune route OpenShift Container Platform n'a été créée pour le service :

   Example command

   $ $ oc get routes.route.openshift.io \
     -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
     -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
     -n knative-serving-ingress

   Vous obtiendrez le résultat suivant :

   No resources found in knative-serving-ingress namespace.

3. Créer une ressource Route dans l'espace de noms knative-serving-ingress:

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     annotations:
       haproxy.router.openshift.io/timeout: 600s 1
     name: <route_name> 2
     namespace: knative-serving-ingress 3
   spec:
     host: <service_host> 4
     port:
       targetPort: http2
     to:
       kind: Service
       name: kourier
       weight: 100
     tls:
       insecureEdgeTerminationPolicy: Allow
       termination: edge 5
       key: |-
         -----BEGIN PRIVATE KEY-----
         [...]
         -----END PRIVATE KEY-----
       certificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
       caCertificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE----
     wildcardPolicy: None

   1

   La valeur du délai d'attente pour la route OpenShift Container Platform. Vous devez définir la même valeur que le paramètre max-revision-timeout-seconds (600s par défaut).

   2

   Le nom de la route OpenShift Container Platform.

   3

   L'espace de noms pour la route OpenShift Container Platform. Il doit s'agir de knative-serving-ingress.

   4

   Le nom d'hôte pour l'accès externe. Vous pouvez le définir sur <service_name>-<service_namespace>.<domain>.

   5

   Les certificats que vous souhaitez utiliser. Actuellement, seule la terminaison edge est prise en charge.

4. Appliquer la ressource Route:

   $ oc apply -f <filename>

Procédure

1. Déployer les certificats de serveur dans l'espace de noms knative-serving-ingress:

   $ export san="knative"

   Note

   La validation du nom alternatif du sujet (SAN) est nécessaire pour que ces certificats puissent transmettre la demande à <app_name>.<namespace>.svc.cluster.local.

2. Générer une clé racine et un certificat :

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example/CN=Example' \
       -keyout ca.key \
       -out ca.crt

3. Générer une clé de serveur qui utilise la validation SAN :

   $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
     -subj "/CN=Example/O=Example" \
     -addext "subjectAltName = DNS:$san"

4. Créer des certificats de serveur :

   $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
     -days 365 -in tls.csr \
     -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt

5. Configurez un secret pour la passerelle locale de Kourier :

   1. Déployer un secret dans l'espace de noms knative-serving-ingress à partir des certificats créés lors des étapes précédentes :

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -

   2. Mettre à jour la spécification de la ressource personnalisée (CR) KnativeServing pour utiliser le secret créé par la passerelle Kourier :

      Exemple KnativeServing CR

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

Procédure

1. Ajoutez l'annotation serverless.openshift.io/default-enable-http2=true à la ressource personnalisée KnativeServing:

   oc annotate knativeserving <your_knative_CR> -n knative-serving serverless.openshift.io/default-enable-http2=true

2. Après l'ajout de l'annotation, vous pouvez vérifier que la valeur appProtocol du service Kourier est h2c:

   $ oc get svc -n knative-serving-ingress kourier -o jsonpath="{.spec.ports[0].appProtocol}"

   Exemple de sortie

   h2c

3. Vous pouvez désormais utiliser le cadre gRPC sur le protocole HTTP/2 pour le trafic externe, par exemple :

   import "google.golang.org/grpc"
   
   grpc.Dial(
      YOUR_URL, 1
      grpc.WithTransportCredentials(insecure.NewCredentials())), 2
   )

   1

   Votre URL ksvc.

   2

   Votre certificat.

Procédure

1. Trouvez l'hôte de l'application. Voir les instructions dans Verifying your serverless application deployment.

2. Recherchez l'adresse publique de la passerelle d'entrée :

   $ oc -n knative-serving-ingress get svc kourier

   Exemple de sortie

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
   kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

   L'adresse publique apparaît dans le champ EXTERNAL-IP et, dans ce cas, il s'agit de a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com.

3. Définissez manuellement l'en-tête host de votre requête HTTP sur l'hôte de l'application, mais dirigez la requête elle-même vers l'adresse publique de la passerelle d'entrée.

   $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

   Exemple de sortie

   Hello Serverless!

   Vous pouvez également effectuer une requête gRPC directe auprès de la passerelle d'entrée :

   import "google.golang.org/grpc"
   
   grpc.Dial(
       "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
       grpc.WithAuthority("hello-default.example.com:80"),
       grpc.WithInsecure(),
   )

   Note

   Veillez à ajouter le port correspondant, 80 par défaut, aux deux hôtes, comme indiqué dans l'exemple précédent.

Procédure

1. Ajoutez l'annotation sidecar.istio.io/inject="true" à votre service :

   Exemple de service

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   Ajouter l'annotation sidecar.istio.io/inject="true".

   2

   Vous devez définir l'annotation sidecar.istio.io/rewriteAppHTTPProbers: "true" dans votre service Knative, car les versions 1.14.0 et supérieures d'OpenShift Serverless utilisent par défaut une sonde HTTP comme sonde de préparation pour les services Knative.

2. Appliquer la ressource Service:

   $ oc apply -f <filename>

3. Créer une ressource RequestAuthentication dans chaque espace de noms d'application sans serveur qui est un membre de l'objet ServiceMeshMemberRoll:

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: <namespace>
   spec:
     jwtRules:
     - issuer: testing@secure.istio.io
       jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json

4. Appliquer la ressource RequestAuthentication:

   $ oc apply -f <filename>

5. Autoriser l'accès à la ressource RequestAuthenticaton à partir des pods système pour chaque espace de noms d'application sans serveur qui est un membre de l'objet ServiceMeshMemberRoll, en créant la ressource AuthorizationPolicy suivante :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allowlist-by-paths
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - to:
       - operation:
           paths:
           - /metrics 1
           - /healthz 2

   1

   Le chemin d'accès à votre application pour collecter les métriques par pod système.

   2

   Le chemin d'accès à votre application pour sonder le pod du système.

6. Appliquer la ressource AuthorizationPolicy:

   $ oc apply -f <filename>

7. Pour chaque espace de noms d'application sans serveur qui est un membre de l'objet ServiceMeshMemberRoll, créez la ressource AuthorizationPolicy suivante :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - from:
       - source:
          requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]

8. Appliquer la ressource AuthorizationPolicy:

   $ oc apply -f <filename>

Vérification

1. Si vous essayez d'utiliser une requête curl pour obtenir l'URL du service Knative, elle est refusée :

   Example command

   $ curl http://hello-example-1-default.apps.mycluster.example.com/

   Exemple de sortie

   RBAC: access denied

2. Vérifier la demande avec un JWT valide.

   1. Obtenir le jeton JWT valide :

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. Accédez au service en utilisant le jeton valide dans l'en-tête de la requête curl:

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      La demande est désormais autorisée :

      Exemple de sortie

      Hello OpenShift!

Procédure

1. Ajoutez l'annotation sidecar.istio.io/inject="true" à votre service :

   Exemple de service

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   Ajouter l'annotation sidecar.istio.io/inject="true".

   2

   Vous devez définir l'annotation sidecar.istio.io/rewriteAppHTTPProbers: "true" dans votre service Knative, car les versions 1.14.0 et supérieures d'OpenShift Serverless utilisent par défaut une sonde HTTP comme sonde de préparation pour les services Knative.

2. Appliquer la ressource Service:

   $ oc apply -f <filename>

3. Créer une politique dans l'espace de noms d'une application sans serveur, qui est un membre de l'objet ServiceMeshMemberRoll, qui n'autorise que les demandes avec des jetons Web JSON valides (JWT) :

   Important

   Les chemins /metrics et /healthz doivent être inclus dans excludedPaths car ils sont accessibles à partir des pods du système dans l'espace de noms knative-serving.

   apiVersion: authentication.istio.io/v1alpha1
   kind: Policy
   metadata:
     name: default
     namespace: <namespace>
   spec:
     origins:
     - jwt:
         issuer: testing@secure.istio.io
         jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
         triggerRules:
         - excludedPaths:
           - prefix: /metrics 1
           - prefix: /healthz 2
     principalBinding: USE_ORIGIN

   1

   Le chemin d'accès à votre application pour collecter les métriques par pod système.

   2

   Le chemin d'accès à votre application pour sonder le pod du système.

4. Appliquer la ressource Policy:

   $ oc apply -f <filename>

Vérification

1. Si vous essayez d'utiliser une requête curl pour obtenir l'URL du service Knative, elle est refusée :

   $ curl http://hello-example-default.apps.mycluster.example.com/

   Exemple de sortie

   Origin authentication failed.

2. Vérifier la demande avec un JWT valide.

   1. Obtenir le jeton JWT valide :

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. Accédez au service en utilisant le jeton valide dans l'en-tête de la requête curl:

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      La demande est désormais autorisée :

      Exemple de sortie

      Hello OpenShift!

Procédure

1. Créez un fichier YAML contenant le CR DomainMapping dans le même espace de noms que le CR cible que vous souhaitez mapper :

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   Le nom de domaine personnalisé que vous souhaitez associer au CR cible.

   2

   L'espace de noms du CR DomainMapping et du CR cible.

   3

   Le nom du CR cible à mettre en correspondance avec le domaine personnalisé.

   4

   Le type de CR mappé au domaine personnalisé.

   Exemple de mappage de domaine de service

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   Exemple de mappage de domaines de routes

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-route
      kind: Route
      apiVersion: serving.knative.dev/v1

2. Appliquer le CR DomainMapping sous la forme d'un fichier YAML :

   $ oc apply -f <filename>

Procédure

1. Naviguez jusqu'à la page Topology.
2. Cliquez avec le bouton droit de la souris sur le service que vous voulez mapper à un domaine, et sélectionnez l'option Edit qui contient le nom du service. Par exemple, si le service s'appelle example-service, sélectionnez l'option Edit example-service.

3. Dans la section Advanced options, cliquez sur Show advanced Routing options.

   1. Si le CR de mappage de domaine que vous souhaitez mapper au service existe déjà, vous pouvez le sélectionner dans la liste Domain mapping.
   2. Si vous voulez créer un nouveau CR de mappage de domaine, tapez le nom de domaine dans la case et sélectionnez l'option Create. Par exemple, si vous tapez example.com, l'option Create est Create "example.com".
4. Cliquez sur Save pour enregistrer les modifications apportées à votre service.

Vérification

1. Naviguez jusqu'à la page Topology.
2. Cliquez sur le service que vous avez créé.
3. Dans l'onglet Resources de la fenêtre d'information sur le service, vous pouvez voir le domaine que vous avez mappé au service listé sous Domain mappings.

Procédure

1. Naviguez jusqu'à CustomResourceDefinitions et utilisez la boîte de recherche pour trouver la définition de ressource personnalisée (CRD) DomainMapping.
2. Cliquez sur le CRD DomainMapping, puis naviguez jusqu'à l'onglet Instances.
3. Cliquez sur Create DomainMapping.

4. Modifiez le YAML pour le CR DomainMapping afin qu'il inclue les informations suivantes pour votre instance :

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   Le nom de domaine personnalisé que vous souhaitez associer au CR cible.

   2

   L'espace de noms du CR DomainMapping et du CR cible.

   3

   Le nom du CR cible à mettre en correspondance avec le domaine personnalisé.

   4

   Le type de CR mappé au domaine personnalisé.

   Exemple de mappage d'un domaine vers un service Knative

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: custom-ksvc-domain.example.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

Procédure

1. Créez un secret TLS Kubernetes :

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

2. Ajoutez le label networking.internal.knative.dev/certificate-uid: <id>` au secret TLS de Kubernetes :

   $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

   Si vous utilisez un fournisseur de secret tiers tel que cert-manager, vous pouvez configurer votre gestionnaire de secret pour étiqueter automatiquement le secret TLS de Kubernetes. Les utilisateurs de Cert-manager peuvent utiliser le modèle de secret proposé pour générer automatiquement des secrets avec l'étiquette correcte. Dans ce cas, le filtrage des secrets est effectué sur la base de la clé uniquement, mais cette valeur peut contenir des informations utiles telles que l'ID du certificat que le secret contient.

   Note

   L'opérateur cert-manager pour Red Hat OpenShift est une fonctionnalité de l'aperçu technologique. Pour plus d'informations, consultez la documentation Installing the cert-manager Operator for Red Hat OpenShift.

3. Mettez à jour le CR DomainMapping pour utiliser le secret TLS que vous avez créé :

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

Vérification

1. Vérifiez que l'état de la CR DomainMapping est True et que la colonne URL de la sortie indique le domaine mappé avec le schéma https:

   oc get domainmapping <domain_name>

   Exemple de sortie

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

2. Facultatif : si le service est exposé publiquement, vérifiez qu'il est disponible en exécutant la commande suivante :

   $ curl https://<domain_name>

   Si le certificat est auto-signé, passez la vérification en ajoutant le drapeau -k à la commande curl.

Procédure

1. Dans la perspective de la console web de OpenShift Container Platform Administrator, naviguez vers OperatorHub → Installed Operators.
2. Sélectionnez l'espace de noms knative-serving.
3. Cliquez sur Knative Serving dans la liste de Provided APIs pour l'OpenShift Serverless Operator afin d'accéder à l'onglet Knative Serving.

4. Cliquez sur knative-serving, puis sur l'onglet YAML dans la page knative-serving.

   

5. Modifier le nombre de répliques dans le CR KnativeServing:

   Exemple YAML

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     high-availability:
       replicas: 3

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 Event Source. Vous serez dirigé vers la page Event Sources.
3. Sélectionnez le type de source d'événement que vous souhaitez créer.

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. Dans la perspective Developer, naviguez vers Add → Event Source. La page Event Sources s'affiche.
4. Facultatif : si vous avez plusieurs fournisseurs pour vos sources d'événements, sélectionnez le fournisseur requis dans la liste Providers pour filtrer les sources d'événements disponibles du fournisseur.
5. Sélectionnez ApiServerSource puis cliquez sur Create Event Source. La page Create Event Source s'affiche.

6. Configurez les paramètres de ApiServerSource en utilisant les boutons Form view ou YAML view:

   Note

   Vous pouvez passer de la vue Form view à la vue YAML view. Les données sont conservées lors du passage d'une vue à l'autre.

   1. Saisissez v1 comme APIVERSION et Event comme KIND.
   2. Sélectionnez le site Service Account Name pour le compte de service que vous avez créé.
   3. Sélectionnez le site Sink pour la source de l'événement. Un Sink peut être soit un Resource, tel qu'un canal, un courtier ou un service, soit un URI.
7. Cliquez sur Create.

Suppression de la source du serveur API

1. Naviguez jusqu'à la vue Topology.

2. Cliquez avec le bouton droit de la souris sur la source du serveur API et sélectionnez Delete ApiServerSource.

   

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

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

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éer une source de serveur API sous la forme d'un fichier YAML :

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     name: testevents
   spec:
     serviceAccountName: events-sa
     mode: Resource
     resources:
       - apiVersion: v1
         kind: Event
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1
         kind: Broker
         name: default

4. Appliquer le fichier YAML ApiServerSource:

   $ oc apply -f <filename>

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

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-display
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

6. Appliquer le fichier YAML Service:

   $ oc apply -f <filename>

7. Créez un objet Trigger sous la forme d'un fichier YAML qui filtre les événements du courtier default vers le service créé à l'étape précédente :

   apiVersion: eventing.knative.dev/v1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     broker: default
     subscriber:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

8. Appliquer le fichier YAML Trigger:

   $ oc apply -f <filename>

9. 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

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

    $ oc get apiserversource.sources.knative.dev testevents -o yaml

    Exemple de sortie

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      annotations:
      creationTimestamp: "2020-04-07T17:24:54Z"
      generation: 1
      name: testevents
      namespace: default
      resourceVersion: "62868"
      selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
      uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
    spec:
      mode: Resource
      resources:
      - apiVersion: v1
        controller: false
        controllerSelector:
          apiVersion: ""
          kind: ""
          name: ""
          uid: ""
        kind: Event
        labelSelector: {}
      serviceAccountName: events-sa
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

1. Récupérez les pods en entrant la commande suivante :

   $ oc get pods

2. Affichez les journaux de la fonction d'expéditeur de messages pour les modules en entrant la commande suivante :

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

   $ oc delete -f trigger.yaml

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

   $ oc delete -f k8s-events.yaml

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

   $ oc delete -f authentication.yaml

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.

   1. Dans la perspective Developer, naviguez vers Add → YAML.

   2. Copiez l'exemple YAML :

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   3. Cliquez sur Create.

2. Créez une source ping dans le même espace de noms que le service créé à l'étape précédente, ou tout autre puits vers lequel vous souhaitez envoyer des événements.

   1. Dans la perspective Developer, naviguez vers Add → Event Source. La page Event Sources s'affiche.
   2. Facultatif : si vous avez plusieurs fournisseurs pour vos sources d'événements, sélectionnez le fournisseur requis dans la liste Providers pour filtrer les sources d'événements disponibles du fournisseur.

   3. Sélectionnez Ping Source puis cliquez sur Create Event Source. La page Create Event Source s'affiche.

      Note

      Vous pouvez configurer les paramètres de PingSource en utilisant Form view ou YAML view et passer d'une vue à l'autre. Les données sont conservées lors du passage d'une vue à l'autre.

   4. Enter a value for Schedule. In this example, the value is */2 * * * *, which creates a PingSource that sends a message every two minutes.
   5. Facultatif : vous pouvez saisir une valeur pour Data, qui est la charge utile du message.
   6. Sélectionnez un Sink. Il peut s'agir d'un Resource ou d'un URI. Dans cet exemple, le service event-display créé à l'étape précédente est utilisé comme puits Resource.
   7. Cliquez sur Create.

1. Dans la perspective Developer, naviguez jusqu'à Topology.

2. Affichez la source et la destination du ping.

   

Suppression de la source de ping

1. Naviguez jusqu'à la vue Topology.
2. Cliquez avec le bouton droit de la souris sur la source du serveur API et sélectionnez Delete Ping Source.

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

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!"
     }

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.

   1. Créer un fichier YAML de service :

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

   2. Créer le service :

      $ oc apply -f <filename>

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.

   1. Créer un fichier YAML pour la source ping :

      apiVersion: sources.knative.dev/v1
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        data: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. Créer la source de ping :

      $ oc apply -f <filename>

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

   $ oc get pingsource.sources.knative.dev <nom_de_la_source_de_ping> -oyaml

   Exemple de sortie

   apiVersion: sources.knative.dev/v1
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     data: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

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: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

Procédure

1. Dans la perspective Developer, naviguez jusqu'à la page Add et sélectionnez Event Source.
2. Dans la page Event Sources, sélectionnez Kafka Source dans la section Type.

3. Configurez les paramètres de Kafka Source:

   1. Ajouter une liste de Bootstrap Servers séparée par des virgules.
   2. Ajouter une liste de Topics séparée par des virgules.
   3. Ajouter un Consumer Group.
   4. Sélectionnez le site Service Account Name pour le compte de service que vous avez créé.
   5. Sélectionnez le site Sink pour la source de l'événement. Un Sink peut être soit un Resource, tel qu'un canal, un courtier ou un service, soit un URI.
   6. Saisissez une adresse Name pour la source d'événements Kafka.
4. Cliquez sur Create.

1. Dans la perspective Developer, naviguez jusqu'à Topology.

2. Afficher la source et le puits d'événements Kafka.

   

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!

Procédure

1. Créer un objet KafkaSource sous la forme d'un fichier YAML :

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: <source_name>
   spec:
     consumerGroup: <group_name> 1
     bootstrapServers:
     - <list_of_bootstrap_servers>
     topics:
     - <list_of_topics> 2
     sink:
     - <list_of_sinks> 3

   1

   Un groupe de consommateurs est un groupe de consommateurs qui utilisent le même identifiant de groupe et consomment des données d'un thème.

   2

   Un thème fournit une destination pour le stockage des données. Chaque thème est divisé en une ou plusieurs partitions.

   3

   Un puits indique où les événements sont envoyés à partir d'une source.

   Important

   Seule la version v1beta1 de l'API pour les objets KafkaSource sur OpenShift Serverless est prise en charge. N'utilisez pas la version v1alpha1 de cette API, car elle est désormais obsolète.

   Exemple d'objet KafkaSource

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: kafka-source
   spec:
     consumerGroup: knative-group
     bootstrapServers:
     - my-cluster-kafka-bootstrap.kafka:9092
     topics:
     - knative-demo-topic
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

2. Appliquer le fichier YAML KafkaSource:

   $ oc apply -f <filename>

Procédure

1. Créez les fichiers de certificats en tant que secrets dans l'espace de noms que vous avez choisi :

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-literal=password="SecretPassword" \
     --from-literal=saslType="SCRAM-SHA-512" \ 1
     --from-literal=user="my-sasl-user"

   1

   Le type SASL peut être PLAIN, SCRAM-SHA-256, ou SCRAM-SHA-512.

2. Créez ou modifiez votre source Kafka de manière à ce qu'elle contienne la configuration suivante : spec:

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: example-source
   spec:
   ...
     net:
       sasl:
         enable: true
         user:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: user
         password:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: password
         type:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: saslType
       tls:
         enable: true
         caCert: 1
           secretKeyRef:
             name: <kafka_auth_secret>
             key: ca.crt
   ...

   1

   La spécification caCert n'est pas nécessaire si vous utilisez un service Kafka en nuage public, tel que Red Hat OpenShift Streams for Apache Kafka.

Procédure

1. Créez une source d'événement de n'importe quel type, en naviguant vers Add → Event Source et en sélectionnant le type de source d'événement que vous souhaitez créer.
2. Dans la section Sink de la vue du formulaire Create Event Source, sélectionnez votre évier dans la liste Resource.
3. Cliquez sur Create.