Blue Green Deployment with Kubernetes

What is Blue Green Deployment in Kubernetes?

Blue Green Deployment Kubernetes is a deployment strategy that involves managing two identical environments simultaneously. The "blue" environment represents the present stable version of the application, while the "green" environment represents the updated version. The main objective of this strategy is to seamlessly switch traffic between these two environments.

To better understand this concept, let's consider an example of an application deployed on a Kubernetes production environment. As we know, new code changes are introduced frequently, sometimes even on a weekly or daily basis. Previously, to roll out a new version of the application, all nodes in the target environment had to be updated simultaneously with the new service or artifact version. This approach had its drawbacks, as it was not outage-proof, and rolling back changes in case of issues was challenging. Moreover, the transition process would result in some downtime, which could be a significant concern for organizations. Downtime not only affects the reputation of the application but also potentially leads to a loss of potential customers.

To address these issues, various deployment methods have been developed and are used based on the specific requirements of organizations.

Benefits of using Blue Green Deployment in Kubernetes

There are numerous advantages to leveraging the Blue Green deployment kubernetes. Let's explore some of the key factors that make it a highly beneficial approach for software releases:

1. Backup System: One of the key advantages of a blue green deployment kubernetes is the presence of a standby system, which acts as a crucial backup in case of system failures. By maintaining two identical environments, organizations can easily switch to the backup server during unforeseen events or malware breaches, improving overall risk management and ensuring business continuity.
2. Seamless Traffic Switching: The advantage of using a blue green deployment Kubernetes lies in its ability to redirect traffic effortlessly between the two system versions. Since both environments share the same infrastructure, the system can remain live and functional while any issues are being addressed.
3. Efficient and Quick Releases: With a blue green deployment kubernetes, organizations can achieve rapid software releases. This approach offers the flexibility to roll out updates at any time without requiring downtime. End-users experience minimal impact during the release.
4. Simplified Rollback Process: In the event of an issue or error, rolling back an update becomes a straightforward process in a blue green deployment kubernetes. This simplified rollback mechanism reduces the risks associated with experimenting in a live production environment.
5. Elimination of Downtime: Downtime, whether planned or unexpected, can be completely avoided with a blue green deployment kubernetes. During maintenance checks or fixes, users can be seamlessly shifted to the other environment, ensuring uninterrupted service.

Getting Started

After gaining a sufficient understanding of the theoretical explanations and examples behind blue green deployment kubernetes, let's now shift our focus to the practical implementation of this strategy. We’ll need to define some common ground. You’ll need:

1. Kubernetes Cluster
2. Docker registry to store the container images.
3. Any Cloud Provider account (AWS, Azure, GCP, etc)
4. Kubectl CLI and cluster config or any tools that might be helpful.

This is an overview image how it is done.

Continuous Integration Pipeline Setup

In a working organization, we can assume that there is already a Continous Integration pipeline set up for carrying out the build and testing process. If you're using this for your project or setup we will have to build our own pipeline for carrying out the docker build process and pushing it to the artifact repository of your choice in our case we will be using DockerHub. We can use any CI tool you like for now we will be using Jenkins.

This is an example of Jenkinsfile which can be used for pushing your DockerImage to Dockerhub:

This file could already exist in your organization or you might need to create one for use. Once done we are ready for our next part.

Release Organization

Release organization is a critical aspect of Kubernetes blue green deployment, ensuring a smooth and efficient release process. By structuring releases, managing versioning, and coordinating with development and operations teams, organizations can effectively implement blue green deployment kubernetes. To begin, establishing a clear release structure is essential. This includes defining release cycles, determining the frequency of releases, and setting up a standardized process for each release. By having a well-defined structure, teams can plan and execute deployments with ease.

Version management is another crucial component of release organization. It involves tracking and managing different versions of the application, ensuring proper documentation and control over changes. In the context of Kubernetes, managing manifests and configuration files becomes crucial. These files define the desired state of the application and its infrastructure. Proper organization and versioning of these files enable smooth and efficient deployments in a blue green environment. By using configuration management tools or Git repositories, teams can effectively manage and organize these files, ensuring consistency and reducing errors during the release process.

Blue Pipelines

The blue green deployment kubernetes method relies heavily on blue pipelines. They stand in for the stable environment, which is often the most recent iteration of the program that is now handling live traffic. An overview of blue pipelines in the context of blue green deployment kubernetes is provided below:

1. Purpose: Blue pipelines are used to preserve the reliability and accessibility of the current version of the program. Throughout the deployment process, they make sure that users continue to receive unbroken service.
2. Testing and Validation: Blue Pipelines are in charge of conducting the necessary tests and validations on the most recent version of the program. This covers any necessary checks to guarantee the stability and caliber of the current environment, such as functional testing, performance testing, and others.
3. Monitoring: To keep track of the well-being and effectiveness of the blue environment, blue pipelines frequently include monitoring methods. This enables teams to proactively identify any potential problems or abnormalities and take the necessary steps.
4. Scaling and Capacity: For the stable environment, scaling and capacity management are handled by blue pipelines. They make sure that the system underpinning the blue environment is capable of handling the anticipated load and performance demands.
5. Rollback Capability: Blue pipelines offer the possibility to swiftly roll back to the stable blue version in the event of problems or failures in the green environment. This guarantees a quick and easy return to the trustworthy condition when necessary.

eg:

An Overview of what happens in Blue Pipelines.

• Deploys API and website to the blue environment for blue pipeline.
• Jenkins pulls the branch for the last revision.
• After that Jenkins starts building and preparing deployment packages.
• When done Jenkins stop sites(Stop load balancer routing, stop IIS)
• Once done it will Copy new files and start the Sites( Start only IIS, not routing)

Note: These YAML files are simple examples for demonstration purposes. In a real-world scenario, you may need to modify and customize these files based on your specific application's requirements and environment settings.

blue-deployment.yml

blue-service.yml

Overall in blue green deployment kubernetes, blue deployment serves as a backbone to maintain stability when trying to release a new update. It gives a rollback capability.

Cleanup Pipelines

The Kubernetes blue green deployment kubernetes process includes cleanup pipelines, which are in charge of maintaining and deleting resources related to the old version (blue) following the successful deployment of the new version (green). An overview of cleanup pipelines in blue green deployment kubernetes is shown below:

1. Purpose: After a successful deployment to the new green environment, cleanup pipelines are created to get rid of any traces of the old blue environment that is no longer needed. This guarantees effective resource use and upholds a tidy and orderly deployment infrastructure.
2. Resource Cleanup: Resources connected to the blue environment, such as pods, services, deployments, and any other Kubernetes objects unique to the old version, are removed using cleanup pipelines. By doing so, resource duplication is avoided, and the deployment environment is kept simple.
3. Configuration Cleanup: In addition to the dumping of resources, cleanup pipelines can also take care of the removal of configuration files, environment variables, and other blue environment artifacts. By ensuring that only relevant and recent configuration is kept, and other clutters are removed to reduce potential confusion later on.
4. Database Management: If your application depends on a database, cleanup pipelines might need to perform operations like data migration, schema upgrades, or removing unused temporary data. Data integrity is guaranteed and performance for the new version is optimized by proper database management.
5. Post-Deployment Validation: Cleanup pipelines may include validation processes to confirm that the cleanup process was effective and that the green environment is completely functional and operational following the removal of the blue environment.

Organizations can maintain a tidy and effective infrastructure, reduce resource waste, and guarantee a seamless switch from the old to the new version by integrating cleanup pipelines into the deployment process. Cleanup pipelines are essential for streamlining a blue green deployment kubernetes approach and optimizing the deployment lifetime.

Green Pipelines

Green pipelines are a key component of the blue green deployment kubernetes strategy, representing the environment hosting the updated version of the application. Let's explore a brief overview of green pipelines:

1. Purpose: Green pipelines have the function of distributing and testing the new application version in a controlled manner. Before sending live traffic to the upgraded version, they give a separate place for validating it.
2. Deployment of New Version: Green pipelines are responsible for deploying the new version of the application to the green environment. Applying Kubernetes manifests, setting up resources, and making sure the environment is prepared to handle traffic are all included in this.
3. Testing and Validation: The revised version is thoroughly tested and validated by Green Pipelines. Testing of all kinds, including functional, integration, performance, and security testing, are included in this. It is essential to make sure the new version satisfies quality requirements and functions as intended.
4. Gradual Traffic Shift: Traffic can be moved gradually from the blue environment to the green environment with the help of green pipelines. Load balancing, DNS switching, or other traffic routing techniques can accomplish this. The intention is to progressively increase traffic going to green spaces while keeping an eye on their stability and performance.
5. Monitoring and Rollback: Monitoring systems are set up during the green pipeline to keep tabs on the health and functionality of the new version. This aids in the early detection of any problems or anomalies. In the event of serious problems, a rollback mechanism may be activated to return to the reliable blue environment.

eg:

Here's an overview of what happens during Green Pipelines.

• Jenkins takes parameters to deploy which version (We prepared packages in blue)
• Once done Jenkins activates Blue Sites Routings(Load balancer)
• Jenkins Stop Sites(Stop load balancer routing, stop IIS) & copy new files.
• Once done Jenkins Start Sites(Start only IIS, not routing) and then Activate Blue Sites Routings(Load balancer). Once it's done, we are LIVE! The load balancer now sends requests to all servers (blue and green)

Note: These YAML files are simple examples for demonstration purposes. In a real-world scenario, you may need to modify and customize these files based on your specific application's requirements and environment settings.

green-deployment.yml

green-service.yml

In order to provide a regulated and verified deployment of the new version, green pipelines are essential. They provide a dedicated space for testing, monitoring, and gradually transitioning traffic, ultimately leading to a smooth and successful blue green deployment in Kubernetes.

Deployment to the Green Pipeline

Before deploying to the green pipeline, it is essential to verify that the new version of the application has undergone sufficient testing and validation in the green environment. This includes functional testing, integration testing, performance testing, and any other relevant checks to ensure the stability and quality of the updated version. Some key points we need to take care of are:

1. Deployment Strategy: Establish the green pipeline's deployment plan. This could involve canary deployments, where a small part of the traffic is initially routed to the green environment for additional testing prior to scaling up, or rolling upgrades, where the new version gradually replaces the previous one.
2. Traffic Routing: Implement the appropriate procedures to route live traffic towards the environment's green spaces. Load balancing, DNS switching, or employing Kubernetes ingress controllers to regulate traffic routing rules can all be used to do this. Increase traffic to the green environment gradually while paying great attention to its stability and performance.
3. Monitoring and Observability: Implement reliable monitoring and observability measures to keep tabs on the well-being and effectiveness of the green environment. This involves maintaining an eye on important metrics, configuring alarms for any anomalies or problems, and utilizing logging and tracing technologies for thorough visibility into the behavior of the program.

By following some of these steps, organizations can ensure a controlled and reliable deployment of the green pipeline.

How to Handle Simultaneous Deployment?

Handling simultaneous deployments using Jenkins and ensuring that we deploy the intended version can be achieved through a combination of blue green deployment in Kubernetes and pipeline queues. Below is a step-by-step approach to implementing this solution:

1. Ensure you have the latest code: Before making any changes, perform a git pull in your local repository to ensure you have the most recent version of the project.
2. Locate the Pipeline YAML files: In Jenkins, navigate to your project's repository, and find the Jenkinsfile at the root. Inside this folder, you will find the pipeline YAML files for various stages of your CI/CD process, such as "Deploy to Blue/Green", "Activate Blue/Green", and any other relevant pipelines.
3. Edit the pipeline YAML files: Open each of the pipeline YAML files in a text editor or the Jenkins pipeline editor.
4. Add the queue configuration: At the beginning of each pipeline file, add the following YAML snippet:

The above configuration sets up a queue named "shared Kubernetes deployment" with the organization scope. This ensures that pipelines belonging to this queue will run sequentially, preventing two deployments from happening simultaneously.

5. Save and commit the changes: After adding the queue configuration to all relevant pipeline files, save the changes and commit them to your version control system. This will trigger the CI/CD process in Jenkins.

Some additional Points that could be considered as per the requirements are Pipeline Triggers, Notifications and Monitoring, Automated Testing, Rollback Strategy, Versioning, and Release Notes. Now, when multiple developers or team members trigger deployments simultaneously, Jenkins will manage the queue and execute the deployments sequentially, one after the other, to avoid concurrency side effects.

Sanity Checks

The goal of these sanity checks is not to perform exhaustive testing of the entire application but rather to quickly identify any show-stopping issues that could negatively impact users. Once the sanity checks pass successfully, organizations or teams can proceed with the final step of directing production traffic to the Green environment, completing the Blue Green deployment kubernetes process. Here are some key sanity checks to perform during Blue Green deployment kubernetes are:

1. Health Check Endpoint: Implement a health check endpoint in your application that returns a status indicating whether the application is running correctly. The endpoint should respond with a success status code (e.g., 200 OK) when everything is operational.
2. Basic Functionality Tests: Conduct tests that cover the essential functions of your application. For example, if it's a web application, check if the main pages load without any errors, if the login process works, or if basic CRUD (Create, Read, Update, Delete) operations function as expected.
3. Database Connectivity: Ensure that the new version can connect to and interact with the required databases successfully.
4. Data Integrity Checks: If your application deals with data, verify that data integrity is maintained during the deployment process.
5. Security Checks: Check for common security vulnerabilities like SQL injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) in the new version.

Load Balancing Vs DNS Switching