4.4. Fractionnement du trafic

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.