Check the Deployments created by the Helm chart:
kubectl get deploy -l app.kubernetes.io/managed-by=Helm
Look at the Pods and the "slot" label:
kubectl get po -l component=web -L slot -o wide
You'll see all the Pods in the Service - the selector is not choosing by the slot label:
kubectl describe svc vweb-web
Browse to the app at http://localhost:30019; requests are load-balanced between the blue and green Pods.
The fix is to the label selector in the Service - adding the activeSlot value:
Update the chart to use the new template:
helm upgrade vweb labs/rollouts/solution/helm/vweb
Refresh at http://localhost:30019 - all responses are blue (v1), which is the default slot in the values file.
Switch to the green slot:
helm upgrade --set activeSlot=green vweb labs/rollouts/solution/helm/vweb
And now the app is running the green (v2) release.
With a blue-green update there is no delay while the new Pods come online, they're already up and running.
Open a new split terminal so you can track the changes to the blue release:
kubectl get po -l slot=blue --watch
The Helm upgrade command supports the atomic flag - so any errors in the upgrade cause the whole release to roll back to the previous definition.
This update doesn't cause an error during deployment, so you need a timeout to force the rollback when the Pods enter the CrashLoopBackOff state:
helm upgrade --reuse-values --set blueImage=kiamol/ch09-vweb:v3 --atomic --timeout 30s vweb labs/rollouts/solution/helm/vweb
You'll see the new v3 Pods fail, and after the timeout Helm rolls back they get terminated. The v1 Pods keep running because the update fails.
Specifying reuse-values means the green release is still active, so the failed blue update doesn't affect the app.
Back to the exercises