docs: add prerequisites to tutorials

README.md

@@ -127,13 +127,15 @@ spec:
       # builtin Prometheus check
       # minimum req success rate (non 5xx responses)
       # percentage (0-100)
-      threshold: 99
+      thresholdRange:
+        min: 99
       interval: 1m
     - name: request-duration
       # builtin Prometheus check
       # maximum req duration P99
       # milliseconds
-      threshold: 500
+      thresholdRange:
+        max: 500
       interval: 30s
     - name: "database connections"
       # custom Prometheus check

docs/gitbook/tutorials/contour-progressive-delivery.md

@@ -16,7 +16,7 @@ kubectl apply -f https://projectcontour.io/quickstart/contour.yaml
 
 The above command will deploy Contour and an Envoy daemonset in the `projectcontour` namespace.
 
-Install Flagger using Kustomize \(kubectl 1.14\) in the `projectcontour` namespace:
+Install Flagger using Kustomize (kubectl 1.14) in the `projectcontour` namespace:
 
 ```bash
 kubectl apply -k github.com/weaveworks/flagger//kustomize/contour

docs/gitbook/tutorials/istio-ab-testing.md

@@ -2,10 +2,48 @@
 
 This guide shows you how to automate A/B testing with Istio and Flagger.
 
-Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity.
+Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions.
+In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users.
+This is particularly useful for frontend applications that require session affinity.
 
 ![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png)
 
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.11** or newer and Istio **v1.0** or newer.
+
+Install Istio with telemetry support and Prometheus:
+
+```bash
+istioctl manifest apply --set profile=default
+```
+
+Install Flagger using Kustomize (kubectl 1.14) in the `istio-system` namespace:
+
+```bash
+kubectl apply -k github.com/weaveworks/flagger//kustomize/istio
+```
+
+Create an ingress gateway to expose the demo app outside of the mesh:
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: Gateway
+metadata:
+  name: public-gateway
+  namespace: istio-system
+spec:
+  selector:
+    istio: ingressgateway
+  servers:
+    - port:
+        number: 80
+        name: http
+        protocol: HTTP
+      hosts:
+        - "*"
+```
+
 ## Bootstrap
 
 Create a test namespace with Istio sidecar injection enabled:
@@ -132,7 +170,7 @@ virtualservice.networking.istio.io/podinfo
 Trigger a canary deployment by updating the container image:
 
 ```bash
-kubectl -n test set image deployment/abtest \
+kubectl -n test set image deployment/podinfo \
 podinfod=stefanprodan/podinfo:3.1.1
 ```
 
@@ -160,8 +198,8 @@ Events:
   Normal   Synced  55s   flagger  Advance podinfo.test canary iteration 8/10
   Normal   Synced  45s   flagger  Advance podinfo.test canary iteration 9/10
   Normal   Synced  35s   flagger  Advance podinfo.test canary iteration 10/10
-  Normal   Synced  25s   flagger  Copying podinfo.test template spec to abtest-primary.test
-  Warning  Synced  15s   flagger  Waiting for abtest-primary.test rollout to finish: 1 of 2 updated replicas are available
+  Normal   Synced  25s   flagger  Copying podinfo.test template spec to podinfo-primary.test
+  Warning  Synced  15s   flagger  Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
   Normal   Synced  5s    flagger  Promotion completed! Scaling down podinfo.test
 ```
 
@@ -173,7 +211,7 @@ You can monitor all canaries with:
 watch kubectl get canaries --all-namespaces
 
 NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
-test        abtest    Progressing   100      2019-03-16T14:05:07Z
+test        podinfo   Progressing   100      2019-03-16T14:05:07Z
 prod        frontend  Succeeded     0        2019-03-15T16:15:07Z
 prod        backend   Failed        0        2019-03-14T17:05:07Z
 ```
@@ -194,10 +232,11 @@ Generate latency:
 watch curl -b 'type=insider' http://app.example.com/delay/1
 ```
 
-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.
+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.
 
 ```text
-kubectl -n test describe canary/abtest
+kubectl -n test describe canary/podinfo
 
 Status:
   Failed Checks:         2

docs/gitbook/tutorials/istio-progressive-delivery.md

@@ -4,9 +4,48 @@ This guide shows you how to use Istio and Flagger to automate canary deployments
 
 ![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png)
 
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.11** or newer and Istio **v1.0** or newer.
+
+Install Istio with telemetry support and Prometheus:
+
+```bash
+istioctl manifest apply --set profile=default
+```
+
+Install Flagger using Kustomize (kubectl 1.14) in the `istio-system` namespace:
+
+```bash
+kubectl apply -k github.com/weaveworks/flagger//kustomize/istio
+```
+
+Create an ingress gateway to expose the demo app outside of the mesh:
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: Gateway
+metadata:
+  name: public-gateway
+  namespace: istio-system
+spec:
+  selector:
+    istio: ingressgateway
+  servers:
+    - port:
+        number: 80
+        name: http
+        protocol: HTTP
+      hosts:
+        - "*"
+```
+
 ## Bootstrap
 
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services, Istio destination rules and virtual services\). These objects expose the application inside the mesh 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,
+Istio destination rules and virtual services).
+These objects expose the application inside the mesh and drive the canary analysis and promotion.
 
 Create a test namespace with Istio sidecar injection enabled:
 
@@ -27,7 +66,7 @@ Deploy the load testing service to generate traffic during the canary analysis:
 kubectl apply -k github.com/weaveworks/flagger//kustomize/tester
 ```
 
-Create a canary custom resource \(replace example.com with your own domain\):
+Create a canary custom resource (replace example.com with your own domain):
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -116,7 +155,8 @@ Save the above resource as podinfo-canary.yaml and then apply it:
 kubectl apply -f ./podinfo-canary.yaml
 ```
 
-When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary. The canary analysis will run for five minutes while validating the HTTP metrics and rollout hooks every minute.
+When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary.
+The canary analysis will run for five minutes while validating the HTTP metrics and rollout hooks every minute.
 
 ![Flagger Canary Process](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-hpa.png)
 
@@ -226,7 +266,8 @@ Generate latency:
 watch curl http://podinfo-canary:9898/delay/1
 ```
 
-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.
+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.
 
 ```text
 kubectl -n test describe canary/podinfo
@@ -255,11 +296,14 @@ Events:
 
 ![Flagger Canary Traffic Shadowing](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-traffic-mirroring.png)
 
-For applications that perform read operations, Flagger can be configured to drive canary releases with traffic mirroring. Istio traffic mirroring will copy each incoming request, sending one request to the primary and one to the canary service. The response from the primary is sent back to the user and the response from the canary is discarded. Metrics are collected on both requests so that the deployment will only proceed if the canary metrics are within the threshold values.
+For applications that perform read operations, Flagger can be configured to drive canary releases with traffic mirroring.
+Istio traffic mirroring will copy each incoming request, sending one request to the primary and one to the canary service.
+The response from the primary is sent back to the user and the response from the canary is discarded.
+Metrics are collected on both requests so that the deployment will only proceed if the canary metrics are within the threshold values.
 
-Note that mirroring should be used for requests that are **idempotent** or capable of being processed twice \(once by the primary and once by the canary\).
+Note that mirroring should be used for requests that are **idempotent** or capable of being processed twice (once by the primary and once by the canary).
 
-You can enable mirroring by replacing `stepWeight/maxWeight` with `iterations` and by setting `canaryAnalysis.mirror` to `true`:
+You can enable mirroring by replacing `stepWeight/maxWeight` with `iterations` and by setting `analysis.mirror` to `true`:
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -303,7 +347,7 @@ spec:
 
 With the above configuration, Flagger will run a canary release with the following steps:
 
-* detect new revision \(deployment spec, secrets or configmaps changes\)
+* detect new revision (deployment spec, secrets or configmaps changes)
 * scale from zero the canary deployment
 * wait for the HPA to set the canary minimum replicas
 * check canary pods health
@@ -315,7 +359,7 @@ With the above configuration, Flagger will run a canary release with the followi
 * abort the canary release if the metrics check failure threshold is reached
 * stop traffic mirroring after the number of iterations is reached
 * route live traffic to the canary pods
-* promote the canary \(update the primary secrets, configmaps and deployment spec\)
+* promote the canary (update the primary secrets, configmaps and deployment spec)
 * wait for the primary deployment rollout to finish
 * wait for the HPA to set the primary minimum replicas
 * check primary pods health

docs/gitbook/tutorials/kubernetes-blue-green.md

@@ -57,17 +57,13 @@ kubectl create ns test
 Create a deployment and a horizontal pod autoscaler:
 
 ```bash
-export REPO=https://raw.githubusercontent.com/weaveworks/flagger/master
-
-kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
-kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml
+kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo
 ```
 
 Deploy the load testing service to generate traffic during the analysis:
 
 ```bash
-kubectl -n test apply -f ${REPO}/artifacts/loadtester/deployment.yaml
-kubectl -n test apply -f ${REPO}/artifacts/loadtester/service.yaml
+kubectl apply -k github.com/weaveworks/flagger//kustomize/tester
 ```
 
 Create a canary custom resource: