A blue/green deployment runs the current version of a service alongside a replacement. The replacement can be tested in a production-like setup while the current version keeps serving production traffic. When the team is confident, it switches traffic to the replacement; keeping the earlier version available provides a rollback option. Running both versions at once requires extra resources. section 8.1.2
The traffic switch can be implemented at several levels:
- With Kubernetes resources, create two Deployments and a Service that selects pods from only one of them. Test the replacement through a separate Service, then change the production Service’s selector to the replacement’s labels. These manual changes can be error-prone. section 8.1.2 section 8.3.2
- With Knative Serving, tag the replacement revision for testing while its production traffic percentage remains at 0. At promotion, change the traffic rules from 100/0 to 0/100. section 8.2.2
- With Argo Rollouts, configure an active Service and a preview Service under a blueGreen strategy. Set autoPromotionEnabled to false when promotion must wait for manual approval; otherwise, promotion occurs when the new ReplicaSet is ready. section 8.3.2
Preview and promote a notifications-service release
For an Argo Rollouts deployment, apply the blue/green Rollout and its Services with `kubectl apply -f argo-rollouts/blue-green/`. Watch it with `kubectl argo rollouts get rollout notifications-service-bluegreen --watch`. After updating the image to v1.1.0, the preview route can return `NOTIFICATIONS-IMPROVED` while the active route still returns v1.0.0. Once the preview is accepted, run `kubectl argo rollouts promote notifications-service-bluegreen`. section 8.3.2
A switch at a specific time can matter when versions are not backward compatible. For a notifications-service v2.0.0 upgrade that requires client changes, teams must coordinate the client and service updates before changing Knative’s traffic rules. Blue/green routing controls which version receives requests; it does not remove that coordination requirement. section 8.2.2
Listing 8.20 Rollout defining a BlueGreen strategy
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: notifications-service-bluegreen
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: notifications-service
template:
metadata:
labels:
app: notifications-service
spec:
containers:
- name: notifications-service
image: salaboy/notifications-service-<HASH>:v1.0.0
env:
- name: KAFKA_URL
value: kafka.default.svc.cluster.local
..
strategy:
blueGreen:
activeService: notifications-service-blue
previewService: notifications-service-green
autoPromotionEnabled: false
The Rollout manifest shows the blueGreen strategy’s activeService, previewService, and manual-promotion setting together. section 8.3.2
