Kubernetes Deployment

The default strategy that incrementally replaces old Pods with new ones. It ensures application availability by maintaining a minimum number of Pods (minReadySeconds) and limiting the surge of new Pods (maxSurge) during the update.

• Key Parameters: maxUnavailable (how many can be down), maxSurge (how many extra can be created).
• Use Case: The standard choice for stateless applications where a gradual, controlled rollout is acceptable.

A strategy that terminates all existing Pods before creating new ones. This results in a brief period of downtime as the old version is completely shut down before the new version starts.

• Behavior: All old Pods are killed simultaneously; new Pods are created only after termination is complete.
• Use Case: Necessary for applications that cannot run two versions concurrently, often due to database schema changes or incompatible configurations.

A pattern (not a native Kubernetes strategy) that involves maintaining two identical environments: Blue (current live version) and Green (new version). Traffic is switched entirely from one environment to the other in a single operation.

• Implementation: Uses a Service selector to switch traffic between two complete Deployments.
• Advantage: Enables instant rollback by switching the Service selector back to the old Deployment.

A pattern for gradually exposing a new version to a subset of users before a full rollout. It mitigates risk by testing in production with limited traffic.

• Implementation: Can be achieved using multiple Deployments with careful Pod labeling and Service selectors, or more robustly with a service mesh (e.g., Istio) for fine-grained traffic splitting.
• Process: Start by routing 5% of traffic to the new version, monitor metrics, then gradually increase.

The two critical parameters that define the pace and safety of a RollingUpdate.

• maxUnavailable: Specifies the maximum number of Pods that can be unavailable during the update. Can be an absolute number (e.g., 1) or a percentage (e.g., 25%). Default is 25%.
• maxSurge: Specifies the maximum number of Pods that can be created over the desired number of Pods. This allows the rollout to proceed faster. Default is 25%.

Tuning these values balances rollout speed against resource usage and availability.

The process of reverting a Deployment to a previous, known-good revision. Kubernetes maintains a revision history of each Deployment, enabling quick rollbacks.

• Command: kubectl rollout undo deployment/<deployment-name>
• Mechanism: The rollback is itself a RollingUpdate, applying the previous Pod template.
• Revision History: Controlled by the revisionHistoryLimit field, which defaults to 10 revisions.

Commands to instantiate and update a Deployment from a manifest file.

• kubectl apply -f deployment.yaml: Creates or updates a Deployment to match the declared state in the YAML file.
• kubectl create deployment nginx --image=nginx: Imperatively creates a Deployment named nginx using the NGINX container image.
• kubectl rollout status deployment/<name>: Monitors the progress of a newly created or updated Deployment.

Commands to view the current state and configuration of a Deployment.

• kubectl get deployments: Lists all Deployments in the current namespace, showing desired/current/up-to-date/available replica counts.
• kubectl describe deployment/<name>: Provides detailed information, including events, selector, replicas, and Pod template.
• kubectl get pods -l app=<label>: Lists the Pods managed by the Deployment using its selector labels.

Commands to modify the number of replicas and manage rolling updates.

• kubectl scale deployment/<name> --replicas=5: Scales the Deployment to run 5 Pod replicas.
• kubectl set image deployment/<name> nginx=nginx:1.21: Triggers a rolling update by changing the container image for the nginx container.
• kubectl rollout history deployment/<name>: Shows the revision history of the Deployment.

Commands to manage failed updates and restore previous states.

• kubectl rollout undo deployment/<name>: Rolls back to the previous revision.
• kubectl rollout undo deployment/<name> --to-revision=2: Rolls back to a specific historical revision.
• kubectl rollout pause/resume deployment/<name>: Pauses or resumes an ongoing rollout for canary testing.

Commands to remove a Deployment and its managed resources.

• kubectl delete deployment/<name>: Deletes the specified Deployment. By default, this also deletes all its managed Pods (cascading delete).
• kubectl delete -f deployment.yaml: Deletes resources defined in the manifest file.
• kubectl delete deployment <name> --cascade=orphan: Deletes the Deployment object but leaves its Pods running (not managed).

Key objects and mechanisms that interact with Deployments.

• ReplicaSet: The underlying controller that ensures the specified number of Pod replicas are running. A Deployment manages ReplicaSets.
• RollingUpdate Strategy: The default update strategy that replaces Pods incrementally.
• Readiness & Liveness Probes: Health checks defined in the Pod spec that influence rollout success and Pod availability.
• Horizontal Pod Autoscaler (HPA): An autoscaling API object that can automatically scale a Deployment based on observed CPU utilization or other metrics.

The smallest and simplest Kubernetes object. A Pod represents a single instance of a running process in your cluster and can contain one or more tightly coupled containers. It is the fundamental unit of deployment that a Deployment manages and scales.

• Encapsulates application containers, storage, and a unique network IP.
• Ephemeral by nature; Deployments ensure a specified number of Pod replicas are always running.

A ReplicaSet is a lower-level controller that ensures a specified number of identical Pod replicas are running at any given time. A Deployment manages Pods by creating and managing ReplicaSets.

• Provides the core scaling and self-healing mechanism for Pods.
• Deployments enable declarative updates by creating new ReplicaSets and managing the transition between them.

A Kubernetes Service is an abstraction that defines a logical set of Pods and a policy to access them. It provides a stable network endpoint (IP address and DNS name) for Pods managed by a Deployment, which are ephemeral.

• Enables load balancing across Pod replicas.
• Decouples the front-end from the back-end Pods, allowing them to be scaled or updated without disrupting service discovery.

ConfigMaps and Secrets are API objects used to inject configuration data and sensitive information into Pods. A Deployment's Pod template can reference these objects to separate configuration from application code.

• ConfigMap: Stores non-confidential configuration data as key-value pairs.
• Secret: Holds sensitive data like passwords or tokens, stored encoded or encrypted.
• Using them allows for easy, centralized updates to configuration without rebuilding container images.

The default update strategy for a Kubernetes Deployment. It incrementally updates Pod instances with new ones, ensuring zero-downtime deployments.

• The Deployment creates a new ReplicaSet with the updated Pod template.
• Gradually scales down the old ReplicaSet while scaling up the new one.
• Allows for rollback to a previous version if the update fails.

The Horizontal Pod Autoscaler automatically scales the number of Pods in a Deployment (or ReplicaSet) based on observed CPU utilization or other custom metrics.

• Works by adjusting the replicas field in the Deployment's spec.
• Ensures applications can handle increased load and scale down to reduce resource consumption during lulls.
• A key component for building cost-efficient, responsive applications.