Application lifecycle management is one critical aspect of container orchestration that requires special attention particularly with rising workload and cluster complexities. When deploying a Kubernetes application into production, there are several strategies to stage and update cluster resources. The right strategy allows seamless updates to the application workload, without impacting service availability.
This article delves into deployment strategies for managing the lifecycle of Kubernetes applications, and why rolling update deployments act as the most preferred deployment strategy by allowing seamless updates without impacting application availability.
Kubernetes deployment strategies
Kubernetes uses replication through ReplicaSets to ensure high-availability by deploying as many instances of the workload pods as desired to maintain optimum performance. While doing so, ReplicaSets are used as intelligent agents that help run multiple instances of the same pod in a cluster. Kubernetes deployment strategies leverage such ReplicaSets to maintain the optimum number of operational pods as well as load-balancing to spin up new pods when existing ones fail.
While there are a number of other strategies, the Recreate and Rolling Update deployment strategies are the most popular ones used to stage and update Kubernetes cluster resources.
- The Recreate deployment strategy is the simplest form of Kubernetes deployment that terminates all active pod instances, and then spins up new pod versions afresh. Though this strategy remains a popular choice for completely renewing the app state, it is often not recommended for application architectures that need to maintain a consistent steady-state.
- A Rolling Update, on the other hand, gradually replaces pod instances with newer versions to ensure there are enough new pods to maintain the availability threshold before terminating old pods. Such a phased replacement ensures there is always a minimum number of available pods that enable a safe rollout of updates without causing any downtime.
Deployments in Kubernetes create new ReplicaSets for rollbacks, updates, spinning up replicas, or for any other configuration changes. Kubernetes assumes rolling updates as the default deployment strategy by incrementally replacing POD instances without affecting downtime.
Let us learn more on how this works by configuring a Rolling Update Deployment.
Configuring a rolling update deployment
Deployments in Kubernetes are created by defining their specifications in a YAML definition file. To understand how a rolling update deployment is configured, let us take the reference of a deployment named deployment-definition with the following specifications:
The above specification highlights a Deployment manifest that creates a new container while downloading the image. In order to ensure that Kubernetes updates the above configuration without impacting application availability, we can use the RollingUpdate deployment by additionally including the following under spec:
To update a deployment configuration, make changes to the deployment file by using the following command:
$ kubectl apply -f deployment-definition.yml
By defining the above parameters within the deployment-definition specification, the updated YAML would be similar to this:
To learn this well, let us understand the different parameter functions -
- maxUnavailable - specifies the maximum number of unavailable pods during an update. Optional, and can be specified through a percentage or an absolute number.
- maxSurge - specifies the maximum number of pods to be created beyond the desired state during the upgrade. Optional, and can be specified through a percentage or an absolute number.
- timeoutSeconds - the time (in seconds) that waits for the rolling event to timeout. On reaching the specified time, it automatically rolls back to the previous deployment. Optional, if left blank, the default value is assumed to be 600 seconds.
- intervalSeconds - specifies the time gap in seconds after an update. Optional, if left blank, the default value is assumed to be 1 second.
- updatePeriodSeconds - time to wait between individual pods migrations or updates. Optional, if left blank, the default value is assumed to be 1 second.
As per the specified values, the deployment will continue to run until it reaches the desired state, following which old pods can be terminated or retained, as required - thereby, maintaining zero downtime.
Rolling updates - post-configuration operations
Once the deployment specification is setup, Kubernetes takes use of the kubectl command for follow-up steps:
To replace the existing image with darwin/rss-php-nginx:v1 version, you can use the command:
$ kubectl set image deployment/deployment-definition front-end=darwin/rss-php-nginx:v1 --record
Once the deployment YAML is configured, the deployment is then launched by running the command:
$ kubectl create -f deployment-definition.yml
To display the list of running deployments:
$ kubectl get deployments
To update a deployment, make changes to the deployment file by using the kubectl apply command:
$ kubectl apply -f deployment-definition.yml
Additional changes by changing resources can also be done using the kubectl set command:
In case there are ongoing deployments, check the status of the rollout:
$ kubectl rollout status deployment/deployment-definition
To display the history of rollouts:
$ kubectl rollout history deployment/deployment-definition
In case of a deployment update doesn’t work as expected, one can roll back changes by using the command:
$ kubectl rollout undo deployment/deployment-definition
Benefits of rolling updates
Rolling updates allow changes to be integrated gradually, offering flexibility and control within an application lifecycle. Some benefits of using rolling updates for Kubernetes clusters include:
- Ensures zero downtime since pod instances of the application are always running even during an upgrade
- Allows developers to examine the effect of the changes in a production environment without affecting user experience
- Does not require additional resources assigned to the cluster, making it a cost-effective deployment strategy
- Avoids the requirement of strenuous manual migration of configuration files, where complex upgrades can be achieved efficiently by making simple changes to a deployment file.
Closing thoughts
One advantage of a cloud-native environment is its support of a microservice approach, which allows multiple developers to make changes simultaneously. While this is a good thing, frequent releases can easily affect application reliability and uptime. DevOps teams must therefore come up with mechanisms for managing deployment in a manner that minimizes risk to the app lifecycle. More so, complex workloads require the right methodologies for sustained operational efficiency and application resilience.
To help with this, Kubernetes allows the provisioning of seamless deployments through rolling updates for controlled upgrades without impacting uptimes. Due to its apparent benefits of maintaining efficient automation and parallelism, using rolling updates for deployments is often considered one of the essential best practices of a DevOps model.
If you're looking for an internal tooling platform that complements your Kubernetes deployments and helps manage your applications, then Airplane is a good solution for you. With Airplane, you can transform scripts, queries, APIs, and more into custom internal workflows and UIs. Airplane is maintenance-free and provides strong built-ins, such as audit logs, permissions setting, job scheduling, and more. Airplane's engineering workflows solution helps you streamline building internal tools for your most important engineering use cases, including deployment pipelines.
To try it out, sign up for a free account or book a demo and build your first internal tool quickly and efficiently.
