github/flagger
1
0
Fork 0
mirror of https://github.com/fluxcd/flagger.git synced 2026-04-15 06:57:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update documented flow

Browse Source 
Signed-off-by: Kevin Dorosh <kcdorosh@gmail.com>
This commit is contained in:
Kevin Dorosh
2020-12-22 10:09:20 -05:00
parent 2e1b3fc8de
commit 41497c73f4
3 changed files with 16 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/gitbook/tutorials/gloo-progressive-delivery.md
+12 -9
View File
@@ -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.