Update podinfo to v3.1.0

charts/podinfo/Chart.yaml

@@ -1,10 +1,10 @@
 apiVersion: v1
-version: 3.0.0
-appVersion: 2.0.0
+version: 3.1.0
+appVersion: 3.1.0
 name: podinfo
 engine: gotpl
 description: Flagger canary deployment demo chart
-home: https://github.com/weaveworks/flagger
+home: https://flagger.app
 maintainers:
 - email: stefanprodan@users.noreply.github.com
   name: stefanprodan

charts/podinfo/templates/deployment.yaml

@@ -37,6 +37,9 @@ spec:
             - --random-delay={{ .Values.faults.delay }}
             - --random-error={{ .Values.faults.error }}
             - --config-path=/podinfo/config
+            {{- range .Values.backends }}
+            - --backend-url={{ . }}
+            {{- end }}
           env:
           {{- if .Values.message }}
           - name: PODINFO_UI_MESSAGE

charts/podinfo/values.yaml

@@ -1,24 +1,25 @@
 # Default values for podinfo.
 image:
   repository: stefanprodan/podinfo
-  tag: 2.0.0
+  tag: 3.1.0
   pullPolicy: IfNotPresent
 
 podAnnotations: {}
 
 service:
+  enabled: false
   type: ClusterIP
   port: 9898
 
 hpa:
   enabled: true
   minReplicas: 2
-  maxReplicas: 2
+  maxReplicas: 4
   cpu: 80
   memory: 512Mi
 
 canary:
-  enabled: true
+  enabled: false
   # Istio traffic policy tls can be DISABLE or ISTIO_MUTUAL
   istioTLS: DISABLE
   istioIngress:
@@ -71,6 +72,7 @@ fullnameOverride: ""
 
 logLevel: info
 backend: #http://backend-podinfo:9898/echo
+backends: []
 message: #UI greetings
 
 faults:

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

@@ -51,7 +51,7 @@ helm upgrade -i frontend flagger/podinfo \
 --namespace test \
 --set nameOverride=frontend \
 --set backend=http://backend.test:9898/echo \
---set canary.loadtest.enabled=true \
+--set canary.enabled=true \
 --set canary.istioIngress.enabled=true \
 --set canary.istioIngress.gateway=public-gateway.istio-system.svc.cluster.local \
 --set canary.istioIngress.host=frontend.istio.example.com
@@ -91,7 +91,7 @@ Now let's install the `backend` release without exposing it outside the mesh:
 helm upgrade -i backend flagger/podinfo \
 --namespace test \
 --set nameOverride=backend \
---set canary.loadtest.enabled=true \
+--set canary.enabled=true \
 --set canary.istioIngress.enabled=false
 ```
 
@@ -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=2.0.1
+--set image.tag=3.1.1
 ```
 
 Flagger detects that the deployment revision changed and starts the canary analysis:
@@ -177,6 +177,7 @@ Now trigger a canary deployment for the `backend` app, but this time you'll chan
 helm upgrade -i backend flagger/podinfo/ \
 --namespace test \
 --reuse-values \
+--set canary.loadtest.enabled=true \
 --set canary.helmtest.enabled=true \
 --set httpServer.timeout=25s
 ```
@@ -283,7 +284,7 @@ metadata:
   namespace: test
   annotations:
     flux.weave.works/automated: "true"
-    flux.weave.works/tag.chart-image: semver:~2.0
+    flux.weave.works/tag.chart-image: semver:~3.1
 spec:
   releaseName: frontend
   chart:
@@ -293,7 +294,7 @@ spec:
   values:
     image:
       repository: stefanprodan/podinfo
-      tag: 2.0.0
+      tag: 3.1.0
       backend: http://backend-podinfo:9898/echo
       canary:
         enabled: true
@@ -311,7 +312,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 `2.0.0 - 2.0.99` is pushed to Quay, 
+When an image tag in the sem ver range of `3.1.0 - 3.1.99` is pushed to Docker Hub, 
 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:
@@ -344,9 +345,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 `2.0.1`
-* CI builds the image and pushes the `podinfo:2.0.1` image to the container registry
-* Flux scans the registry and updates the Helm release `image.tag` to `2.0.1`
+* cut a release from the master branch of the podinfo code repo with the git tag `3.1.1`
+* CI builds the image and pushes the `podinfo:3.1.1` image to the container registry
+* Flux scans the registry and updates the Helm release `image.tag` to `3.1.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
@@ -354,9 +355,9 @@ A CI/CD pipeline for the `frontend` release could look like this:
 * Flagger runs the helm test before routing traffic to the canary service
 * Flagger starts the load test and runs the canary analysis 
 * Based on the analysis result the canary deployment is promoted to production or rolled back
-* Flagger sends a Slack notification with the canary result
+* Flagger sends a Slack or MS Teams notification with the canary result
 
-If the canary fails, fix the bug, do another patch release eg `2.0.2` and the whole process will run again.
+If the canary fails, fix the bug, do another patch release eg `3.1.2` and the whole process will run again.
 
 A canary deployment can fail due to any of the following reasons:
 

kustomize/podinfo/deployment.yaml

@@ -10,7 +10,7 @@ spec:
   progressDeadlineSeconds: 60
   strategy:
     rollingUpdate:
-      maxUnavailable: 0
+      maxUnavailable: 1
     type: RollingUpdate
   selector:
     matchLabels:
@@ -24,21 +24,27 @@ spec:
     spec:
       containers:
       - name: podinfod
-        image: stefanprodan/podinfo:2.0.0
+        image: stefanprodan/podinfo:3.1.0
         imagePullPolicy: IfNotPresent
         ports:
-        - containerPort: 9898
-          name: http
+        - name: http
+          containerPort: 9898
+          protocol: TCP
+        - name: http-metrics
+          containerPort: 9797
+          protocol: TCP
+        - name: grpc
+          containerPort: 9999
           protocol: TCP
         command:
         - ./podinfo
         - --port=9898
+        - --port-metrics=9797
+        - --grpc-port=9999
+        - --grpc-service-name=podinfo
         - --level=info
         - --random-delay=false
         - --random-error=false
-        env:
-        - name: PODINFO_UI_COLOR
-          value: blue
         livenessProbe:
           exec:
             command: