Argo Rollouts Demo

00:09:06
https://www.youtube.com/watch?v=hIL0E2gLkf8

Ringkasan

TLDRArgo Rollouts est un outil puissant pour gérer les déploiements d'applications sur Kubernetes à l'aide de stratégies de mise à jour progressive comme blue-green et canary. En intégrant des maillages de services et des contrôleurs d'accès, il permet de diriger le trafic de manière sécurisée et d'effectuer des analyses de métriques pour garantir la stabilité des mises à jour. Si les métriques montrent des problèmes, Argo peut automatiquement revenir à la version stable précédente. Une démonstration explique comment argo utilise une stratégie canary avec Istio pour mesurer et ajuster le taux de succès des déploiements. Cet outil supporte également des métriques personnalisées et diverses intégrations avec d'autres solutions.

Takeaways

  • 🚀 Argo Rollouts permet des mises à jour progressives des applications Kubernetes.
  • 🛠️ Il supporte les stratégies blue-green et canary pour déployer des nouvelles versions.
  • 🔍 Le contrôle des métriques est essentiel pour promouvoir ou annuler une mise à jour.
  • 🔄 Argo peut automatiquement revenir à une version stable si des erreurs sont détectées.
  • 📊 L'utilisation de services de maillage ou de contrôleurs d'ingress est optionnelle mais bénéfique.
  • 🤖 Argo intègre des fournisseurs de métriques standards et personnalisés.
  • 🔗 Il s'intègre avec des solutions comme Istio pour la gestion du trafic.
  • 🎯 La stratégie canary teste un pourcentage limité de trafic avant déploiement complet.
  • 🛑 En cas de baisse de la performance, la mise à jour est arrêtée et annulée.
  • 👁️ Analyse continue des métriques avec des fournisseurs comme Prometheus.

Garis waktu

  • 00:00:00 - 00:09:06

    Dans cette vidéo, nous allons passer en revue et faire une démonstration rapide des déploiements Argo (Argo Rollouts). Argo Rollouts est un contrôleur de livraison progressive qui propose des stratégies de mise à jour supplémentaires telles que le blue-green et le canary pour Kubernetes. Il s'intègre avec divers maillages de services et contrôleurs d'entrée pour façonner et déplacer en toute sécurité le trafic vers différentes versions de l'application pendant une mise à jour. Argo Rollouts interroge les fournisseurs de métriques et effectue une analyse sur la mise à jour pour soit promouvoir automatiquement le déploiement à la nouvelle version, soit revenir à la version stable précédente, en fonction des métriques collectées.

Peta Pikiran

Mind Map

Pertanyaan yang Sering Diajukan

  • Qu'est-ce que Argo Rollouts?

    Argo Rollouts est un contrôleur de livraison progressive pour Kubernetes, offrant des stratégies de mise à jour comme blue-green et canary.

  • Comment Argo Rollouts gère-t-il les mises à jour?

    Il intègre des maillages de services et des contrôleurs d'ingress pour rediriger le trafic et utilise des métriques pour analyser et ajuster les mises à jour.

  • Qu'est-ce que la livraison progressive?

    C'est le déploiement d'une mise à jour à un nombre croissant d'utilisateurs pour limiter les impacts négatifs potentiels.

  • Quels types de stratégies de mise à jour Argo Rollouts prend-il en charge?

    Il prend en charge les stratégies de mise à jour blue-green et canary.

  • Qu'arrive-t-il si une mise à jour échoue l'analyse d'Argo Rollouts?

    La mise à jour est automatiquement rétrogradée à la version stable précédente.

  • Quel rôle jouent les métriques dans Argo Rollouts?

    Les métriques sont utilisées pour évaluer le succès ou l'échec d'une mise à jour et déterminer s'il faut la promouvoir ou la rétrograder.

Lihat lebih banyak ringkasan video

Dapatkan akses instan ke ringkasan video YouTube gratis yang didukung oleh AI!
Teks
en
Gulir Otomatis:
  • 00:00:00
    in this video we will go through a quick
  • 00:00:03
    overview and demo of argo rollouts argo
  • 00:00:06
    rollouts
  • 00:00:07
    is a progressive delivery controller
  • 00:00:09
    which provides additional
  • 00:00:10
    update strategies such as blue green and
  • 00:00:12
    canary to kubernetes
  • 00:00:14
    and it does this by integrating with
  • 00:00:16
    various service meshes and
  • 00:00:18
    ingress controllers for the purposes of
  • 00:00:20
    shaping
  • 00:00:21
    and safely shifting traffic to versions
  • 00:00:23
    of the application
  • 00:00:25
    during an update argo rollouts will
  • 00:00:28
    query metric providers
  • 00:00:29
    and perform analysis on the update and
  • 00:00:32
    based on these metrics
  • 00:00:34
    is able to either automatically promote
  • 00:00:36
    the rollout to the new version
  • 00:00:37
    or roll back to the previous stable
  • 00:00:40
    version
  • 00:00:41
    so first off let's explain what exactly
  • 00:00:43
    is progressive delivery
  • 00:00:46
    progressive delivery is the practice of
  • 00:00:48
    gradually rolling out an
  • 00:00:49
    update to a progressively larger and
  • 00:00:52
    larger subset
  • 00:00:53
    of users and by doing this you are able
  • 00:00:56
    to limit the potential negative
  • 00:00:58
    impact of the update in the event that
  • 00:01:00
    something goes wrong
  • 00:01:02
    let's see how this can be applied in
  • 00:01:03
    practice using argo rollouts
  • 00:01:06
    let's say we want to deploy version 2 of
  • 00:01:09
    our application
  • 00:01:10
    after updating our spec rollouts can
  • 00:01:13
    expose a small percentage of traffic to
  • 00:01:15
    that new version
  • 00:01:16
    let's say five percent the controller
  • 00:01:19
    then waits while metrics are collected
  • 00:01:21
    on the application behavior after the
  • 00:01:23
    update
  • 00:01:24
    next those metrics will be analyzed to
  • 00:01:26
    determine whether or not the change is
  • 00:01:28
    causing any problems
  • 00:01:31
    if it's going smoothly the update
  • 00:01:33
    continues and the weight
  • 00:01:35
    is increased again and the process
  • 00:01:37
    repeats
  • 00:01:38
    otherwise if the analysis fails
  • 00:01:40
    inaugural rollouts will abort the update
  • 00:01:42
    and automatically roll back to the
  • 00:01:44
    previous stable version
  • 00:01:47
    our goal rollouts introduces some new
  • 00:01:49
    custom resources to your cluster
  • 00:01:52
    the rollout custom resource is intended
  • 00:01:54
    to be a drop-in
  • 00:01:55
    replacement for a deployment it has an
  • 00:01:57
    identical spec
  • 00:01:59
    but with added blue-green and canary
  • 00:02:01
    strategies
  • 00:02:02
    the rollout manages your networking and
  • 00:02:04
    service mesh related resources
  • 00:02:07
    in order to shape the traffic according
  • 00:02:08
    to your rollout steps
  • 00:02:10
    it then automates the promotion of your
  • 00:02:12
    rollout based on analysis
  • 00:02:16
    analysis is a custom resource which lets
  • 00:02:18
    you describe how to perform analysis
  • 00:02:21
    it lets you define what metrics to
  • 00:02:23
    measure and when
  • 00:02:24
    and how to interpret those measurements
  • 00:02:27
    as
  • 00:02:27
    an update is happening analysis
  • 00:02:30
    continuously queries metric providers
  • 00:02:32
    to measure the success of an update
  • 00:02:36
    so now we'll go through a quick demo of
  • 00:02:38
    argo rollouts in action
  • 00:02:41
    at the top left is the cubesat argo
  • 00:02:43
    rollouts plugin
  • 00:02:44
    showing a visual representation of
  • 00:02:46
    varela
  • 00:02:48
    this rollout is using the canary
  • 00:02:49
    strategy with the istio traffic routing
  • 00:02:52
    integration
  • 00:02:53
    it's running with a single replica and
  • 00:02:56
    it's currently running revision 1 of our
  • 00:02:58
    application
  • 00:03:01
    at the top right we have our demo
  • 00:03:03
    application
  • 00:03:04
    and every bubble that you see folding by
  • 00:03:06
    is a request
  • 00:03:07
    which our browser is making to the
  • 00:03:09
    backend
  • 00:03:10
    the backend responds with a color which
  • 00:03:13
    indicates which version
  • 00:03:14
    of the app it is there's a bar chart at
  • 00:03:17
    the bottom
  • 00:03:18
    which represents the percentage of
  • 00:03:20
    requests that were handled by
  • 00:03:22
    the different versions of the backend
  • 00:03:24
    and right now
  • 00:03:25
    since we are only running a single
  • 00:03:27
    version it's showing
  • 00:03:28
    it as 100 of the blue
  • 00:03:32
    at the bottom right of the screen is
  • 00:03:34
    kiali which is a
  • 00:03:36
    management console for the istio service
  • 00:03:38
    mesh
  • 00:03:40
    currently it's showing us that we have
  • 00:03:42
    traffic coming from the
  • 00:03:43
    istio gateway which is being split
  • 00:03:46
    between
  • 00:03:47
    two services istio rollout stable
  • 00:03:50
    and istio rollout canary and 100
  • 00:03:54
    of that traffic is being directed to the
  • 00:03:56
    stable version
  • 00:03:57
    and currently both of the surfaces are
  • 00:04:00
    reaching the same
  • 00:04:01
    set of pods finally at the bottom left
  • 00:04:06
    is the rollout
  • 00:04:07
    specification and as you can see the
  • 00:04:10
    rollout
  • 00:04:10
    looks nearly identical to the deployment
  • 00:04:13
    resource
  • 00:04:14
    but it does have a new section
  • 00:04:17
    which contains the canary update
  • 00:04:19
    strategy
  • 00:04:21
    the strategy describes the steps that
  • 00:04:23
    the rollout will take during an update
  • 00:04:26
    and for now you should understand that
  • 00:04:28
    the rollout will initially direct
  • 00:04:30
    10 of the traffic to the canary and then
  • 00:04:33
    pause
  • 00:04:34
    indefinitely so let's go ahead and
  • 00:04:38
    perform an
  • 00:04:38
    update i am going to change the
  • 00:04:42
    image from the blue to the yellow image
  • 00:04:56
    so what you see happening is that the
  • 00:04:59
    controller has started spinning up the
  • 00:05:01
    new version of the application
  • 00:05:03
    which you can see by the revision 2
  • 00:05:06
    replica set and once the new version is
  • 00:05:10
    running
  • 00:05:10
    if you can recall from our steps the
  • 00:05:13
    rollout will send 10
  • 00:05:14
    of the traffic to the canary and then
  • 00:05:16
    pause indefinitely
  • 00:05:19
    in our demo application you can now see
  • 00:05:21
    the yellow version that the back end is
  • 00:05:23
    servicing
  • 00:05:24
    some of our requests and from the bar
  • 00:05:26
    chart
  • 00:05:27
    roughly 10 of the requests are being
  • 00:05:30
    handled by the yellow version
  • 00:05:32
    the rollout controller also kicked off
  • 00:05:36
    analysis run and that's going to take
  • 00:05:39
    some time to
  • 00:05:40
    gather some measurements so while we're
  • 00:05:42
    waiting let's go ahead and look at the
  • 00:05:45
    analysis spec
  • 00:05:50
    so this is the analysis template that
  • 00:05:51
    our rollout is using
  • 00:05:53
    this analysis is using the prometheus
  • 00:05:55
    metric provider
  • 00:05:57
    and performing queries at 20 second
  • 00:05:59
    intervals
  • 00:06:01
    the query that is performing is taking
  • 00:06:04
    the total number of
  • 00:06:06
    non 500 requests and dividing it by
  • 00:06:09
    total request which is
  • 00:06:10
    effectively our success rate that result
  • 00:06:14
    is then
  • 00:06:14
    evaluated by the success condition
  • 00:06:18
    which if it ever drops below 90
  • 00:06:21
    the analysis will fail and we will
  • 00:06:23
    automatically
  • 00:06:24
    roll back in the plug-in
  • 00:06:27
    each of these green ticks represents a
  • 00:06:30
    measurement which was taken
  • 00:06:32
    and it as successful
  • 00:06:36
    and in kyali we can now see that roughly
  • 00:06:39
    10 of the traffic is reaching our canary
  • 00:06:43
    service
  • 00:06:44
    which is then being directed to the
  • 00:06:47
    canary
  • 00:06:48
    pods
  • 00:06:52
    so now let's introduce some errors in
  • 00:06:55
    our application
  • 00:06:56
    and see how the rollout behaves so our
  • 00:06:59
    demo app allows me to adjust
  • 00:07:01
    the error rate using this slider
  • 00:07:05
    and i will do that for the
  • 00:07:08
    yellow yellow surface
  • 00:07:14
    okay so i basically injected errors for
  • 00:07:17
    our yellow backend
  • 00:07:19
    and what should now happen is that the
  • 00:07:21
    next measurement that the controller
  • 00:07:23
    takes
  • 00:07:24
    should evaluate to a success rate
  • 00:07:27
    below 90 which will then abort the
  • 00:07:31
    rollout
  • 00:07:34
    and looking at kyoli we if you look at
  • 00:07:37
    the traffic pack
  • 00:07:39
    we can confirm that this success rate
  • 00:07:41
    has
  • 00:07:42
    dropped and and now
  • 00:07:45
    and sure enough on the plug-in
  • 00:07:49
    we see that it took a failed measurement
  • 00:07:51
    as
  • 00:07:52
    indicated by this red x and the analysis
  • 00:07:55
    run
  • 00:07:56
    has been marked failed
  • 00:07:59
    and the replica set has then been scaled
  • 00:08:02
    down
  • 00:08:03
    and the rollout is now degraded
  • 00:08:06
    and from our demo app we can see that
  • 00:08:10
    our back-end is no longer servicing any
  • 00:08:13
    uh requests
  • 00:08:14
    by our yellow version
  • 00:08:18
    so that's a quick demo of vargo rollouts
  • 00:08:22
    argument rollouts integrates with many
  • 00:08:24
    common service meshes and ingers
  • 00:08:26
    controllers
  • 00:08:27
    including the ones listed here one thing
  • 00:08:30
    to note is that the use of a service
  • 00:08:32
    measure english controller is optional
  • 00:08:34
    since it is possible to achieve canary
  • 00:08:36
    and blue-green updates without the use
  • 00:08:38
    of a traffic provider
  • 00:08:41
    in addition rollouts also integrates
  • 00:08:43
    with common metric providers
  • 00:08:46
    you can also perform queries against
  • 00:08:48
    your own custom metric provider
  • 00:08:49
    or even run kubernetes jobs to determine
  • 00:08:52
    the
  • 00:08:53
    success of analysis using your own
  • 00:08:55
    container and scripts
  • 00:08:58
    to learn more about rollouts please
  • 00:09:00
    visit our github page
  • 00:09:01
    read our blog or join our slack
Tags
  • Argo Rollouts
  • Kubernetes
  • livraison progressive
  • blue-green
  • canary
  • métriques
  • maillage de services
  • mise à jour
  • déploiement
  • analyse
  • rollback