Overview
Given the complexity of systems built using a microservices based architecture, deploying cloud native applications can be challenging. Several deployment strategies are at your disposal to perform this with confidence.
In this multi-part exercise, you will progressively test and experience various "deployment patterns" for Kubernetes workloads. You will learn about the suitability of the deployment patterns for specific scenarios.
What Will You Do¶
| Part | What will you do? |
|---|---|
| 1 | In this part, you will Configure and Setup an Environment to use GitOps to experience various deployment strategies/patterns on Kubernetes |
| 2 | In this part, you will use GitOps to test a "Recreate" Deployment Strategy |
| 3 | In this part, you will use GitOps to test a "Rolling Update" Deployment Strategy |
| 4 | In this part, you will use GitOps to test a "Blue-Green" Deployment Strategy |
| 5 | In this part, you will use GitOps to test a "Canary" Deployment Strategy |
Deployments in Kubernetes¶
A Deployment is a resource object in Kubernetes that defines the desired state for the application. Deployments are declarative, meaning that users do not have to specify how to achieve the state. Instead, users simply declare the desired state and allow the Deployment-controller to automatically reach that end goal in the most efficient way.
A deployment allows us to describe an application's life cycle, such as which images to use for the app, the number of pods there should be, and the way in which they should be updated.
The process of manually updating containerized applications can be time-consuming and tedious. A Kubernetes deployment makes this process automated and repeatable. Deployments are fully managed by the Kubernetes API server, and the whole update process is performed on the server side without client interaction. The Kubernetes deployment controller is also continuously monitoring the health of pods and nodes. It replaces a failed pod or bypass down nodes, ensuring continuity of critical applications.
Assumptions¶
This exercise assumes that you have access to the following:
- An Org with Org Admin privileges
- A provisioned or imported cluster in a project
- The cluster has access to a Load Balancer
- An account on GitHub for GitOps operations