The triggers to transition from stage to stage can be automated. The blue and green clusters run at the same time, but only for a limited period of time, which optimizes costs and operational efforts.
Technical architect update#
Once the new version is live, it becomes the blue cluster for whatever change or update comes next. T3: Switch traffic to the green cluster.T2: Sync the Kubernetes state between the blue and green clusters.In our description, the blue cluster is the current version, and the green cluster is the new one. In a blue-green deployment there are five stages to updating the current version of the cluster to the new version. For details, see section T3: Switch traffic to the green cluster.Īpplication Gateway provides the front ends, which are dedicated to the private endpoints. This is done by using A and CNAME records. This diagram is for the private-facing case:įor this case, a single Azure DNS instance implements the switching of traffic between the blue and green clusters. If you want to use your own DNS and load balancer, you need to be sure that they're configured to provide a safe and reliable switch.Īzure Application Gateway provides the front ends, which are dedicated to the public endpoints. This technique is the most reliable and efficient in an Azure environment.
Technical architect full#
By using Azure Front Door, it's possible to implement a full switch or a more controlled switch that's based on weights.
For more information, see Blue-green deployment with Azure Front Door. The following diagram shows the architecture for the public-facing case:ĭownload a Visio file of this architecture.Īzure Front Door and Azure DNS provide the routing mechanism that switches traffic between the blue and green clusters. There's also a hybrid case, not discussed here, in which there's a mix of public-facing and private-facing applications and APIs in the cluster. The applications and APIs are private-facing.The applications and APIs are public-facing.
This section describes architectures for blue-green deployment of AKS clusters. This article describes the design and implementation of a blue-green deployment of AKS that uses Azure managed services and native Kubernetes features. Deploying in this way increases availability when making changes, including upgrades, to AKS clusters. Once the new version is validated, a routing change switches user traffic to it. This article provides guidance on implementing a blue-green deployment strategy to test a new version of an Azure Kubernetes Service (AKS) cluster while continuing to run the current version.
0 kommentar(er)
