From 41497c73f499f5324340e397d7f90a7b44681434 Mon Sep 17 00:00:00 2001 From: Kevin Dorosh Date: Wed, 16 Dec 2020 13:49:51 -0500 Subject: [PATCH] Update documented flow Signed-off-by: Kevin Dorosh --- README.md | 2 +- .../tutorials/gloo-progressive-delivery.md | 21 +++++++++++-------- docs/gitbook/usage/deployment-strategies.md | 6 +++--- 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 6b27dbd5..3d45c4e6 100644 --- a/README.md +++ b/README.md @@ -201,7 +201,7 @@ For more details on how the canary analysis and promotion works please [read the | Feature | Contour | Gloo | NGINX | Skipper | Traefik | | ------------------------------------------ | ------------------ | ------------------ | ------------------ | ------------------ | ------------------ | | Canary deployments (weighted traffic) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | -| A/B testing (headers and cookies routing) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | +| A/B testing (headers and cookies routing) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | | Blue/Green deployments (traffic switch) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | | Webhooks (acceptance/load testing) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | | Manual gating (approve/pause/resume) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | diff --git a/docs/gitbook/tutorials/gloo-progressive-delivery.md b/docs/gitbook/tutorials/gloo-progressive-delivery.md index 041de1b0..99d5dca9 100644 --- a/docs/gitbook/tutorials/gloo-progressive-delivery.md +++ b/docs/gitbook/tutorials/gloo-progressive-delivery.md @@ -1,12 +1,15 @@ # Gloo Canary Deployments -This guide shows you how to use the [Gloo](https://gloo.solo.io/) ingress controller and Flagger to automate canary deployments. +This guide shows you how to use the [Gloo Edge](https://gloo.solo.io/) ingress controller and Flagger to automate canary deployments. ![Flagger Gloo Ingress Controller](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-gloo-overview.png) ## Prerequisites -Flagger requires a Kubernetes cluster **v1.11** or newer and Gloo ingress **1.3.5** or newer. +This guide was written for Flagger version **1.5.0** or higher. Prior versions of Flagger used Gloo upstream groups to handle +canaries, but newer versions of Flagger use Gloo route tables to handle canaries as well as A/B testing. + +Flagger requires a Kubernetes cluster **v1.11** or newer and Gloo Edge ingress **1.6.0** or newer. Install Gloo with Helm v3: @@ -30,7 +33,7 @@ helm upgrade -i flagger flagger/flagger \ ## Bootstrap -Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services and Gloo upstream groups\). These objects expose the application outside the cluster and drive the canary analysis and promotion. +Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services and Gloo route tables groups\). These objects expose the application outside the cluster and drive the canary analysis and promotion. Create a test namespace: @@ -50,7 +53,7 @@ Deploy the load testing service to generate traffic during the canary analysis: kubectl -n test apply -k github.com/weaveworks/flagger//kustomize/tester ``` -Create an virtual service definition that references an upstream group that will be generated by Flagger \(replace `app.example.com` with your own domain\): +Create an virtual service definition that references an route table that will be generated by Flagger \(replace `app.example.com` with your own domain\): ```yaml apiVersion: gateway.solo.io/v1 @@ -65,8 +68,8 @@ spec: routes: - matchers: - prefix: / - routeAction: - upstreamGroup: + delegateAction: + ref: name: podinfo namespace: test ``` @@ -165,7 +168,7 @@ horizontalpodautoscaler.autoscaling/podinfo-primary service/podinfo service/podinfo-canary service/podinfo-primary -upstreamgroups.gloo.solo.io/podinfo +routetables.gateway.solo.io/podinfo ``` When the bootstrap finishes Flagger will set the canary status to initialized: @@ -247,13 +250,13 @@ podinfod=stefanprodan/podinfo:3.1.2 Generate HTTP 500 errors: ```bash -watch curl -H 'Host: app.example.com' http://gateway-proxy-v2.gloo-system/status/500 +watch curl -H 'Host: app.example.com' http://gateway-proxy.gloo-system/status/500 ``` Generate high latency: ```bash -watch curl -H 'Host: app.example.com' http://gateway-proxy-v2.gloo-system/delay/2 +watch curl -H 'Host: app.example.com' http://gateway-proxy.gloo-system/delay/2 ``` When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed. diff --git a/docs/gitbook/usage/deployment-strategies.md b/docs/gitbook/usage/deployment-strategies.md index 5835cf90..2b42bbbe 100644 --- a/docs/gitbook/usage/deployment-strategies.md +++ b/docs/gitbook/usage/deployment-strategies.md @@ -3,11 +3,11 @@ Flagger can run automated application analysis, promotion and rollback for the following deployment strategies: * **Canary Release** \(progressive traffic shifting\) - * Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo, Traefik + * Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo Edge, Traefik * **A/B Testing** \(HTTP headers and cookies traffic routing\) - * Istio, App Mesh, NGINX, Contour + * Istio, App Mesh, NGINX, Contour, Gloo Edge * **Blue/Green** \(traffic switching\) - * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo + * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo Edge * **Blue/Green Mirroring** \(traffic shadowing\) * Istio