Merge pull request #254 from weaveworks/podinfo

Use Kustomize installer in Linkerd docs

docs/gitbook/tutorials/canary-helm-gitops.md

@@ -138,7 +138,7 @@ helm upgrade -i frontend flagger/podinfo/ \
 --reuse-values \
 --set canary.loadtest.enabled=true \
 --set canary.helmtest.enabled=true \
---set image.tag=1.4.1
+--set image.tag=1.7.1
 ```
 
 Flagger detects that the deployment revision changed and starts the canary analysis:
@@ -283,17 +283,17 @@ metadata:
   namespace: test
   annotations:
     flux.weave.works/automated: "true"
-    flux.weave.works/tag.chart-image: semver:~1.4
+    flux.weave.works/tag.chart-image: semver:~1.7
 spec:
   releaseName: frontend
   chart:
     repository: https://stefanprodan.github.io/flagger/
     name: podinfo
-    version: 2.0.0
+    version: 2.3.0
   values:
     image:
       repository: quay.io/stefanprodan/podinfo
-      tag: 1.4.0
+      tag: 1.7.0
       backend: http://backend-podinfo:9898/echo
       canary:
         enabled: true
@@ -311,7 +311,7 @@ In the `chart` section I've defined the release source by specifying the Helm re
 In the `values` section I've overwritten the defaults set in values.yaml.
 
 With the `flux.weave.works` annotations I instruct Flux to automate this release. 
-When an image tag in the sem ver range of `1.4.0 - 1.4.99` is pushed to Quay, 
+When an image tag in the sem ver range of `1.7.0 - 1.7.99` is pushed to Quay, 
 Flux will upgrade the Helm release and from there Flagger will pick up the change and start a canary deployment.
 
 Install [Weave Flux](https://github.com/weaveworks/flux) and its Helm Operator by specifying your Git repo URL:
@@ -321,6 +321,7 @@ helm repo add weaveworks https://weaveworks.github.io/flux
 
 helm install --name flux \
 --set helmOperator.create=true \
+--set helmOperator.createCRD=true \
 --set git.url=git@github.com:<USERNAME>/<REPOSITORY> \
 --namespace flux \
 weaveworks/flux
@@ -343,9 +344,9 @@ launch the `frontend` and `backend` apps.
 
 A CI/CD pipeline for the `frontend` release could look like this:
 
-* cut a release from the master branch of the podinfo code repo with the git tag `1.4.1`
+* cut a release from the master branch of the podinfo code repo with the git tag `1.7.1`
 * CI builds the image and pushes the `podinfo:1.7.1` image to the container registry
-* Flux scans the registry and updates the Helm release `image.tag` to `1.4.1`
+* Flux scans the registry and updates the Helm release `image.tag` to `1.7.1`
 * Flux commits and push the change to the cluster repo
 * Flux applies the updated Helm release on the cluster
 * Flux Helm Operator picks up the change and calls Tiller to upgrade the release
@@ -355,7 +356,7 @@ A CI/CD pipeline for the `frontend` release could look like this:
 * Based on the analysis result the canary deployment is promoted to production or rolled back
 * Flagger sends a Slack notification with the canary result
 
-If the canary fails, fix the bug, do another patch release eg `1.4.2` and the whole process will run again.
+If the canary fails, fix the bug, do another patch release eg `1.7.2` and the whole process will run again.
 
 A canary deployment can fail due to any of the following reasons:
 

docs/gitbook/usage/linkerd-progressive-delivery.md

@@ -11,24 +11,13 @@ Flagger requires a Kubernetes cluster **v1.11** or newer and Linkerd **2.4** or
 Install Flagger in the linkerd namespace:
 
 ```bash
-helm repo add flagger https://flagger.app
-
-helm upgrade -i flagger flagger/flagger \
---namespace linkerd \
---set metricsServer=http://linkerd-prometheus:9090 \
---set meshProvider=linkerd
+kubectl apply -k github.com/weaveworks/flagger//kustomize/linkerd
 ```
 
-Optionally you can enable Slack notifications:
+Note that you'll need kubectl 1.14 or newer to run the above command.
 
-```bash
-helm upgrade -i flagger flagger/flagger \
---reuse-values \
---namespace linkerd \
---set slack.url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK \
---set slack.channel=general \
---set slack.user=flagger
-```
+To enable Slack or MS Teams notifications,
+see Flagger's [install docs](https://docs.flagger.app/install/flagger-install-on-kubernetes) for Kustomize or Helm options.
 
 ### Bootstrap
 
@@ -46,17 +35,13 @@ kubectl annotate namespace test linkerd.io/inject=enabled
 Install the load testing service to generate traffic during the canary analysis:
 
 ```bash
-helm upgrade -i flagger-loadtester flagger/loadtester \
---namespace=test
+kubectl apply -k github.com/weaveworks/flagger//kustomize/tester
 ```
 
 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
 ```
 
 Create a canary custom resource for the podinfo deployment:
@@ -223,7 +208,7 @@ Trigger another canary deployment:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=quay.io/stefanprodan/podinfo:1.4.2
+podinfod=quay.io/stefanprodan/podinfo:1.7.2
 ```
 
 Exec into the load tester pod with:
@@ -312,7 +297,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=quay.io/stefanprodan/podinfo:1.4.3
+podinfod=quay.io/stefanprodan/podinfo:1.7.3
 ```
 
 Generate 404s:
@@ -459,7 +444,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=quay.io/stefanprodan/podinfo:1.5.0
+podinfod=quay.io/stefanprodan/podinfo:1.7.4
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B testing:

kustomize/podinfo/deployment.yaml

@@ -0,0 +1,66 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: podinfo
+  labels:
+    app: podinfo
+spec:
+  minReadySeconds: 5
+  revisionHistoryLimit: 5
+  progressDeadlineSeconds: 60
+  strategy:
+    rollingUpdate:
+      maxUnavailable: 0
+    type: RollingUpdate
+  selector:
+    matchLabels:
+      app: podinfo
+  template:
+    metadata:
+      annotations:
+        prometheus.io/scrape: "true"
+      labels:
+        app: podinfo
+    spec:
+      containers:
+      - name: podinfod
+        image: quay.io/stefanprodan/podinfo:1.7.0
+        imagePullPolicy: IfNotPresent
+        ports:
+        - containerPort: 9898
+          name: http
+          protocol: TCP
+        command:
+        - ./podinfo
+        - --port=9898
+        - --level=info
+        - --random-delay=false
+        - --random-error=false
+        env:
+        - name: PODINFO_UI_COLOR
+          value: blue
+        livenessProbe:
+          exec:
+            command:
+            - podcli
+            - check
+            - http
+            - localhost:9898/healthz
+          initialDelaySeconds: 5
+          timeoutSeconds: 5
+        readinessProbe:
+          exec:
+            command:
+            - podcli
+            - check
+            - http
+            - localhost:9898/readyz
+          initialDelaySeconds: 5
+          timeoutSeconds: 5
+        resources:
+          limits:
+            cpu: 2000m
+            memory: 512Mi
+          requests:
+            cpu: 100m
+            memory: 64Mi

kustomize/podinfo/hpa.yaml

@@ -0,0 +1,18 @@
+apiVersion: autoscaling/v2beta1
+kind: HorizontalPodAutoscaler
+metadata:
+  name: podinfo
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  minReplicas: 2
+  maxReplicas: 4
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      # scale up if usage is above
+      # 99% of the requested CPU (100m)
+      targetAverageUtilization: 99

kustomize/podinfo/kustomization.yaml

@@ -0,0 +1,5 @@
+namespace: test
+resources:
+  - hpa.yaml
+  - deployment.yaml
+