.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
CI/CD
言語
Articles
9/15/2021
10 minutes
Kubernetes Deployment Strategy Options: Which One to Use And When
.svg)
.svg)
Originally published by New Context.
As the use of containerized applications continues to rise, more organizations are turning to the Kubernetes container management architecture (or K8s) to automate their application scaling and management. One of the reasons Kubernetes has become such a valued tool for container orchestration is because of its automatic state maintenance abilities, which use resource objects known as deployments. There are several Kubernetes deployment strategy options to choose from depending on your particular needs, resources, and infrastructure.
In Kubernetes, a deployment is a resource object you use to define the desired end state of your program. The Kubernetes deployment controller will then automatically reach that end state in the most efficient way by comparing the current program state to the desired state and then automatically altering the state to match your end goal. There are six commonly used Kubernetes deployment strategies that we’ll discuss:
The recreate Kubernetes deployment strategy involves terminating all running instances of version A and then recreating them with version B. Your application will go down for the length of time it takes to shut down the old instances and start up the new ones. This deployment strategy is typically only used in development environments where downtime won’t affect any production users. The recreate method is best used when you need to run data migrations in between terminating your old code and starting your new code, or when your deployment doesn’t support running version A and version B of your application at the same time.
In a ramped deployment, your pods are updated in a rolling fashion, with new instances of your application replacing old instances one at a time. This is the default deployment method for Kubernetes, and is one of the safest and slowest strategies. A ramped deployment uses a readiness probe to make sure a new instance is ready before it deactivates an old instance, and if there is a problem during the deployment, it can be aborted without bringing the whole cluster down. A ramped Kubernetes deployment is recommended for stateful applications and in cases where you need to minimize the performance impact to your end users without paying for additional resources.
In a blue/green Kubernetes deployment strategy, both your old version (blue) and new version (green) are deployed at the same time, with a Kubernetes service object that acts as a load balancer sending end-user traffic to blue instances and QA and developer traffic to green instances. This allows you to live test the new version of your application without impacting your users. Once your testing is complete, you update the load balancer to send user traffic to the green version of your application. A blue/green deployment strategy works well for avoiding API versioning issues because you’re changing the entire cluster state in one go, but as you need to double your cloud resources to run both versions at the same time, it can be very expensive.
A canary deployment involves routing a subset of your users to updated instances of your application while the rest continue using the older versions. This type of deployment can be managed with just Kubernetes using ReplicaSet to spin up as many new instances as necessary to get the right percentage of traffic—e.g. If you normally run 100 instances and you want to send 5% of user traffic to version B of your application, you would have five instances running version B and 95 instances running version A. This type of setup can be pretty complicated to manage though, so many organizations employ a load balancer (such as HAProxy) or service mesh (like LInkerd or Istio) to help control traffic. A canary deployment works best when you need real traffic testing of your new versions and have the resources to manage the complex setup.
As it relates to Kubernetes, A/B testing refers to a type of canary deployment involving distributing traffic to different versions of an application based on specific parameters. Whereas a typical canary deployment will route users based on traffic weight, A/B testing allows you to target specific users based on a cookie, user agent, or another method of identification. One of the primary applications of this Kubernetes deployment is to test the conversion of a feature and then only roll out the version that successfully converts the most users. Like other types of canary deployments, A/B testing deployments are very complex and generally require service meshes to provide fine-grain control over traffic distribution.
Shadow is another subset of canary deployments that allows you to test the production load on a new version. A shadow deployment involves releasing version B alongside version A and sending traffic to both at the same time, without the end users noticing any difference. Once the stability and performance of the new version meet your defined requirements, a full rollout is triggered. A shadow deployment works best when your primary concern is the performance load on your production applications, but it is just as complex as other canary deployments, and can be even more expensive because you need to run double the resources.
Every deployment option comes with its own pros and cons to consider. Here is a breakdown of some of the key strengths and weaknesses of each strateg
Ultimately, when choosing a Kubernetes deployment strategy, you’ll need to analyze your resources, goals, and unique requirements to ensure you make the right decision for your organization. Kubernetes is notoriously difficult to learn, and you need a complete understanding of your applications and cloud container architecture to use it effectively. If your team doesn’t have experience with Kubernetes or other container management solutions, or if your project is too large and complex to handle on your own, you should seek out a development partner to aid in your K8s deployment.
.svg)
.svg)
.svg)