BlueGreen deployment for Kubernetes app with Istio
Similar to canary deployment, PipeCD allows you to enable and automate the blue-green deployment strategy for your application based on Istio’s weighted routing feature.
In both canary and blue-green strategies, the old version and the new version of the application get deployed at the same time. But while the canary strategy slowly routes the traffic to the new version, the blue-green strategy quickly routes all traffic to one of the versions.
In this guide, we will show you how to configure the application configuration file to apply the blue-green strategy.
Complete source code for this example is hosted in pipe-cd/examples repository.
Before you begin
- Add a new Kubernetes application by following the instructions in this guide
- Ensure having
pipecd.dev/variant: primary
label and selector in the workload template - Ensure having at least one Istio’s
DestinationRule
and defining the needed subsets (primary
andcanary
) withpipecd.dev/variant
label
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: mesh-istio-bluegreen
spec:
host: mesh-istio-bluegreen
subsets:
- name: primary
labels:
pipecd.dev/variant: primary
- name: canary
labels:
pipecd.dev/variant: canary
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
- Ensure having at least one Istio’s
VirtualService
manifest and all traffic is routed to theprimary
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: mesh-istio-bluegreen
spec:
hosts:
- mesh-istio-bluegreen.pipecd.dev
gateways:
- mesh-istio-bluegreen
http:
- route:
- destination:
host: mesh-istio-bluegreen
subset: primary
weight: 100
Enabling blue-green strategy
- Add the following application configuration file into the application directory in the Git repository.
apiVersion: pipecd.dev/v1beta1
kind: KubernetesApp
spec:
pipeline:
stages:
- name: K8S_CANARY_ROLLOUT
with:
replicas: 100%
- name: K8S_TRAFFIC_ROUTING
with:
all: canary
- name: WAIT_APPROVAL
- name: K8S_PRIMARY_ROLLOUT
- name: K8S_TRAFFIC_ROUTING
with:
all: primary
- name: K8S_CANARY_CLEAN
trafficRouting:
method: istio
istio:
host: mesh-istio-bluegreen
- Send a PR to update the container image version in the Deployment manifest and merge it to trigger a new deployment. PipeCD will plan the deployment with the specified blue-green strategy.
Deployment Details Page
- Now you have an automated blue-green deployment for your application. 🎉
Understanding what happened
In this example, you configured the application configuration file to switch all traffic from an old to a new version of the application using Istio’s weighted routing feature.
- Stage 1:
K8S_CANARY_ROLLOUT
ensures that the workloads of canary variant (new version) should be deployed. But at this time, they still handle nothing, all traffic is handled by workloads of primary variant. The number of workloads (e.g. pod) for canary variant is configured to be 100% of the replicas number of primary varant.
- Stage 2:
K8S_TRAFFIC_ROUTING
ensures that all traffic should be routed to canary variant. Because thetrafficRouting
is configured to use Istio, PipeCD will find Istio’s VirtualService resource of this application to control the traffic percentage. (You can add an ANALYSIS stage after this to validate the new version. When any negative impacts are detected, an auto-rollback stage will be executed to switch all traffic back to the primary variant.)
-
Stage 3:
WAIT_APPROVAL
waits for a manual approval from someone in your team. -
Stage 4:
K8S_PRIMARY_ROLLOUT
ensures that all resources of primary variant will be updated to the new version.
- Stage 5:
K8S_TRAFFIC_ROUTING
ensures that all traffic should be routed to primary variant. Now primary variant is running the new version so it means all traffic is handled by the new version.
- Stage 6:
K8S_CANARY_CLEAN
ensures all created resources for canary variant should be destroyed.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.