Forem: Naveen Jayachandran

Kubernetes – Creating a ReplicaSet

Naveen Jayachandran — Mon, 03 Nov 2025 17:29:11 +0000

A ReplicaSet is a core Kubernetes controller designed to ensure that a specified number of identical Pods, called replicas, are running at all times. It serves as a self-healing mechanism — if any Pod fails, crashes, or is accidentally deleted, the ReplicaSet automatically creates a replacement to maintain the desired count. This guarantees high availability, scalability, and reliability for applications running in Kubernetes.

Purpose of a ReplicaSet
The main objectives of a ReplicaSet are to maintain application stability, availability, and scalability.

High Availability: A ReplicaSet maintains a consistent number of running Pods. Even if a node or Pod fails, others remain available to serve traffic, ensuring zero downtime.

Load Balancing: When used with a Kubernetes Service, a ReplicaSet distributes traffic evenly across all its Pods. As replicas scale up or down, the Service dynamically adjusts to maintain balanced traffic distribution.

Scalability: You can easily adjust the number of replicas by modifying the replicas field in the ReplicaSet specification. The controller automatically creates or removes Pods to match the updated count.

How ReplicaSets Improved Over Replication Controllers
ReplicaSets are the modern replacement for the older Replication Controller. The key improvement lies in label selectors:

Replication Controller: Uses equality-based selectors, matching Pods with exact key-value label pairs (e.g., app: frontend). This is quite restrictive.

ReplicaSet: Uses set-based selectors, allowing more expressive selection logic. For example, it can select Pods where a label value exists or belongs to a specific set of values. Example:matchExpressions: - key: environment operator: In values: - production - qa This allows a ReplicaSet to manage Pods with labels environment=production or environment=qa.

Example: ReplicaSet Manifest
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-replicaset
spec:
replicas: 2
selector:
matchLabels:
app: nginx-rs-pod
matchExpressions:
- key: env
operator: In
values:
- dev
template:
metadata:
labels:
app: nginx-rs-pod
env: dev
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
Non-Template Pod Acquisition
A ReplicaSet can also adopt existing Pods that match its selectors, even if it didn’t originally create them. This process is called non-template Pod acquisition.

Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: first-replicaset
spec:
selector:
matchLabels:
app: web-app
replicas: 5
Any Pod with the label app: web-app will be managed by this ReplicaSet.

Working with ReplicaSets
Step 1: Create the YAML File
Define your ReplicaSet with desired configurations such as the number of replicas, labels, and container specifications.

Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-app:latest
ports:
- containerPort: 80
Step 2: Create the ReplicaSet
kubectl create -f replicaset.yaml
Step 3: Verify Creation
kubectl get replicasets
Step 4: View Details
kubectl describe replicaset my-replicaset
Deleting ReplicaSets and Pods
Delete a ReplicaSet
kubectl delete rs
This removes the ReplicaSet and all managed Pods.

Delete Pods Independently
kubectl delete pods --selector
You can delete specific Pods without deleting the ReplicaSet. The ReplicaSet will recreate them to maintain the replica count.

Isolating Pods from a ReplicaSet
To exclude a Pod from ReplicaSet management, change its label so it no longer matches the ReplicaSet’s selector.

Steps:

List Pods:kubectl get pods

Edit Pod labels:kubectl edit pod

Apply the updated Pod configuration:kubectl apply -f .yaml

Scaling a ReplicaSet

Manual Scaling You can scale a ReplicaSet manually using:

kubectl scale rs --replicas=5

Automatic Scaling with HPA You can attach a Horizontal Pod Autoscaler (HPA) to automatically adjust replicas based on metrics like CPU utilization.

Example:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: mavenwebapprc
namespace: test-ns
spec:
replicas: 2
selector:
matchLabels:
app: mavenwebapp
template:
metadata:
labels:
app: mavenwebapp
spec:
containers:
- name: mavenwebapp
image: dockerhandson/maven-web-application:1
ports:
- containerPort: 8080
metrics:

type: Resource resource: name: cpu targetAverageUtilization: 80 When CPU utilization reaches 80%, the HPA scales the replicas up to the configured maximum limit (for example, four Pods).

Difference Between ReplicaSet and ReplicationController
Feature ReplicaSet ReplicationController
Purpose Modern controller ensuring desired number of Pods are running Older mechanism managing Pod lifecycles
Selector Type Supports set-based selectors Supports only equality-based selectors
Flexibility More expressive and powerful matching logic Limited matching capabilities
Status Successor to ReplicationController Deprecated for most use cases
Difference Between ReplicaSet and DaemonSet
Feature ReplicaSet DaemonSet
Pod Distribution Ensures a fixed number of Pods run across the cluster Ensures one Pod runs on each node
Use Case Best for stateless applications like web servers Ideal for stateful or system-level apps like log collectors or monitoring agents
Pod Replacement Recreates a Pod when one is deleted Automatically deploys a Pod to every new node in the cluster
Scaling Manually or automatically scaled One Pod per node by design
Summary
A ReplicaSet is the foundation of Kubernetes scalability and reliability. It ensures your applications stay highly available by maintaining the right number of Pods. While Deployments are typically used to manage ReplicaSets (for rolling updates and version control), understanding ReplicaSets helps you grasp how Kubernetes ensures continuous and consistent application availability.

Kubernetes Deployment

Naveen Jayachandran — Mon, 03 Nov 2025 17:28:04 +0000

A Kubernetes Deployment is a higher-level abstraction used to manage and scale containerized applications while ensuring they remain in the desired operational state. It provides a declarative way to specify how many Pods should run, which container images they should use, and how updates or rollbacks should occur — all without downtime.

Key Capabilities of a Deployment
With a Deployment, you can:

Scale applications dynamically based on workload.

Maintain availability by ensuring the specified number of Pods are always healthy and running.

Perform rolling updates to deploy new versions seamlessly.

Rollback easily if a deployment introduces issues.

Automate self-healing, ensuring that failed Pods are recreated automatically.

Think of a Deployment as both a blueprint and a controller for Pods — it simplifies and automates most aspects of application lifecycle management in Kubernetes.

Common Use Cases
Kubernetes Deployments are widely used for managing application lifecycles. Common scenarios include:

Rolling out new applications: Create a Deployment that launches a ReplicaSet, which in turn provisions Pods. You can monitor rollout progress using deployment status commands.

Seamless application updates: Modify the PodTemplateSpec to trigger a new ReplicaSet. The Deployment automatically scales up the new version while gradually scaling down the old one — ensuring zero downtime.

Rollback to previous versions: If an update introduces instability, roll back to an earlier revision easily.

Dynamic scaling: Adjust the replica count manually or automatically using autoscalers to handle traffic fluctuations.

Pausing and resuming rollouts: Pause a rollout to batch multiple updates together and resume when ready.

Monitoring rollout progress: Check rollout status to confirm whether updates are progressing smoothly or stuck.

Resource cleanup: Automatically remove obsolete ReplicaSets to maintain cluster efficiency.

Core Components of a Deployment
A Kubernetes Deployment consists of three key parts:

Metadata: Includes the name and labels. Labels establish relationships between Deployments, ReplicaSets, and Services.

Specification (spec): Defines:

Number of replicas (Pods)

Selector labels

Pod template (template) The Pod template includes container specifications such as:

Container name

Image to use

Ports to expose

Resource limits (CPU, memory)

Status: Automatically maintained by Kubernetes. It reflects the current state of the Deployment and enables self-healing. If the actual and desired states differ, Kubernetes reconciles them automatically.

Example: Nginx Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80
Commands:

Create the Deployment

kubectl apply -f nginx.yaml

Check status

kubectl get all
This will successfully create and deploy an Nginx application on your cluster.

Updating a Deployment
You can update Deployments in two main ways:

Method 1: Edit Using kubectl
kubectl edit deployment
This opens the configuration in your terminal. Make the changes (press i to insert), then save and exit (Esc + :wq).

Method 2: Update the YAML File
Edit the YAML file directly (e.g., change container port from 80 to 8000), and reapply:

kubectl apply -f nginx.yaml
Rolling Back a Deployment
If an update causes problems, you can easily revert to a previous version.

Steps:
List all revisions:kubectl rollout history deployment

Rollback to a previous revision:kubectl rollout undo deployment/nginx-deployment --to-revision=1

Validate: Always test your rollback strategy to ensure minimal downtime during real incidents.

Viewing Rollout History
kubectl rollout history deployment/
To view details for a specific revision:

kubectl rollout history deployment/web-app-deployment --revision=3
This helps track configuration changes and revert if needed.

Scaling a Deployment
You can scale Deployments manually or automatically:

Manual Scaling:
kubectl scale deployment/tomcat-deployment --replicas=5
Autoscaling:
kubectl autoscale deployment/tomcat-deployment --min=5 --max=8 --cpu-percent=75
Here:

--min=5: Minimum Pods always running

--max=8: Maximum Pods during high load

--cpu-percent=75: Scaling threshold based on CPU usage

Pausing and Resuming a Rollout
Pause a rollout:
kubectl rollout pause deployment/webapp-deployment
Resume the rollout:
kubectl rollout resume deployment/webapp-deployment
You can also update the container image during a paused rollout:

kubectl set image deployment/webapp-deployment webapp=webapp:2.1
Deployment Status Phases
Kubernetes reports various statuses for a Deployment:

Status Description
Pending Deployment is initializing or waiting for resources.
Progressing Deployment is rolling out changes or creating ReplicaSets.
Succeeded Deployment completed successfully.
Failed Deployment failed due to configuration or environment errors.
Unknown API server cannot determine status or connection lost.
Check rollout progress:

kubectl rollout status deployment/
Common Deployment Failures and Causes
Failure Reason Description
Failed probes Readiness or liveness probe misconfigured.
Image pull errors Incorrect image name or tag.
Insufficient resources Resource quota limits exceeded.
Dependency issues Service dependencies (like databases) unavailable.
For detailed debugging:

kubectl describe deployment
Canary Deployments
A Canary Deployment gradually introduces new versions of an application to a subset of users or Pods, allowing testing under real workloads before a full rollout.

Example Approach:
Deploy a new version to 50% of Pods while the rest continue serving the old version.

Based on feedback or monitoring results, either:

Roll out to all Pods, or

Roll back to the stable version.

Implementation Methods:

Traffic Splitting using Istio or other service mesh tools.

Blue-Green Deployment – maintain two environments (old and new) and switch traffic when ready.

ReplicaSet vs Deployment
ReplicaSet Deployment
Ensures the specified number of Pods are running. Manages ReplicaSets and automates Pod lifecycle.
Does not support rolling updates or rollbacks. Supports both rolling updates and rollbacks.
Handles Pods directly. Handles ReplicaSets, which in turn manage Pods.
Suitable for simple, static workloads. Suitable for dynamic, frequently updated applications.
Summary
A Kubernetes Deployment simplifies managing applications by handling updates, scaling, rollbacks, and self-healing automatically. It abstracts away the complexity of direct Pod or ReplicaSet management, enabling you to define your application’s desired state and letting Kubernetes maintain it efficiently.

Kubernetes – Difference Between ReplicaSet and Replication Controller

Naveen Jayachandran — Mon, 03 Nov 2025 17:26:57 +0000

Overview
Kubernetes (K8s) is an open-source container orchestration platform initially developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF). It automates the deployment, scaling, and management of containerized applications.

Kubernetes is available in two major forms:

Kubernetes: The full-fledged version used in production environments.

Minikube: A lightweight local version used for development and testing.

Replication in Kubernetes
Replication ensures that multiple instances of an application (Pods) are running simultaneously to maintain high availability, load balancing, and scalability.

Key benefits of replication include:

Reliability: Prevents downtime by maintaining a desired number of Pods.

Load Balancing: Distributes traffic evenly among available Pods.

Auto Scaling: Dynamically adjusts the number of Pods based on workload.

Replication is especially useful in microservices architectures, cloud-native applications, and mobile backend systems.

Replication Controller (RC)
The Replication Controller is the original mechanism in Kubernetes for ensuring that a specified number of Pod replicas are running at all times. Although it has now been largely replaced by ReplicaSets, it’s still valuable to understand how it works.

A Replication Controller continuously monitors its Pods and automatically replaces any that fail or get deleted. It can also scale Pods up or down and supports bulk operations like updates or deletions.

Key characteristics:

API Version: v1

Kind: ReplicationController

Defines:

A name

A replica count

A Pod template (similar to a standalone Pod definition)

The selector field (optional) determines which Pods are managed. If omitted, it defaults to the Pod template’s labels.

ReplicaSet (RS)
The ReplicaSet is the next-generation controller that supersedes the Replication Controller. It serves the same purpose—maintaining the desired number of Pods—but provides enhanced selector capabilities and is typically managed by Deployments for versioned rollouts.

Key characteristics:

API Version: apps/v1

Kind: ReplicaSet

Requires:

A name

A replica count

A selector (mandatory)

A Pod template

The selector can use both:

Match Labels: Basic equality checks.

Match Expressions: Complex logical conditions (e.g., In, NotIn, Exists, DoesNotExist).

Example use cases include maintaining web servers or API Pods with specific label criteria.

Replication Controller vs. ReplicaSet
Feature Replication Controller (RC) ReplicaSet (RS)
Definition The original replication mechanism in Kubernetes. The modern replacement that extends RC functionality.
API Version v1 apps/v1
Selector Type Supports equality-based selectors only. Supports set-based selectors (matchLabels, matchExpressions).
Rolling Updates Supports the rolling-update command. Does not support the rolling-update command directly.
Replacement Status Deprecated in favor of ReplicaSets. Recommended for use, often managed via Deployments.
Usage Recommendation Legacy workloads only. Use Deployments (which internally manage ReplicaSets).
Summary
While both Replication Controller and ReplicaSet ensure Pod availability, ReplicaSets provide more flexibility, richer selector options, and better integration with modern Kubernetes workflows.

In current Kubernetes best practices:

Avoid using Replication Controllers.

Use Deployments, which manage ReplicaSets automatically and add capabilities like rolling updates and rollbacks.

Kubernetes – Replication Controller

Naveen Jayachandran — Mon, 03 Nov 2025 17:26:05 +0000

A Replication Controller (RC) in Kubernetes is a core component responsible for ensuring that a specified number of Pod replicas are running at all times. Similar to a ReplicaSet, its primary function is to maintain the desired number of identical Pods — automatically creating or terminating them as necessary. This ensures high availability, fault tolerance, and scalability within a Kubernetes cluster.

Core Responsibilities of a Replication Controller
Ensuring Availability If a Pod managed by an RC fails, is deleted, or the node hosting it crashes, the RC will automatically create a new Pod to replace it, maintaining the desired replica count.

Scaling The number of running Pods can be increased or decreased simply by updating the replicas field in the RC’s configuration.

Load Balancing When used with a Kubernetes Service, the RC ensures that traffic is evenly distributed across all active Pods, promoting efficient resource utilization.

Example: Running a Replication Controller
Step 1: Create the Definition File
Create a file named rc-definition.yaml with the following content:

apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
spec:
replicas: 3
selector:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
Explanation of the Manifest
apiVersion: v1 – Indicates that the Replication Controller belongs to the core Kubernetes API group.

kind: ReplicationController – Specifies the type of Kubernetes resource.

metadata.name – Defines the name of the Replication Controller (myapp-rc).

spec.replicas: 3 – Sets the desired number of running Pods.

spec.selector – Uses equality-based selectors to manage Pods labeled app: myapp.

spec.template – Describes the Pod template used to create new replicas; the labels here must match the selector.

Step 2: Create the Replication Controller
kubectl apply -f rc-definition.yaml
Step 3: Verify Creation
kubectl get rc myapp-rc
Example Output:

NAME DESIRED CURRENT READY AGE
myapp-rc 3 3 3 15s

kubectl get pods
Example Output:

NAME READY STATUS RESTARTS AGE
myapp-rc-5j2x7 1/1 Running 0 25s
myapp-rc-8b9vj 1/1 Running 0 25s
myapp-rc-h4wz8 1/1 Running 0 25s
Step 4: Test Self-Healing
Delete one of the Pods and watch Kubernetes recreate it automatically:

kubectl delete pod
Step 5: Scale the Replicas
To increase the number of replicas:

kubectl scale rc myapp-rc --replicas=5
Step 6: Clean Up
When done, delete the Replication Controller and its Pods:

kubectl delete rc myapp-rc
Labels in a Replication Controller
Labels are key-value pairs attached to Kubernetes resources. In Replication Controllers, labels play an essential role in identifying, organizing, and grouping Pods. They allow administrators to control Pod scheduling and management efficiently.

Example:

selector:
app: nginx
You can also use multiple labels in a selector, separated by commas:

selector:
app: webapp
tier: frontend
Pod Selector
A Pod selector matches Pods based on their labels. It works on equality-based or set-based expressions and is used across various Kubernetes objects such as:

ReplicationControllers

ReplicaSets

Deployments

DaemonSets

This mechanism allows controllers to monitor and manage specific groups of Pods dynamically.

Responsibilities of a Replication Controller
Ensures that the number of running Pods always matches the desired count.

Creates new Pods if the running count falls short of the desired replicas.

Deletes excess Pods if more than the desired count are running.

Monitors Pod health continuously and replaces any failed Pods automatically.

Guarantees that the application remains available and resilient against failures.

Replication Controller vs ReplicaSet
Feature Replication Controller ReplicaSet
Purpose Ensures the desired number of Pods are running. Same purpose, but a more advanced and flexible controller.
Selector Type Supports equality-based selectors only. Supports set-based selectors (more expressive).
Pod Association Uses labels to associate Pods. Uses label selectors to associate Pods.
Generation Original replication mechanism in Kubernetes. Next-generation replacement for ReplicationController.
Usage Recommendation Deprecated in favor of ReplicaSets and Deployments. Preferred for modern Kubernetes deployments.
Summary
The Replication Controller is one of the earliest mechanisms in Kubernetes for ensuring application availability and scaling. It continuously monitors and maintains the desired number of Pods, providing self-healing, scalability, and load distribution.
However, in modern Kubernetes deployments, ReplicaSets (often managed by Deployments) have largely replaced Replication Controllers, offering greater flexibility and advanced selector capabilities.

Mastering Kubernetes Deployment Strategies: The Real-World Guide for DevOps, Cloud, and SRE Engineers

Naveen Jayachandran — Mon, 03 Nov 2025 17:25:19 +0000

In today’s rapidly evolving DevOps landscape, Kubernetes has become the engine powering modern, scalable infrastructure. Whether you’re preparing for a DevOps, Cloud Engineer, or SRE interview, or managing large-scale systems in production, understanding Kubernetes deployment strategies is a must-have skill.

Because here’s the truth:
In production environments, simply replacing containers is a recipe for disaster. It can trigger service downtime, bug exposure, or even complete outages — all of which can damage customer trust and brand reputation.

That’s why seasoned engineers rely on well-defined deployment strategies — controlled, testable, and reversible methods to roll out new versions safely.

Why Deployment Strategies Matter
A deployment strategy defines how new application versions are released and how they interact with existing versions during the rollout. In DevOps and Kubernetes contexts, the right deployment approach ensures:

🔹 Minimal downtime and consistent user experience

🔹 Safe feature validation before full rollout

🔹 Quick rollback mechanisms in case of production failures

🔹 Controlled experimentation using real-world traffic

🔹 Confidence in automated delivery pipelines

Essentially, these strategies form the safety net between innovation and reliability — enabling continuous delivery without compromising stability.

The Six Key Kubernetes Deployment Strategies
In this detailed guide, we’ll dive into six production-grade deployment strategies every DevOps engineer must know, along with their real-world trade-offs, use cases, and scenario-based interview examples that will help you stand out.

Canary Deployment – The "Gradual Rollout" What It Is The Canary deployment introduces a new version (V2) to a small subset of users while the majority continue using the stable version (V1). If metrics, logs, and monitoring results show healthy behavior, traffic to the new version is gradually increased until full rollout.

When to Use It
Introducing new or risky features

Deploying critical infrastructure changes

Wanting to validate performance in live production

Pros
Limits user impact if something fails

Enables real-world A/B validation

Integrates well with metrics-driven automation

Cons
Requires traffic routing control (e.g., Istio, NGINX, or service mesh)

Complex configuration for progressive rollout

Real-World Example
Imagine an e-commerce platform releasing a new ML-based recommendation engine. Instead of exposing it to all users, the company deploys it to 5% of traffic. Observability tools (Prometheus, Grafana) monitor accuracy, response time, and user conversions before a full rollout.

Interview Scenario
Answer:
I’d implement a Canary deployment, routing a small percentage of live traffic to the new model (V2) while most users continue with V1. Using metrics and logging (via Prometheus and Grafana), I’d assess performance. If stable, I’d gradually increase traffic until full adoption. This approach ensures minimal risk and easy rollback.

Blue-Green Deployment – The "Big Switch" What It Is In Blue-Green deployments, two environments exist simultaneously:

Blue: The live (current) production environment.

Green: The new version waiting to go live.

Once testing confirms the new version’s stability, traffic is switched entirely from Blue to Green.

When to Use It
When zero downtime is mandatory

For major version upgrades or high-visibility releases

In environments that support dual infrastructure

Pros
Instant rollback by reverting traffic to Blue

Clear separation between environments

Simple release management

Cons
Doubles resource requirements temporarily

Needs traffic management control (e.g., load balancers)

Real-World Example
A fintech platform scheduled a midnight rollout for a regulatory compliance update. By deploying the new version in the Green environment ahead of time and switching the load balancer during the maintenance window, they ensured a zero-downtime launch.

Interview Scenario
Answer:
I’d use a Blue-Green deployment. I’d deploy the new version in a parallel Green environment, perform pre-release testing, and switch traffic via the load balancer at launch time. If issues appear, I’d revert to the Blue version immediately, ensuring uninterrupted service.

A/B Testing Deployment – The "Data-Driven Experiment" What It Is Unlike Canary deployments (which focus on performance validation), A/B testing routes user segments to different application versions based on user attributes (e.g., location, device, or random assignment). It’s primarily a product and UX strategy rather than purely operational.

When to Use It
For UI/UX experiments

To validate feature effectiveness

When data-driven decision-making is required

Pros
Enables measurable user behavior comparisons

Supports data-backed feature promotion

Cons
Requires analytics and telemetry setup

More complex traffic segmentation

Not ideal for backend-only updates

Real-World Example
A streaming platform tests two versions of its recommendation UI: one showing horizontal carousels, another using vertical lists. Traffic is split 50/50, and metrics like user engagement and watch time determine which design performs better.

Interview Scenario
Answer:
I’d go with A/B Testing. It lets me expose two different UI versions to subsets of users and collect real-time metrics like completion and retention rates. Based on results, I’d promote the best-performing version to production.

Rolling Update – The "Smooth Transition" What It Is Rolling updates are Kubernetes’ default deployment method. Pods running the old version (V1) are replaced incrementally by new pods (V2), ensuring that some old pods always remain available during the transition.

When to Use It
For routine updates requiring continuous availability

When backward compatibility between versions exists

Pros
No downtime

Fully automated in Kubernetes

Simple rollback with deployment history

Cons
Slightly slower rollout

Risky if database schema changes are not compatible

Real-World Example
A SaaS company updates its payment service microservice with enhanced retry logic. A Rolling Update ensures that only one pod is replaced at a time, maintaining seamless service continuity across the cluster.

Interview Scenario
Answer:
A Rolling Update suits this best. Kubernetes ensures new pods are created and healthy before terminating old ones. This keeps service disruption minimal and allows for a safe rollback via deployment history if issues occur.

Recreate Deployment – The "Wipe and Replace" What It Is In the Recreate strategy, all old pods are terminated before deploying new ones. It’s straightforward but causes temporary downtime.

When to Use It
For non-critical services

In development or staging environments

When downtime is acceptable

Pros
Simplest to configure and manage

Minimal infrastructure cost

Cons
Causes downtime

Not suitable for user-facing or mission-critical systems

Real-World Example
An internal DevOps monitoring dashboard is updated during off-hours. Using a Recreate deployment, engineers shut down the old version, deploy the new one, and verify functionality — simple and efficient.

Interview Scenario
Answer:
I’d choose Recreate. It’s straightforward and resource-efficient, ideal for internal or non-critical apps. Since downtime is acceptable, we can afford the brief outage while deploying a new version cleanly.

Shadow Deployment – The "Silent Test" What It Is In Shadow deployments, live production traffic is mirrored to a new version (V2) while users continue interacting only with the stable version (V1). The new version processes the requests but doesn’t return responses to end users.

When to Use It
For load testing under real production traffic

During architecture rewrites or migrations

When you want zero user impact validation

Pros
Safely tests under real-world load

Identifies performance bottlenecks early

No risk to end users

Cons
High resource utilization (traffic duplication)

Complex setup and routing configuration

Real-World Example
A company refactors its monolithic application into microservices. Before the full switch, it mirrors production traffic to the new microservices (V2) using Istio. Engineers observe latency, throughput, and failure rates — ensuring confidence before the live transition.

Interview Scenario
Answer:
I’d implement a Shadow Deployment. It mirrors live traffic to the new architecture while users still receive responses from the old system. This enables realistic load testing and performance observation without impacting user experience.

Comparative Summary
Strategy Downtime Rollback Ease Resource Usage Use Case
Canary None Moderate Medium Gradual feature rollout
Blue-Green None Easy High Major, zero-downtime release
A/B Testing None Manual High UX experiments, data-driven validation
Rolling Update None Easy Low Routine production updates
Recreate Yes N/A Low Non-critical environments
Shadow None Complex Very High Performance testing and architecture validation
Best Practices for Kubernetes Deployments
Automate Rollouts and Rollbacks Use tools like Argo Rollouts or Flagger for progressive delivery automation.

Integrate Observability Always monitor key metrics (latency, error rates, CPU usage) using Prometheus, Grafana, and ELK stacks.

Leverage Feature Flags Tools like LaunchDarkly or Unleash decouple deployment from feature release, adding flexibility.

Test in Production Carefully Adopt Shadow or Canary strategies for high-risk deployments and validate using real traffic.

Version Your Configurations Use Helm or Kustomize for maintaining multiple deployment configurations safely.

Secure Your Pipelines Integrate RBAC, image scanning, and admission controllers to ensure compliance and security.

Plan for Rollback Always design deployments with rollback capability in mind — never deploy blind.

How to Talk About This in Interviews
Interviewers love when candidates:

Explain why they’d choose a strategy

Mention trade-offs and real metrics

Reference Kubernetes primitives like Deployments, ReplicaSets, and Services

Mention real tools (e.g., Istio, ArgoCD, Helm, Prometheus)

Example high-impact answer:

Conclusion
Kubernetes deployment strategies aren’t just technical patterns — they’re risk management tools that define how safely, confidently, and efficiently teams deliver innovation.

Whether you’re deploying a new ML model, refactoring a legacy monolith, or running high-availability APIs, mastering these strategies will make you a stronger engineer and a standout interview candidate.

Each method — from Canary to Shadow — brings its own balance of speed, safety, and simplicity. The real skill lies in choosing the right one for the right scenario.

Kubernetes – Creating Multiple Containers in a Pod

Naveen Jayachandran — Mon, 03 Nov 2025 17:24:18 +0000

Introduction
Kubernetes is an open-source container orchestration platform developed by Google in 2014 and written in Golang. It automates container deployment, load balancing, scaling, and management across multiple environments — including physical, virtual, and cloud-based infrastructures.

All major cloud providers (like AWS, Azure, and GCP) support Kubernetes as a managed service. Kubernetes ensures your containers run efficiently and reliably through its powerful automation and scheduling capabilities.

Kubernetes Architecture Overview

Kube-API Server
The API Server is the main entry point to the Kubernetes control plane.
It directly interacts with users through YAML or JSON configuration files and processes requests to manage cluster resources. It acts as the frontend of the control plane.
ETCD
etcd is a consistent, distributed key-value store that maintains the cluster state and metadata.
It ensures high availability and reliability of data across nodes.

Key Features of etcd:

Secure and fault-tolerant

Fully replicated

High performance

Highly available

Controller Manager
The Controller Manager continuously ensures that the actual state of the cluster matches the desired state defined in your configuration files. It automates the lifecycle of pods, nodes, and other Kubernetes objects.
Kube-Scheduler
The Kube-Scheduler assigns newly created pods to suitable nodes based on resource availability and constraints. It decides where each pod should run within the cluster.
Pod
A Pod is the smallest deployable unit in Kubernetes. It can contain one or more containers that share the same network namespace (IP address and ports).

Although the best practice is to run one container per pod, sometimes multiple containers are necessary — for example, when they must share storage or communicate directly within the same environment.

Container
A container is the runnable instance of an image with all dependencies bundled together.
It is lightweight, fast to start, and does not require pre-allocated memory.
Kube-Proxy
Kube-Proxy manages network communication inside and outside the cluster.
It assigns a unique IP address to each pod and handles load balancing and network routing.
Kubelet
The Kubelet is an agent that runs on every node in the cluster.
It receives instructions from the API Server and ensures that containers described in Pod specifications are running and healthy.

Creating Multiple Containers in a Single Pod
Let’s go step-by-step through how to create a pod with multiple containers.

Step 1: Open Your Kubernetes Environment
Ensure that Kubernetes is properly installed and configured on your machine or cluster.
You should be able to run:

kubectl version
Step 2: Create a Manifest File
All Kubernetes resources are created using manifest files written in YAML format.
We’ll create one for our multi-container pod.

Run the following command to create a file:

vi multicontainer.yml
Press i to enter insert mode and then type the YAML code below.

YAML Code for Creating Multiple Containers in a Pod
apiVersion: v1
kind: Pod
metadata:
name: testpod1
spec:
containers:
- name: c00
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo Hello-Coder; sleep 5; done"]
- name: c01
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo Hello-Programmer; sleep 5; done"]
After typing the code:

Press ESC

Type :wq and press Enter to save and exit.

Step 3: Apply the Manifest File
Run the following command to create the pod:

kubectl apply -f multicontainer.yml
You should see output like:

pod/testpod1 created
Step 4: Verify Pod Status
To check if the pod is running, execute:

kubectl get pods
Sample Output:

NAME READY STATUS RESTARTS AGE
testpod1 2/2 Running 0 30s
The READY column showing 2/2 confirms that both containers inside the pod are running successfully.

Step 5: View Container Logs
You can view the logs of each container individually using:

Logs from Container c00:
kubectl logs -f testpod1 -c c00
Output:

Hello-Coder
Hello-Coder
...
Logs from Container c01:
kubectl logs -f testpod1 -c c01
Output:

Hello-Programmer
Hello-Programmer
...
Summary
Pod Name: testpod1

Container 1: c00 → prints Hello-Coder

Container 2: c01 → prints Hello-Programmer

You have successfully created a multi-container pod in Kubernetes.
Although each pod typically contains a single container, multiple containers can coexist in the same pod when they share resources or need close coordination.

How to Run Shell Commands in Kubernetes Pods or Containers

Naveen Jayachandran — Mon, 03 Nov 2025 17:23:31 +0000

Kubernetes—commonly known as K8s—is an open-source container orchestration platform originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF). It is designed to automate the deployment, scaling, and management of containerized applications, helping organizations achieve agility and consistency across environments.

Running shell commands inside Kubernetes Pods or containers is a fundamental skill for developers and DevOps engineers managing applications in Kubernetes clusters. This guide will walk you through how to do it step-by-step, using Minikube for demonstration.

Setting Up a Kubernetes Cluster
Before executing shell commands, ensure that your Kubernetes cluster is properly set up. You can do this in one of two ways:

Full Cluster Setup – A production-grade environment with multiple nodes.

Single-Node Setup with Minikube – A lightweight local Kubernetes environment ideal for testing and development.

The main difference is that Minikube runs on a single node, making it simpler to configure and manage. You can install Minikube based on your system’s OS and architecture. (For more details, refer to: Setting Up Minikube in Your Local System.)

Understanding Kubernetes Pods and Containers
In Kubernetes, Pods are the smallest deployable units. A pod encapsulates one or more tightly coupled containers that share the same network namespace and storage volumes.

Think of a Pod as an abstraction layer on top of containers that adds metadata and orchestration capabilities. It contains the application’s code, libraries, runtime, and dependencies—ensuring consistent behavior across environments.

Now, let’s learn how to execute shell commands inside a Kubernetes Pod.

Executing Commands Inside a Kubernetes Pod
In this example, we’ll use Minikube to demonstrate the process.

Step 1: Start Minikube
Run the following command to start your local Kubernetes cluster:

minikube start
This initializes and configures a single-node Kubernetes cluster.

Step 2: Check Minikube Status
Verify that Minikube is running:

minikube status
If everything is working correctly, you should see the cluster components listed as Running.

Step 3: Create a Pod Using an NGINX Image
Run the following command to create a Pod:

kubectl run nginx-pod --image=nginx
This command pulls the NGINX image from Docker Hub and creates a pod named nginx-pod.

Step 4: List All Pods
Confirm that your pod is created and running:

kubectl get pods
You should see nginx-pod listed with a Running status.

Step 5: Access the Minikube Environment
Connect to your Minikube instance via SSH:

minikube ssh
This allows you to interact directly with the underlying virtual machine hosting your Kubernetes cluster.

Step 6: List Running Containers
Inside the Minikube environment, list all containers:

docker ps -a
You’ll see containers corresponding to your Kubernetes pods, including the NGINX container.

Step 7: Access the Container Shell
To enter the NGINX container, use:

docker exec -it /bin/bash
Once inside, you can run Linux shell commands such as:

ls
pwd
cd /usr/share/nginx/html
You are now working directly within the containerized environment of your Kubernetes pod.

Alternative: Using kubectl exec (Recommended)
Instead of SSHing into Minikube and using Docker, you can directly execute commands in your pod from your local terminal:

kubectl exec -it nginx-pod -- /bin/bash
This command opens an interactive shell inside the nginx-pod container without requiring Docker commands.

Best Practices for Running Shell Commands in Kubernetes
Use kubectl exec Carefully Always specify the exact pod and container when executing commands to avoid unintentional changes.

Use the -c Flag for Multi-Container Pods When a pod has multiple containers, access a specific one by adding the -c flag:kubectl exec -it -c -- /bin/bash

Execute Sequential Commands with && For running multiple commands in sequence:kubectl exec -it nginx-pod -- sh -c "cd /usr/share/nginx/html && ls && cat index.html"

Debug with kubectl debug Launch a debugging session in a running pod:kubectl debug -it nginx-pod --image=busybox This is useful for troubleshooting live workloads.

Use Non-Interactive Execution for Automation For scripts or CI/CD pipelines, run non-interactive commands:kubectl exec nginx-pod --stdin=false --tty=false -- ls /var/log/nginx

Conclusion
Understanding how to run shell commands inside Kubernetes Pods is essential for managing, debugging, and maintaining containerized applications.

Using tools like Minikube simplifies learning and experimentation, while kubectl exec provides a direct and efficient way to interact with your containers.

Mastering these techniques will help developers and DevOps engineers manage Kubernetes environments with greater confidence, agility, and control—boosting both development speed and operational reliability.

Kubernetes – Node

Naveen Jayachandran — Mon, 03 Nov 2025 17:22:34 +0000

Kubernetes Nodes are the actual worker or master machines where the real execution of workloads takes place. Each node runs essential services to operate Pods and is managed by the Kubernetes Control Plane. A single Kubernetes node can host multiple Pods, and each Pod can run one or more containers.

There are three key processes that operate on every node to schedule and manage Pods:

Container Runtime: The engine that runs containers inside Pods. Example: Docker, containerd, CRI-O.

Kubelet: The agent responsible for communicating with the Control Plane and the container runtime. It ensures Pods are running as defined in the PodSpec.

Kube-Proxy: Handles networking for Pods by forwarding requests from Kubernetes Services to the correct Pods on the node.

What is Kubernetes?
Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF), Kubernetes is written in Go (Golang) and supports deployment on public, private, and hybrid cloud environments.

Kubernetes enables organizations to manage a large number of containers as a single logical unit, simplifying scaling and fault tolerance across infrastructure.

What is a Kubernetes Node?
A Kubernetes Node is a physical or virtual machine that runs containerized workloads. Each node contains:

Kubelet – communicates with the Control Plane and ensures containers are running correctly.

Container Runtime – executes the containers (e.g., Docker, containerd).

Kube-Proxy – manages network rules and service discovery to route traffic efficiently.

Nodes collectively form the computing capacity of a Kubernetes cluster, where actual application workloads run.

How Does a Kubernetes Pod Work?
A Pod is the smallest deployable unit in Kubernetes — often compared to a process in a traditional OS.

Each Pod encapsulates one or more tightly coupled containers that share:

Storage (volumes)

Networking (same IP and port space)

Configuration data

Pods are ephemeral by design. If a Pod fails, Kubernetes automatically replaces it with a new replica to maintain desired application state and availability.

How Does a Kubernetes Node Work?
Nodes provide the execution environment for Pods. Kubernetes distinguishes between two types of nodes:

Master Node (Control Plane): Manages cluster operations such as scheduling, scaling, and maintaining cluster state.

Worker Node: Executes application Pods and reports status to the Control Plane.

A cluster can have any number of worker nodes, and it’s best practice to have at least two master nodes for high availability and failover capability.

Kubernetes Node Name Uniqueness
Each node in a Kubernetes cluster must have a unique name. Duplicate node names lead to inconsistencies and conflicts in object references, metadata, and state tracking.

If two nodes share the same name, the Kubernetes scheduler cannot reliably distinguish between them, which may result in misdirected workloads or volume attachments.

Kubernetes Nodes Not Ready
To view nodes and their status:

kubectl get nodes
Node statuses include:

Ready: Node is healthy and available for scheduling Pods.

NotReady: Node is currently unhealthy (could be due to network failure, kubelet crash, or pod issues).

Unknown: Node is not responding to the Control Plane (communication timeout or network issue).

Self-registration of Kubernetes Nodes
Nodes must be registered with the Kubernetes API server before the Control Plane can schedule Pods onto them.

By default, nodes self-register using the kubelet process. Kubelet communicates with the API server and automatically creates a Node object in the cluster.

Options for Self-registration
Kubeconfig Access: Provide kubelet with a kubeconfig file path for API server authentication.

Register Node Flag: The kubelet flag --register-node=true (default) allows automatic registration with the API server, which then creates the Node object used by the scheduler.

Manual Kubernetes Node Administration
If self-registration is disabled, nodes can be manually registered or removed:

kubectl create node
kubectl delete node
When creating a Node object manually, include name, labels, and taints in the YAML file.
Labels and taints help control Pod scheduling to ensure workloads are deployed only on compatible nodes.

Kubernetes Node Status
To describe a node in detail:

kubectl describe node
A healthy node includes conditions similar to:

"conditions": [
{
"type": "Ready",
"status": "True",
"reason": "KubeletReady",
"message": "kubelet is posting ready status"
}
]
Kubernetes Node Controller
The Node Controller monitors node health and manages node lifecycle.
If --register-node=true, nodes are automatically registered.
For manual setups, use --register-node=false to disable auto-registration.

Resource Capacity Tracking
When a node registers, it reports its resource capacity to the API server, including:

CPU cores

Memory

Ephemeral storage

Persistent volumes

The scheduler uses this data to ensure that Pods are placed only on nodes with sufficient available resources.

Kubernetes Node Topology
Node topology allows controlling how Pods are distributed across nodes and zones for performance, resilience, and affinity requirements.

Example:

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:

name: my-container image: nginx nodeSelector: topology.kubernetes.io/zone: us-east-1a Here, the Pod is scheduled specifically to nodes in the us-east-1a availability zone.

Graceful Node Shutdown
A graceful shutdown allows running Pods to complete their tasks and save their state before termination.

Benefits:

Prevents data loss or corruption

Allows stateful applications to persist important data

Maintains high availability and minimizes downtime

Ensures predictable, stable system behavior

If a Pod does not terminate within the grace period, it is forcefully stopped.

Non-Graceful Node Shutdown Handling
A non-graceful shutdown (e.g., power failure) terminates Pods abruptly, without kubelet notification.

Consequences include:

Loss of in-memory data or unsaved state

Stateful applications entering “Terminating” status indefinitely

Scheduler unable to recreate replacements until node recovery

This is why ensuring graceful shutdowns is critical in production clusters.

Kubernetes Nodes vs Kubernetes Pods
Aspect Kubernetes Nodes Kubernetes Pods
Definition Physical or virtual machines that run workloads Smallest deployable unit that runs containers
Function Host one or more Pods Host one or more containers
Resources Provide CPU, memory, and storage Consume resources from the Node
Responsibility Managed by Control Plane Managed by Scheduler and Controller Manager
Role Run Kubernetes workloads Execute application containers
Managing Kubernetes Nodes
Node management includes:

Provisioning & Deployment – Adding new nodes to increase capacity

Maintenance & Upgrades – Applying patches, updates, or reconfigurations

Scaling – Automatically or manually adding/removing nodes for optimal performance and availability

Optimizing Kubernetes Node Performance
Performance optimization ensures efficient use of compute resources and maintains cluster stability.

Key focus areas:

Scheduling strategy

Resource allocation

Container runtime tuning

Resource Utilization Optimization
Container Packing: Maximize utilization by co-locating compatible workloads.

Resource Requests & Limits: Define fair resource allocations to prevent contention.

Eviction Policies: Gracefully evict Pods when nodes run low on resources.

Resource Monitoring: Continuously track usage to detect inefficiencies and bottlenecks.

Scheduling Strategies
Node Affinity / Anti-Affinity: Schedule Pods on or away from specific nodes based on labels.

Workload-Aware Scheduling: Place Pods based on performance characteristics and resource needs.

Dynamic Scheduling: Continuously rebalance workloads as cluster conditions change.

Container Runtime Tuning
Configuration Optimization: Adjust runtime settings (e.g., Docker, containerd) for better efficiency.

Image Optimization: Use minimal, lightweight images to reduce start times.

Regular Updates: Keep runtime versions current for performance and security improvements.

Memory Management: Fine-tune container memory allocation for consistent performance.

Securing Kubernetes Nodes
Node security is essential to protect workloads from unauthorized access and vulnerabilities. Key practices include:

Node Hardening & Patch Management

Network Policies and Access Controls

Container Runtime Security (sandboxing, scanning, non-root execution)

Kubernetes Namespaces

Naveen Jayachandran — Mon, 03 Nov 2025 17:21:20 +0000

In Kubernetes, Namespaces provide a logical way to isolate and organize groups of resources within a single cluster. They are especially useful in environments where multiple teams or projects share the same cluster, allowing separation and management of resources independently.

Each resource in a Namespace must have a unique name, but resources across different Namespaces can share the same name without conflict.

Default Kubernetes Namespaces
When you create a Kubernetes cluster, it comes with four built-in Namespaces:

default

kube-node-lease

kube-public

kube-system

To view all available Namespaces, use:

kubectl get namespaces
You’ll see the four default Namespaces listed.

Bonus: Kubernetes Dashboard Namespace (Minikube Specific)
When you install Minikube, an additional Namespace called kubernetes-dashboard is automatically created.
This Namespace is specific to Minikube and not present in standard Kubernetes clusters.

kube-system The kube-system Namespace contains core system components and processes managed by Kubernetes itself. It includes system-level Pods like:

kube-dns

kube-proxy

etcd

kube-apiserver

This Namespace is not meant for user-created workloads. Developers should avoid creating or modifying resources in kube-system.

kube-public The kube-public Namespace holds publicly accessible cluster information. It contains a ConfigMap that stores details about the cluster, which can be accessed even without authentication.

To view this information:

kubectl cluster-info
This command retrieves data stored in the kube-public Namespace.

kube-node-lease The kube-node-lease Namespace was introduced to improve cluster performance and scalability. It maintains Node lease objects, which record the heartbeat and availability status of each Node.

Each Node has its own lease object, helping the Kubernetes control plane efficiently detect Node failures.

default The default Namespace is where Kubernetes places all resources if no Namespace is explicitly specified. When you create a Pod, Service, or ConfigMap without assigning a Namespace, it’s automatically placed in default.

Creating Namespaces
You can create new Namespaces in two ways:

Using CLI Commands Run the following command to create a Namespace named my-ns:

kubectl create namespace my-ns
To verify:

kubectl get namespaces
You’ll see my-ns listed among the available Namespaces.

Using a Configuration File It’s often better to define Namespaces using a YAML configuration file — this provides version control and traceability within your infrastructure code.

Example:

apiVersion: v1
kind: Namespace
metadata:
name: development
labels:
name: development
Apply the file:

kubectl create -f namespace.yaml
Creating Components in the Default Namespace
When no Namespace is specified, Kubernetes automatically creates resources in the default Namespace.

Example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
db_url: my-service.database
Apply the ConfigMap:

kubectl apply -f my-config-map.yaml
To verify which Namespace it belongs to:

kubectl get configmap -n default
Or to view detailed YAML output:

kubectl get configmap my-configmap -n default -o yaml
You’ll see that the Namespace field is set to default.

Creating Components in a Custom Namespace
You can assign resources to a specific Namespace in two ways:

Specifying Namespace via CLI Add the --namespace flag when applying the resource file:

kubectl apply -f my-config-map.yaml --namespace=my-ns
Make sure the Namespace (my-ns) already exists, or you’ll get an error.

Specifying Namespace in the YAML File Include the Namespace directly in the metadata section:

apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
namespace: my-ns
data:
db_url: my-service.database
Apply the file:

kubectl apply -f my-config-map.yaml
Then verify:

kubectl get configmap -n my-ns -o yaml
The output will confirm that the ConfigMap now belongs to the my-ns Namespace.

Changing the Active Namespace
By default, your active Namespace is default.
To easily switch between Namespaces, use the kubens tool from kubectx.

Install kubectx and kubens
sudo snap install kubectx --classic
View All Namespaces
kubens
The active Namespace will appear highlighted in green.

Switch to Another Namespace
kubens my-ns
Now, your active Namespace is set to my-ns, meaning any subsequent resource creation (without specifying a Namespace) will default to this Namespace.

Conclusion
Kubernetes Namespaces are essential for managing complex, multi-team, or multi-project environments within a single cluster.
They offer logical separation, resource isolation, and simplified access control — making them a fundamental part of any production-grade Kubernetes architecture.

Kubernetes Pods: How to Create and Manage Them

Naveen Jayachandran — Mon, 03 Nov 2025 17:20:04 +0000

A Pod represents a single instance of a running process in your Kubernetes cluster and can contain one or more containers. Think of a Pod as a lightweight, application-specific logical host. All containers within a Pod are co-located on the same worker node and share the same execution environment.

This shared context is what makes Pods special, and it includes:

Shared Networking
Each Pod gets a unique IP address. All containers within that Pod share this IP and port space, allowing them to communicate with each other over localhost.

Shared Storage
Containers in a Pod can share storage volumes, providing a common filesystem for data exchange and persistence.

The Pod Lifecycle
A Pod progresses through several lifecycle phases:

Pending: The Pod has been accepted by the Kubernetes system, but one or more container images have not yet been created. This could be due to image download delays or the scheduler finding a suitable node.

Running: The Pod is bound to a node, and all containers are created. At least one container is running or is in the process of starting or restarting.

Succeeded: All containers have terminated successfully (exit status 0) and will not restart. This phase is typical for batch jobs.

Failed: All containers have terminated, and at least one container failed (non-zero exit code).

Unknown: The Pod state cannot be determined—often due to a network issue with the node.

Kubernetes Pods Overview
In Kubernetes, Pods are represented as circles in diagrams, with cube-like structures as containers and cylinder-like structures as shared volumes.

A Pod can contain one or more containers, all sharing:

The same IP address

Storage volumes

Network resources

Other required configurations

Pods make it easier to move containers around the cluster. They are managed by controllers, which handle:

Rollouts: Deploying new versions of Pods

Replication: Maintaining the desired number of Pods

Health monitoring: Restarting or replacing failed Pods

If a node fails, Kubernetes controllers automatically recreate the affected Pods on another node to maintain availability.

Common Controllers
Jobs → For batch tasks that run once and complete (ephemeral workloads).

Deployments → For stateless or persistent apps (like web services).

StatefulSets → For stateful, persistent apps (like databases).

Pod Operating System
The operating system inside a Pod depends on the container image it uses. For example:

An Ubuntu-based image → Ubuntu OS inside the Pod

An Alpine Linux image → Alpine Linux OS inside the Pod

The choice of base image depends on the application’s requirements and the developer’s preference.

Pods and Controllers
Pods are ephemeral — they don’t get rescheduled once they expire. Therefore, we generally don’t create Pods directly. Instead, we use higher-level objects that manage Pods automatically, such as:

Deployments

Replication Controllers

ReplicaSets

These controllers maintain Pod replicas and ensure high availability.

Getting Started with Kubernetes Pods

Create a Pod Imperatively A quick way to test your cluster setup is by creating a simple Nginx Pod:

kubectl run nginx --image=nginx
This command creates a Pod named nginx using the official Nginx image.

Generate a Declarative Manifest Instead of writing YAML manually, you can generate it using kubectl:

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
The --dry-run=client -o yaml flags generate YAML output without actually creating the Pod.

Your pod.yaml will look like this:

apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:

image: nginx name: nginx resources: {} dnsPolicy: ClusterFirst restartPolicy: Always status: {} Key Fields:

apiVersion: API version (e.g., v1)

kind: Type of object (Pod)

metadata: Object identifiers such as name and labels

spec: Desired configuration — containers, images, ports, etc.

Create a Pod Declaratively First, delete the Pod created imperatively:

kubectl delete pod nginx
Now, create it from the YAML manifest:

kubectl apply -f pod.yaml
Running kubectl apply again after modifying the YAML intelligently updates the Pod to match the new desired state.

Inspecting and Interacting with Your Pod
Get Pod Status
kubectl get pods
Example output:

NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 60s
Describe the Pod
For detailed status, events, and configuration:

kubectl describe pod nginx
View Container Logs
kubectl logs nginx
Execute Commands Inside a Container
To open an interactive shell inside the container:

kubectl exec -it nginx -- bash
Once inside, use standard Linux commands (ls, cat, ps, etc.) to inspect the container.

Advanced Patterns: Multi-Container Pods
Pods can include multiple containers that work closely together. Two common design patterns are:

Init Containers
Init Containers run before the main application containers and must complete successfully before the main app starts.

Use Cases:

Waiting for a dependent service (e.g., database)

Running setup or migration scripts

Cloning a Git repository into a shared volume

Registering the Pod with a central service

Sidecar Containers
Sidecars run alongside the main application containers throughout the Pod’s lifecycle. They extend or enhance the main app’s functionality.

Use Cases:

Logging: Collect and forward logs

Monitoring: Gather metrics for Prometheus

Service Mesh Proxy: Handle traffic via Istio or Linkerd

Data Sync: Sync files from S3 or Git

Pod Communication
Internal Communication
Containers in the same Pod communicate via localhost.

Inter-Pod Communication
Pods within the same cluster communicate using cluster-private IPs assigned by Kubernetes networking.

If external access is required, you can expose a Pod using a Service.

Updating and Replacing Pods
Kubernetes manages Pod updates gracefully:

Updating Pods: Makes configuration or image changes while keeping services running (rolling updates).

Pod Replacement: When a Pod crashes or is terminated, Kubernetes automatically recreates a new Pod instance — ensuring continuous availability.

Static Pods
Static Pods are created directly by the kubelet on a node — not by the Kubernetes control plane.

You define them by placing a Pod manifest file in /etc/kubernetes/manifests/. The kubelet automatically starts and monitors the Pod on that node.

Static Pods are commonly used for control plane components like kube-apiserver, kube-scheduler, and etcd.

Basic Kubectl Commands for Kubernetes Pods
Create a Pod
kubectl create -f
For example, to create a Pod named AskTech:

kubectl create -f asktech-pod.yaml
Delete a Pod
kubectl delete -f
This deletes the Pod defined in the file.

Get Pods
kubectl get pod --namespace
Lists Pods within a specified namespace.

Troubleshooting with kubectl
kubectl get pods → List all Pods in the current namespace.

kubectl describe pod → Get detailed Pod info.

kubectl logs → Retrieve logs from a specific Pod.

✅ In Summary:
Kubernetes Pods are the fundamental execution unit in your cluster, enabling efficient container orchestration, networking, and storage sharing. While you can create Pods manually, managing them via higher-level controllers like Deployments or StatefulSets ensures reliability, scalability, and resilience for your workloads.

Kubernetes - Labels & Selectors

Naveen Jayachandran — Mon, 03 Nov 2025 17:19:00 +0000

Introduction
In Kubernetes, labels are simple key-value pairs attached to objects such as Pods, Deployments, and Services. They are the foundation of resource organization and selection, allowing you to efficiently group, filter, and manage related objects within your cluster.

Example label sets:

app: web-server
tier: frontend
environment: development
release: stable
Labels help answer questions like:

“Which Pods are part of my frontend tier?”

“Which resources belong to the staging environment?”

“Which release version is currently running?”

Working with Labels a. Creating a Pod with Labels Create a Pod manifest with labels. Save the following as labeled-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: web-server-pod
labels:
app: nginx
tier: frontend
environment: development
spec:
containers:

name: nginx-container image: nginx Apply the manifest:

kubectl apply -f labeled-pod.yaml
b. Viewing Labels
To list Pods with their labels:

kubectl get pods --show-labels
Output:

NAME READY STATUS RESTARTS AGE LABELS
web-server-pod 1/1 Running 0 30s app=nginx,environment=development,tier=frontend
To display specific labels as columns:

kubectl get pods -L app,environment
c. Adding and Modifying Labels
Add a new label to an existing Pod:

kubectl label pod web-server-pod owner=admin
Verify the update:

kubectl get pods --show-labels
Update an existing label (requires the --overwrite flag):

kubectl label pod web-server-pod environment=staging --overwrite

Understanding Selectors If labels are the tags that describe objects, selectors are the filters used to find and group those objects.

Selectors are widely used in:

Services — to select which Pods to send traffic to.

Deployments — to define which Pods belong to the deployment.

ReplicaSets — to manage a specific group of Pods.

There are two main types of selectors:

a. Equality-Based Selectors
Filter objects based on exact key-value matches.

Supported operators:

=, ==, !=
b. Set-Based Selectors
Allow more flexible filtering by checking if a key’s value exists within (or outside) a set.

Supported operators:

in, notin, exists

Hands-On: Using Selectors Let’s create two more Pods for demonstration.

a. database-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: database-pod
labels:
app: postgres
tier: backend
environment: development
spec:
containers:

name: postgres-container image: postgres b. api-pod.yaml apiVersion: v1 kind: Pod metadata: name: api-pod labels: app: user-api tier: backend environment: production spec: containers:
name: api-container image: gcr.io/google-samples/hello-app:1.0 Apply both:

kubectl apply -f db-pod.yaml -f api-pod.yaml

Querying Pods with Selectors Equality-Based Selection Find all Pods in the development environment:

kubectl get pods -l environment=development
Find all Pods belonging to the backend tier:

kubectl get pods -l tier=backend
Combine multiple filters (logical AND):

kubectl get pods -l 'tier=backend,environment=production'
Set-Based Selection
Find all Pods in either the development or staging environments:

kubectl get pods -l 'environment in (development,staging)'
Find all Pods that do not belong to the frontend tier:

kubectl get pods -l 'tier notin (frontend)'
Find all Pods that simply have an app label (regardless of value):

kubectl get pods -l 'app'
Summary
Concept Purpose Example
Label Key/value metadata attached to objects app=nginx
Selector Filters resources by labels -l environment=dev
Equality-Based Selector Matches exact key/value tier=backend
Set-Based Selector Matches from a set or existence environment in (dev, staging)
Key Takeaways
Labels are the backbone of organization in Kubernetes.

Selectors use those labels to logically group, filter, and manage resources.

Kubernetes controllers (Deployments, Services, ReplicaSets) rely heavily on label selectors to define their scope.

Kubernetes - Jobs

Naveen Jayachandran — Mon, 03 Nov 2025 17:17:57 +0000

In the Kubernetes world, jobs are considered an object that acts as a supervisor or controller for a task. The Kubernetes Job will create a Pod, monitor the task, and recreate another one if that Pod fails for some reason. Upon completion of the task, it will terminate the Pod. Unlike Deployments and Pods, you can specify a Job in Kubernetes which can be an always-running job, a time-based job, or a task-based job. This allows you to tolerate errors or failures that can cause unexpected Pod termination.

When you submit a Job, it will create one or more Pods based on the requirement, complete the defined task, and keep the Pods running until the task is finished. The Job keeps track of successful completions when Pods finish execution. When a Job is suspended, all of its active Pods are deleted until the Job is restarted.

Job Types

Non-Parallel Job
A simple job where a single task is defined. It will create one Pod, and upon successful completion, the Pod will terminate.
Parallel Job with Fixed Completion Count
A more complex task that requires multiple Pods to complete. These Pods run in parallel, and each Pod receives a unique index between 0 and .spec.completions - 1, based on the number specified in the configuration. The Job is considered successful when the number of successful Pod completions matches .spec.completions.
Parallel Job with a Work Queue
In this type, multiple Pods run in parallel to complete complex workloads with dependencies. To decide what each Pod should work on, the Pods cooperate with one another or with an external service.
For instance, a Pod might pull up to N items in a batch from a work queue. Each Pod autonomously determines whether all peers are finished and whether the entire Job is complete.

Use Cases
A simple use case for a Job is to perform system operations tasks. For example, when setting up a cluster or service that requires repeated setup tasks, you can create a Job and reuse it to bring up the same service or perform similar tasks.

Another use case is performing data backups or computation tasks.

A more complex scenario involves a series of tasks that must be executed in order, where Jobs create and manage Pods until the specified number of completions is reached.

Helm Charts also employ Jobs to run installation, setup, or test commands on clusters during service provisioning.

Key Terminologies
Kubernetes: An open-source system from Google for orchestrating containers, automating most operational tasks around containerized applications.

Pods: The smallest deployable compute units in Kubernetes, which can contain one or more containers.

Minikube: A local version of Kubernetes that helps you start and test your workloads locally.

Steps to Set Up a Job
Let’s consider an example of setting up a Job using the Docker BusyBox image that pings asktech.org.

Step 1. Start your Minikube
$ minikube start
Step 2. Create the Job definition file in YAML format
$ cat ping-job.yaml
Job Definition file in YAML format

Step 3. Submit the Job definition to Kubernetes
$ kubectl apply -f ping-job.yaml
You should see a message indicating that the Job has been created.

Step 4. List all Jobs
$ kubectl get jobs
You can see the number of completions, duration, and age of the Job.

Step 5. Get Job Details
$ kubectl describe job ping
This command displays detailed information about the Job.

Step 6. Get the Pods Running for the Job
$ kubectl get pods
You can view the Pod name, container count, status, restart count, and age.

Step 7. Check Container Logs
You can also check the logs of the running container to see the output of your Job.

Step 8. Delete the Job
To delete the Job and its associated Pods:

$ kubectl delete job ping
$ kubectl get jobs
Once deleted, the Pods associated with the Job are also removed.

✅ Final Note:
Kubernetes Jobs are powerful tools for running finite, batch-oriented tasks. Whether you’re performing database migrations, running test suites, or doing scheduled backups, Jobs provide reliability and fault tolerance through their built-in restart and completion tracking mechanisms.