Contents
Roadmap info from roadmap website
Deployments
A Deployment is a resource object for managing Pods and ReplicaSets via a declarative configuration, which define a desired state that describes the application workload life cycle, number of pods, deployment strategies, container images, and more. The Deployment Controller works to ensure the actual state matches desired state, such as by replacing a failed pod. Out of the box, Deployments support several deployment strategies, like “recreate” and “rolling update”, however can be customized to support more advanced deployment strategies such as blue/green or canary deployments.
Visit the following resources to learn more:
- @official@Deployments Documentation
- @video@Kubernetes Deployments | Deployment Strategies
- @article@Kubernetes Deployment: From Basic Strategies to Progressive Delivery
| Deployment | StatefulSet |
|---|---|
| Intended for stateless applications | Intended for stateful applications |
| Pods are interchangeable | Pods are unique and have a persistent ID |
| All replicas share the same volumes and PersistentVolumeClaims | Each pod has its own volumes and PersistentVolumeClaims |
Creating a deployment
flowchart TD
A[Deployment Specification File] --> B[Kubernetes Control Plane]
B --> C[Controller Created]
A --> D[Desired State]
C --> D
D --> E[Observed State]Key Terminology:
- Pods: The smallest deployable unit in Kubernetes, consisting of one or more containers that share resources.
- Deployments: A Kubernetes resource that describes the desired state of pods.
- Controllers: Continuously running processes that monitor and maintain the desired state of objects.
Deployment Process:
- A deployment specification file (in YAML format) is submitted to the Kubernetes control plane.
- The deployment controller creates a replica set, which instantiates and maintains a replica version of the pods specified in the deployment.
Deployment Object Details:
- API version
- Kind (deployment)
- Deployment name
- Number of pod replicas
- Pod template (metadata and specifications for each pod in the replica set)
- Container image
- Port to expose and accept traffic for the container
Deployment Lifecycle States:
- Processing: The deployment is creating a new replica set or scaling up/down.
- Complete: All new replicas are available and updated, with any old replicas not running.
- Failed: The creation of a new replica set could not be completed (e.g., due to image surfacing issues or lack of permissions).
Deployment Use Cases:
- Pod management tasks (updating, rolling back, scaling, auto-scaling)
- Stateless applications (API servers, websites without dynamic content)
Creating a Deployment:
-
Using a YAML file with the
Kube CTL applycommand -
Using the
Kube CTL create deploymentcommand (imperative method) - Creating a deployment through the Google Cloud Console
Updating deployment
Rolling Updates
A rolling update, also known as a ramped strategy, allows you to update a deployment without anyone noticing. When a deployment is updated, a new set of Pods are launched in a new replica set. Then after the new Pods start running smoothly, the old Pods in the outdated replica set are gracefully retired.
Configuring Rolling Updates
There are two primary parameters used to control the speed of rolling updates:
- maxSurge: specifies the maximum number of extra Pods that can be simultaneously running on the new version.
- maxUnavailable: specifies the maximum number of Pods that can be unavailable at the same time.
To explain this further, let’s work through an example of a rolling update:
Example
A deployment has a desired number of Pods set to 10 with the maxUnavailable parameter set to 10% and the maxSurge parameter set to five. The old replica set has 10 Pods.
The deployment will begin by creating five new Pods in a new replica set based on the maxSurge parameter.
When those new Pods are ready, the total number of Pods will change to 15. Since the maxUnavailable parameter is set to 10%, the minimum number of Pods that can run, regardless of whether they are from the old or new replica set, is 10 - 10%. This equals at least a minimum of nine Pods.
Therefore, six of the 15 Pods can be removed from the old replica set, leaving a minimum of nine, five in the new replica set, and four in the old replica set. Next, an additional five Pods will be launched on the new replica set, totaling 10 Pods in the new replica set and 14 in all replica sets.
Finally, the remaining four Pods in the old replica set will be deleted. The old replica set will be retained for rollback, even though it’s empty, and this will leave 10 Pods in the new replica set.
Flashcard
stateless applications::A stateless application does not store data or state in a cluster or persistent storage and can be scaled up or down as needed without impacting the application’s functionality.
maxSurge::MaxSurge specifies the maximum number of extra Pods that can be simultaneously running on the new version
MaxUnavailable::MaxUnavailable specifies the maximum number of Pods that can be unavailable at the same time.
Requests:: Requests determine the minimum amount of CPU and memory that a container will be allocated on a node
Limits::Limits can set the upper boundary of how much CPU and memory a container can use on a node