Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Complete Kubernetes Guide —

Interview Ready

Scope: Everything from the Complete Kubernetes Training syllabus except Kubernetes Fundamentals
(Topics 1–4).
Every Kubernetes object includes a fully commented YAML manifest, a 3–4 line definition, and
production usage notes.

Table of Contents
1. Introduction to Kubernetes Components
2. Pods — Lifecycle, CNI, Types & Annotations
3. ReplicaSet
4. Deployments & Deployment Strategies
5. Kubernetes Services — ClusterIP, NodePort, LoadBalancer
6. Ingress & Ingress Controller
7. ConfigMap & Secrets
8. Namespaces
9. Kubernetes Volumes — PV, PVC, StorageClass
10. RBAC — Role Based Access Control
11. DaemonSet
12. StatefulSet
13. Headless Services
14. Autoscaling — HPA, VPA, Cluster Autoscaler
15. Scheduling — Taints, Tolerations, Affinity
16. Probes — Liveness, Readiness, Startup
17. KubeConfig Details
18. Init Containers
19. Troubleshooting
20. Kubectl Commands
21. Reverse Proxy
22. SSL/TLS Certificate Information

[Link] Page 1 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

23. EKS Cluster Backup — Velero

24. Service Mesh — Istio, Kiali, Jaeger
25. Cluster Upgradation
26. Cluster Communication & Multi-Cluster
27. Jobs & CronJob
28. DNS & CoreDNS
29. Network Policy
30. Labels & Selectors
31. Pod Security Standards
32. TLS in Cluster Communication
33. Secrets Encryption
34. Helm
35. Disaster Recovery Strategy
36. Logs — kubectl logs & Logging Stack
37. Monitoring & Observability — Prometheus, Grafana, AlertManager
38. EFK Stack
39. Metrics Server
40. Cordon, Drain & PodDisruptionBudget

1. Introduction to Kubernetes Components

Definition
Kubernetes is an orchestration platform composed of Control Plane components (API Server, etcd,
Scheduler, Controller Manager) and Worker Node components (Kubelet, Kube-proxy, Container
Runtime). Together, they manage the lifecycle of containerized workloads across a distributed cluster.
Understanding each component is essential for debugging, scaling, and architecting production
systems.

Production Usage
In production, the Control Plane is typically run as a highly available (HA) set of 3+ nodes (or managed
by cloud providers like EKS/GKE/AKS). Worker nodes are scaled horizontally based on workload
demand. etcd is backed up regularly as it stores all cluster state.

Component Breakdown

[Link] Page 2 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Component Role Runs On

API Server Front-door for all K8s operations; validates & processes REST Control
requests Plane

etcd Distributed key-value store; single source of truth for cluster state Control
Plane

Scheduler Assigns Pods to Nodes based on resource requirements & Control

constraints Plane

Controller Runs controllers (ReplicaSet, Deployment, Node, etc.) to reconcile Control

Manager desired vs actual state Plane

Cloud Controller Integrates with cloud provider APIs (LB, routes, volumes) Control
Manager Plane

Kubelet Agent on each node; ensures containers are running in Pods Worker
Node

Kube-proxy Maintains network rules on nodes; enables Service abstraction Worker

Node

Container Runtime Actually runs containers (containerd, CRI-O) Worker

Node

# ============================================================
# Kubernetes Component Architecture (Conceptual Reference)
# ============================================================
# This is NOT a deployable manifest — it's a reference map
# showing how components interact in a K8s cluster.

# --- CONTROL PLANE COMPONENTS ---

# 1. kube-apiserver
# - The central management entity of the entire cluster
# - ALL communication (kubectl, dashboard, internal components)
# goes through the API Server
# - Validates and processes RESTful API requests
# - Stores the resulting state in etcd
# - Production: Runs as a static Pod on master nodes
# (see /etc/kubernetes/manifests/[Link])

# 2. etcd
# - Consistent, distributed key-value store
# - Stores ALL cluster data (Pods, Services, Secrets, ConfigMaps)
# - Only the API Server communicates with etcd directly
# - Production: Always run in HA mode (3 or 5 nodes)
# - Backup command: etcdctl snapshot save /backup/[Link]

[Link] Page 3 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# 3. kube-scheduler
# - Watches for newly created Pods with no assigned node
# - Selects the best node based on:
# a) Resource requirements (CPU, memory)
# b) Affinity/anti-affinity rules
# c) Taints and tolerations
# d) Data locality
# - Does NOT run the Pod — just decides WHERE it runs

# 4. kube-controller-manager
# - Runs a set of controllers in a single process:
# - Node Controller: Monitors node health
# - ReplicaSet Controller: Ensures desired replica count
# - Endpoint Controller: Populates Service endpoints
# - ServiceAccount Controller: Creates default accounts
# - Each controller is a reconciliation loop:
# watches desired state → compares with actual → takes action

# 5. cloud-controller-manager
# - Separates cloud-specific logic from core K8s
# - Manages: Load Balancers, Routes, Node lifecycle (cloud VMs)
# - Examples: AWS ELB creation, GCP persistent disk provisioning

# --- WORKER NODE COMPONENTS ---

# 6. kubelet
# - Primary node agent running on every worker node
# - Registers the node with the API Server
# - Receives PodSpecs and ensures containers are running & healthy
# - Reports node and Pod status back to the control plane
# - Does NOT manage containers not created by Kubernetes

# 7. kube-proxy
# - Network proxy running on each node
# - Maintains iptables/IPVS rules for Service routing
# - Enables the Service abstraction (ClusterIP, NodePort, etc.)
# - Three modes: iptables (default), IPVS (high performance), userspace (legacy)

# 8. Container Runtime
# - Software responsible for running containers
# - Kubernetes supports any CRI-compliant runtime:
# - containerd (most common, default in modern K8s)
# - CRI-O (lightweight, designed for K8s)
# - Docker was removed as a runtime in K8s 1.24+
# (dockershim deprecated; containerd is used instead)

2. Pods — Lifecycle, CNI, Types & Annotations

[Link] Page 4 of 106
Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Definition
A Pod is the smallest deployable unit in Kubernetes — a wrapper around one or more containers that
share the same network namespace, IP address, and storage volumes. Pods are ephemeral by design;
they are created, scheduled to a node, and eventually terminated. Every container in a Pod can
communicate with others via localhost , making Pods ideal for tightly coupled application
components (e.g., app + sidecar logger).

Production Usage
In production, Pods are never created directly — they are always managed by higher-level controllers
(Deployments, StatefulSets, DaemonSets, Jobs). This ensures automatic restart, scaling, and rolling
updates. Direct Pod creation is only used for one-off debugging ( kubectl run ).

2.1 Pod Manifest — Fully Explained

# ============================================================
# Pod Manifest — Complete Interview-Ready Example
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# Delete: kubectl delete -f [Link]
# ============================================================

apiVersion: v1 # API version for Pod resource

# v1 = stable/core API group
kind: Pod # Resource type — Pod
metadata: # --- METADATA SECTION ---
name: webapp-pod # Unique name of the Pod within a namespace
namespace: production # Namespace where this Pod lives
# If omitted, defaults to "default" namespace
labels: # Key-value pairs for IDENTIFICATION & SELECTION
app: webapp # Used by Services, Deployments to select this Pod
environment: production # Custom label for environment tracking
version: v1.2.0 # Track application version via labels
team: backend # Organizational label — who owns this Pod
annotations: # --- ANNOTATIONS ---
# Key-value pairs for NON-IDENTIFYING metadata
# Unlike labels, annotations are NOT used for selection
# They store auxiliary information for tools & humans
description: "Main web application pod"
[Link]/change-cause: "Updated to v1.2.0 with security patches"
# ^ Records why this version was deployed
# Visible in: kubectl rollout history
[Link]/scrape: "true" # Tells Prometheus to scrape metrics from this Pod
[Link]/port: "9090" # Port where metrics endpoint is exposed
[Link]/path: "/metrics" # Path for the metrics endpoint

[Link] Page 5 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

[Link]/inject: "true"
# ^ Tells Istio service mesh to inject sidecar proxy
[Link]/agent-inject: "true"
# ^ Tells HashiCorp Vault to inject secrets
spec: # --- SPECIFICATION SECTION ---
# Defines the DESIRED STATE of the Pod
restartPolicy: Always # What happens when a container exits:
# Always — restart no matter what (default for Pods in
# OnFailure — restart only on non-zero exit code (for Jo
# Never — never restart (for one-off tasks)

terminationGracePeriodSeconds: 30
# Time (seconds) K8s waits after sending SIGTERM
# before sending SIGKILL
# Production: Set higher (60-120s) for apps that need
# to drain connections or flush data

nodeSelector: # Simple node selection constraint

disktype: ssd # Pod will only be scheduled on nodes with this label
# Simpler alternative to nodeAffinity

serviceAccountName: webapp-sa # ServiceAccount this Pod uses for RBAC

# Controls what K8s API calls the Pod can make
# Production: ALWAYS specify — never use "default"

securityContext: # Pod-level security settings

runAsUser: 1000 # Run all containers as UID 1000 (non-root)
runAsGroup: 3000 # Primary group ID
fsGroup: 2000 # Group ID for mounted volumes
runAsNonRoot: true # Refuse to start if container runs as root

containers: # --- CONTAINER LIST ---

# At least one container is required
- name: webapp # Container name (unique within the Pod)
image: nginx:1.25-alpine # Container image in format: registry/repo:tag
# Production: ALWAYS use specific tags, never "latest"
# "latest" causes unpredictable deployments

imagePullPolicy: IfNotPresent
# When to pull the image:
# Always — pull every time (use for "latest" tag)
# IfNotPresent — pull only if not cached (recommended)
# Never — never pull, must be pre-loaded

ports:
- containerPort: 80 # Port the container listens on
name: http # Named port — can be referenced by Services
protocol: TCP # TCP (default) or UDP
- containerPort: 443
name: https
protocol: TCP

[Link] Page 6 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

env: # Environment variables injected into the container

- name: APP_ENV
value: "production" # Hardcoded value
- name: DB_HOST
valueFrom: # Value sourced from another K8s object
configMapKeyRef: # Reference a ConfigMap key
name: app-config # ConfigMap name
key: database_host # Key within the ConfigMap
- name: DB_PASSWORD
valueFrom:
secretKeyRef: # Reference a Secret key
name: app-secrets # Secret name
key: db-password # Key within the Secret

resources: # --- RESOURCE MANAGEMENT ---

# CRITICAL for production — prevents resource starvation
requests: # MINIMUM resources guaranteed to the container
# Used by the Scheduler to find a suitable node
memory: "128Mi" # 128 Mebibytes of RAM
cpu: "250m" # 250 millicores = 0.25 CPU core
limits: # MAXIMUM resources the container can use
# Exceeding memory limit → OOMKilled
# Exceeding CPU limit → throttled (not killed)
memory: "512Mi"
cpu: "500m"

volumeMounts: # Mount volumes into the container's filesystem

- name: app-data # Must match a volume name defined below
mountPath: /data # Path inside the container where volume is mounted
readOnly: false # Whether the mount is read-only
- name: config-volume
mountPath: /etc/app/config
readOnly: true

# --- PROBES (covered in detail in Section 16) ---

livenessProbe: # Is the container alive? If not → restart it
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 15 # Wait 15s after container starts before probing
periodSeconds: 10 # Check every 10 seconds
failureThreshold: 3 # 3 consecutive failures → restart container

readinessProbe: # Is the container ready to serve traffic?

# If not → remove from Service endpoints
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 5

[Link] Page 7 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

volumes: # --- VOLUMES ---

# Define storage available to containers in the Pod
- name: app-data
persistentVolumeClaim: # Use a PVC for persistent storage
claimName: webapp-pvc # Name of the PVC (must exist)
- name: config-volume
configMap: # Mount a ConfigMap as files
name: app-config # ConfigMap name

2.2 Pod Lifecycle

┌──────────────────────────────────────────────────────────────────────┐
│ POD LIFECYCLE │
│ │
│ kubectl apply ──► API Server ──► etcd (stored) │
│ │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ ┌───────────────────┐ │
│ │ Pending │──►│ Running │──►│Succeeded│ │ Failed │ │
│ │ │ │ │ │(exit 0) │ │ (exit non-zero) │ │
│ └─────────┘ └──────────┘ └─────────┘ └───────────────────┘ │
│ │ │ │
│ │ └──► Unknown (node lost contact) │
│ │ │
│ Scheduler assigns Container runs │
│ Pod to a Node init containers → app containers │
└──────────────────────────────────────────────────────────────────────┘

Phase Description

Pending Pod accepted by K8s but containers not yet created. Reasons: image pull, scheduling,
resource wait

Running Pod bound to a node, at least one container is running or starting

Succeeded All containers exited with code 0 and will not restart

Failed All containers terminated, at least one exited with non-zero code

Unknown Pod state cannot be determined — usually a node communication issue

Container States within a Running Pod:

[Link] Page 8 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

State Meaning

Waiting Container is not running — pulling image, applying secrets, etc.

Running Container is executing without issues

Terminated Container finished execution (success or failure)

2.3 CNI Plugins (Container Network Interface)

Definition
CNI (Container Network Interface) is a specification and set of plugins that configure networking for
containers in Kubernetes. CNI plugins are responsible for assigning IP addresses to Pods, setting up
routes between nodes, and enforcing network policies. Without a CNI plugin, Pods cannot
communicate — it is the first thing you install after setting up a K8s cluster.

Production Usage
Every production cluster requires a CNI plugin. The choice depends on performance needs (Cilium for
eBPF-based high performance), network policy requirements (Calico for fine-grained policies), and
cloud environment (AWS VPC CNI for native AWS networking). Most managed K8s services pre-install
a default CNI.

CNI Plugin Key Feature Best For

Calico Network Policies, BGP routing On-prem, hybrid cloud, security-focused

Cilium eBPF-based, high performance High-throughput, observability-focused

Flannel Simple overlay (VXLAN) Learning, simple clusters

Weave Net Encrypted mesh network Multi-cloud, encrypted traffic

AWS VPC CNI Native VPC IPs for Pods AWS EKS clusters

Azure CNI Native Azure VNet IPs Azure AKS clusters

Antrea OVS-based, VMware backed VMware/vSphere environments

2.4 Types of Pods

[Link] Page 9 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Type Description Use Case

Single- Most common; one container per Standard microservice deployment

Container Pod Pod

Multi-Container Multiple containers sharing Sidecar patterns (logging, proxy, adapter)

Pod network/storage

Static Pod Managed directly by kubelet, not API Control plane components ( kube-
Server apiserver , etcd )

Init Container Has init containers that run before Database migration, config generation
Pod app containers

Multi-Container Pod Patterns:

[Link] Page 10 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# Multi-Container Pod — Sidecar Pattern
# ============================================================
# Pattern: Main app container + sidecar log shipper
# The sidecar reads logs from a shared volume and ships them
# to a centralized logging system (ELK, Splunk, etc.)
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: sidecar-logging-pod
labels:
app: web-with-logging
pattern: sidecar # Identifies this as a sidecar pattern Pod
annotations:
description: "Demonstrates sidecar pattern - app + log shipper"
pod-pattern: "sidecar" # Annotation for documentation/tooling
spec:
containers:
# --- Main Application Container ---
- name: web-app
image: nginx:1.25-alpine
ports:
- containerPort: 80
volumeMounts:
- name: shared-logs # Shared volume between containers
mountPath: /var/log/nginx # Nginx writes logs here

# --- Sidecar Container (Log Shipper) ---

- name: log-shipper
image: fluent/fluent-bit:latest
volumeMounts:
- name: shared-logs # Same shared volume
mountPath: /var/log/input # Fluent Bit reads logs from here
readOnly: true # Sidecar only reads, never writes
env:
- name: OUTPUT_HOST
value: "[Link]"

volumes:
- name: shared-logs
emptyDir: {} # Ephemeral volume — deleted when Pod dies
# Perfect for log sharing between containers

[Link] Page 11 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# Multi-Container Pod — Ambassador Pattern
# ============================================================
# Pattern: Main app + ambassador proxy
# The ambassador container proxies connections to external services,
# abstracting away the complexity of service discovery.
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: ambassador-pod
annotations:
pod-pattern: "ambassador"
spec:
containers:
- name: main-app
image: myapp:v1.0
env:
- name: DB_HOST
value: "localhost" # App connects to localhost
- name: DB_PORT
value: "5432" # Ambassador handles real routing

- name: ambassador
image: haproxy:2.8
ports:
- containerPort: 5432
volumeMounts:
- name: ambassador-config
mountPath: /usr/local/etc/haproxy

volumes:
- name: ambassador-config
configMap:
name: haproxy-config # External routing config

2.5 Annotations Deep Dive

# ============================================================
# Annotations — Complete Reference
# ============================================================
# Annotations store NON-IDENTIFYING metadata.
# Unlike labels, they CANNOT be used in selectors.
# They are used by tools, controllers, and humans.
# ============================================================

[Link] Page 12 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: v1
kind: Pod
metadata:
name: annotated-pod
labels:
app: demo # Labels → for selection (Services, Deployments)
annotations:
# --- INFORMATIONAL ANNOTATIONS ---
description: "Demo pod showing annotation types"
owner: "team-backend@[Link]"
oncall: "platform-team"
documentation: "[Link]

# --- DEPLOYMENT TRACKING ---

[Link]/change-cause: "Upgrade to v2.1 — fix memory leak"
# Visible in: kubectl rollout history
[Link]/revision: "3"

# --- MONITORING & OBSERVABILITY ---

[Link]/scrape: "true" # Prometheus auto-discovery
[Link]/port: "9090"
[Link]/path: "/metrics"

# --- SERVICE MESH (Istio) ---

[Link]/inject: "true" # Enable Istio sidecar injection
[Link]/excludeOutboundPorts: "3306"

# --- INGRESS ANNOTATIONS (used on Ingress objects) ---

# [Link]/rewrite-target: /
# [Link]/ssl-redirect: "true"

# --- SECURITY ---

[Link]/pod: "runtime/default"
[Link]/webapp: "runtime/default"

# --- CI/CD TRACKING ---

[Link]/managed-by: "argocd"
[Link]/sync-wave: "2"
[Link]/build-number: "456"
[Link]/sha: "a1b2c3d4e5f6"
[Link]/author: "dev@[Link]"
spec:
containers:
- name: demo
image: nginx:1.25-alpine

[Link] Page 13 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

3. ReplicaSet

Definition
A ReplicaSet ensures that a specified number of identical Pod replicas are running at all times. If a Pod
crashes or is deleted, the ReplicaSet controller automatically creates a new one to maintain the desired
count. It uses label selectors to identify which Pods it manages. In modern Kubernetes, ReplicaSets
are rarely created directly — they are managed by Deployments, which add rolling update capabilities
on top.

Production Usage
In production, ReplicaSets are the backbone of high availability. They guarantee that your application
always has the desired number of running instances. If a node fails, the ReplicaSet controller detects
the lost Pods and reschedules replacements on healthy nodes. You almost never create ReplicaSets
manually — Deployments create them for you.

# ============================================================
# ReplicaSet Manifest — Complete Example
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# Check: kubectl get rs
# Describe: kubectl describe rs webapp-replicaset
# ============================================================

apiVersion: apps/v1 # API group "apps", version "v1"

# ReplicaSet moved from extensions to apps/v1 in K8s 1.9
kind: ReplicaSet # Resource type
metadata:
name: webapp-replicaset # Name of the ReplicaSet
namespace: production
labels:
app: webapp
tier: frontend
spec:
replicas: 3 # DESIRED number of Pod replicas
# ReplicaSet controller ensures exactly 3 Pods run
# If one dies, a new one is created automatically

selector: # HOW the ReplicaSet finds its Pods

matchLabels: # Pods MUST have ALL these labels to be managed
app: webapp # Must match the Pod template labels below
tier: frontend
# matchExpressions: # More flexible alternative (optional)
# - key: app
# operator: In # Operators: In, NotIn, Exists, DoesNotExist

[Link] Page 14 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# values: [webapp, webapp-v2]

template: # --- POD TEMPLATE ---

# This is the blueprint for Pods created by this RS
metadata:
labels: # Labels MUST satisfy the selector above
app: webapp # If these don't match the selector, RS won't manage them
tier: frontend
spec:
containers:
- name: webapp
image: nginx:1.25-alpine
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"

# ============================================================
# KEY INTERVIEW POINTS:
# 1. ReplicaSet vs ReplicationController:
# - ReplicaSet supports set-based selectors (In, NotIn)
# - ReplicationController only supports equality-based (=, !=)
# - ReplicationController is DEPRECATED
#
# 2. ReplicaSet vs Deployment:
# - Deployment MANAGES ReplicaSets
# - Deployment adds rolling updates, rollbacks, versioning
# - NEVER create ReplicaSets directly in production
#
# 3. Scaling:
# kubectl scale rs webapp-replicaset --replicas=5
# (but better to scale the parent Deployment)
# ============================================================

4. Deployments & Deployment Strategies

Definition
A Deployment is the most common workload controller in Kubernetes. It manages ReplicaSets and
provides declarative updates to Pods — including rolling updates, rollbacks, scaling, and
pausing/resuming deployments. When you update a Deployment (e.g., change the container image), it

[Link] Page 15 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

creates a new ReplicaSet and gradually shifts traffic from the old to the new, ensuring zero-downtime
deployments. Deployment is the go-to resource for stateless applications.

Production Usage
Deployments are the standard way to deploy stateless applications in production. They enable zero-
downtime deployments via rolling updates, instant rollbacks if something goes wrong ( kubectl
rollout undo ), and horizontal scaling. Every production microservice should be deployed via a
Deployment object.

# ============================================================
# Deployment Manifest — Complete Production Example
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# Status: kubectl rollout status deployment/webapp-deployment
# History: kubectl rollout history deployment/webapp-deployment
# Rollback: kubectl rollout undo deployment/webapp-deployment
# ============================================================

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-deployment
namespace: production
labels:
app: webapp
environment: production
annotations:
[Link]/change-cause: "Deploy v1.3.0 — new dashboard feature"
# This annotation appears in rollout history
spec:
replicas: 3 # Desired Pod count

revisionHistoryLimit: 10 # Number of old ReplicaSets to retain for rollback

# Default is 10. Set to 0 to disable rollback.
# Production: Keep at least 5-10

progressDeadlineSeconds: 600 # How long to wait for rollout progress before marking fa
# Default: 600 seconds (10 minutes)

# --- DEPLOYMENT STRATEGY ---

strategy:
type: RollingUpdate # Two options: RollingUpdate (default) or Recreate
rollingUpdate:
maxUnavailable: 1 # Max Pods that can be unavailable during update
# Can be absolute number (1) or percentage (25%)
# Lower = safer but slower updates
maxSurge: 1 # Max Pods that can be created ABOVE the desired count

[Link] Page 16 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# during update. Allows running old + new simultaneously

# Higher = faster updates but more resource usage

selector:
matchLabels:
app: webapp

template:
metadata:
labels:
app: webapp
version: v1.3.0 # Track version in labels for canary routing
spec:
affinity:
podAntiAffinity: # Spread Pods across different nodes
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values: [webapp]
topologyKey: [Link]/hostname
# Each Pod prefers to be on a DIFFERENT node
# This improves fault tolerance

containers:
- name: webapp
image: [Link]/webapp:v1.3.0
ports:
- containerPort: 8080
name: http

env:
- name: APP_VERSION
value: "v1.3.0"

resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30

[Link] Page 17 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

periodSeconds: 10

readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5

lifecycle:
preStop: # Hook executed BEFORE container receives SIGTERM
exec:
command: ["/bin/sh", "-c", "sleep 10"]
# Gives time for load balancer to deregister the Pod
# before it starts shutting down

Deployment Strategies Comparison

# ============================================================
# Strategy 1: RECREATE
# ============================================================
# Kills ALL old Pods first, then creates new ones.
# Results in DOWNTIME — used for stateful apps that cannot
# tolerate two versions running simultaneously.
# ============================================================

# strategy:
# type: Recreate
#
# Timeline:
# 1. All 3 old Pods terminated simultaneously
# 2. <-- DOWNTIME WINDOW -->
# 3. 3 new Pods created and started
#
# Use when: Database schema changes, incompatible API versions,
# applications that use file locks

# ============================================================
# Strategy 2: ROLLING UPDATE (Default)
# ============================================================
# Gradually replaces old Pods with new ones.
# Zero downtime — both versions run simultaneously during update.
# ============================================================

# strategy:
# type: RollingUpdate
# rollingUpdate:

[Link] Page 18 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# maxUnavailable: 25% # At most 25% of desired Pods can be down

# maxSurge: 25% # At most 25% extra Pods during update
#
# Timeline (3 replicas):
# 1. Create 1 new Pod (v2)
# 2. Old Pod (v1) terminated after new Pod is ready
# 3. Repeat until all Pods are v2
#
# Use when: Most stateless applications, APIs, web servers

# ============================================================
# Strategy 3: BLUE/GREEN DEPLOYMENT
# ============================================================
# Not native to K8s — implemented using two Deployments + Service
# Blue = current version, Green = new version
# Switch traffic by updating Service selector
# ============================================================

# Step 1: Blue (current) Deployment is running

# Step 2: Deploy Green (new) Deployment alongside Blue
# Step 3: Test Green independently
# Step 4: Switch Service selector from Blue to Green
# Step 5: Delete Blue Deployment after verification

# --- Blue/Green: Blue Deployment (current v1) ---

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-blue # "Blue" = current production version
spec:
replicas: 3
selector:
matchLabels:
app: webapp
version: blue # Labeled as "blue" version
template:
metadata:
labels:
app: webapp
version: blue
spec:
containers:
- name: webapp
image: myapp:v1.0 # Current production image

---
# --- Blue/Green: Green Deployment (new v2) ---
apiVersion: apps/v1
kind: Deployment
metadata:

[Link] Page 19 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

name: webapp-green # "Green" = new version being tested

spec:
replicas: 3
selector:
matchLabels:
app: webapp
version: green
template:
metadata:
labels:
app: webapp
version: green
spec:
containers:
- name: webapp
image: myapp:v2.0 # New version to deploy

---
# --- Blue/Green: Service (traffic switch) ---
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
selector:
app: webapp
version: blue # ← Change to "green" to switch traffic!
# kubectl patch svc webapp-service \
# -p '{"spec":{"selector":{"version":"green"}}}'
ports:
- port: 80
targetPort: 8080

# ============================================================
# Strategy 4: CANARY DEPLOYMENT
# ============================================================
# Route a SMALL percentage of traffic to the new version.
# Monitor for errors, then gradually increase traffic.
# Implemented with multiple Deployments + shared Service,
# or using Istio/Linkerd for precise traffic splitting.
# ============================================================

# --- Canary: Stable Deployment (90% traffic) ---

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-stable
spec:
replicas: 9 # 9 out of 10 Pods = ~90% traffic
selector:

[Link] Page 20 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

matchLabels:
app: webapp
track: stable
template:
metadata:
labels:
app: webapp # Shared label with canary for Service selection
track: stable
spec:
containers:
- name: webapp
image: myapp:v1.0

---
# --- Canary: Canary Deployment (10% traffic) ---
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-canary
spec:
replicas: 1 # 1 out of 10 Pods = ~10% traffic
selector:
matchLabels:
app: webapp
track: canary
template:
metadata:
labels:
app: webapp # Same "app" label — Service selects BOTH
track: canary
spec:
containers:
- name: webapp
image: myapp:v2.0 # New version gets limited traffic

---
# --- Canary: Service (selects both stable and canary Pods) ---
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
selector:
app: webapp # Selects BOTH stable and canary Pods
# Traffic split is proportional to Pod count
# 9 stable + 1 canary = 90/10 split
ports:
- port: 80
targetPort: 8080

[Link] Page 21 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

5. Kubernetes Services

Definition
A Service is an abstract way to expose an application running on a set of Pods as a network endpoint.
Since Pods are ephemeral (they get new IPs when recreated), Services provide a stable IP and DNS
name that automatically routes traffic to healthy Pods via label selectors. Services decouple the
frontend from the backend — consumers connect to the Service, not individual Pods. There are four
types: ClusterIP (internal), NodePort (external via node ports), LoadBalancer (cloud LB), and
ExternalName (DNS alias).

Production Usage
Every microservice in production is exposed via a Service. Internal services use ClusterIP (default),
APIs exposed to the internet use LoadBalancer (in cloud) or NodePort (on-prem). Services enable
service discovery via DNS — Pods can connect to [Link]
without knowing Pod IPs.

5.1 ClusterIP Service (Default)

[Link] Page 22 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# ClusterIP Service — Internal Access Only
# ============================================================
# Creates a virtual IP accessible ONLY within the cluster.
# Used for internal service-to-service communication.
# Example: Frontend Pod → ClusterIP Service → Backend Pods
# ============================================================

apiVersion: v1
kind: Service
metadata:
name: backend-service
namespace: production
labels:
app: backend
tier: api
spec:
type: ClusterIP # DEFAULT type — can be omitted
# Accessible only within the cluster

selector: # Which Pods receive traffic from this Service

app: backend # All Pods with label "app: backend" are endpoints
tier: api

ports:
- name: http # Named port for clarity
protocol: TCP # TCP (default) or UDP
port: 80 # Port the SERVICE listens on
# Other Pods connect to backend-service:80
targetPort: 8080 # Port on the POD that receives traffic
# Can also use named port: targetPort: http
- name: grpc
protocol: TCP
port: 9090
targetPort: 9090

# sessionAffinity: ClientIP # Uncomment to enable sticky sessions

# Same client IP always goes to the same Pod
# Useful for stateful apps (websockets, sessions)

# ============================================================
# DNS resolution within the cluster:
# backend-service (same namespace)
# [Link] (cross-namespace)
# [Link] (fully qualified)
# ============================================================

[Link] Page 23 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

5.2 NodePort Service

# ============================================================
# NodePort Service — External Access via Node IP:Port
# ============================================================
# Opens a static port (30000-32767) on EVERY node in the cluster.
# Traffic to <NodeIP>:<NodePort> is forwarded to the Service.
# Used for development, on-prem clusters, or when no LB available.
# ============================================================

apiVersion: v1
kind: Service
metadata:
name: webapp-nodeport
namespace: production
spec:
type: NodePort # Exposes service on each node's IP

selector:
app: webapp

ports:
- name: http
protocol: TCP
port: 80 # Internal cluster port (ClusterIP)
targetPort: 8080 # Container port
nodePort: 30080 # External port on every node (30000-32767)
# If omitted, K8s assigns a random port in range
# Access via: [Link]

# ============================================================
# Production Notes:
# - NodePort is NOT recommended for production internet traffic
# - Limitations:
# 1. Only ports 30000-32767
# 2. One service per port
# 3. Node IP can change
# 4. No SSL termination
# - Use LoadBalancer or Ingress instead for production
# ============================================================

5.3 LoadBalancer Service

# ============================================================
# LoadBalancer Service — Cloud Provider Integration
# ============================================================

[Link] Page 24 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Provisions an EXTERNAL load balancer from the cloud provider

# (AWS ELB/NLB, GCP LB, Azure LB).
# Automatically creates NodePort and ClusterIP underneath.
# Most common way to expose services to the internet in cloud.
# ============================================================

apiVersion: v1
kind: Service
metadata:
name: webapp-loadbalancer
namespace: production
annotations:
# --- AWS-specific annotations ---
[Link]/aws-load-balancer-type: "nlb"
# Use NLB instead of classic ELB
# NLB = Layer 4, higher performance
[Link]/aws-load-balancer-scheme: "internet-facing"
# "internal" for private LB
[Link]/aws-load-balancer-ssl-cert: "arn:aws:acm:..."
# ARN of ACM certificate for SSL termination
[Link]/aws-load-balancer-backend-protocol: "http"

# --- GCP-specific annotations ---

# [Link]/load-balancer-type: "Internal"

# --- Azure-specific annotations ---

# [Link]/azure-load-balancer-internal: "true"
spec:
type: LoadBalancer

selector:
app: webapp

ports:
- name: http
protocol: TCP
port: 80 # External LB port
targetPort: 8080 # Pod port
- name: https
protocol: TCP
port: 443
targetPort: 8443

# loadBalancerSourceRanges: # Restrict access to specific IP ranges

# - "[Link]/24" # Whitelist only this CIDR
# - "[Link]/8" # And internal network

# externalTrafficPolicy: Local # Preserve client source IP

# "Cluster" (default) = may lose source IP due to SNAT
# "Local" = only route to Pods on the receiving node
# Production: Use "Local" when you need client IP

[Link] Page 25 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# How it works:
# Internet → Cloud LB (External IP) → NodePort → ClusterIP → Pod
#
# After applying, check external IP:
# kubectl get svc webapp-loadbalancer
# NAME TYPE EXTERNAL-IP PORT(S)
# webapp-loadbalancer LoadBalancer [Link] 80:31234/TCP
# ============================================================

5.4 ExternalName Service

# ============================================================
# ExternalName Service — DNS Alias
# ============================================================
# Maps a Service to an EXTERNAL DNS name (no proxying).
# Returns a CNAME record. No selector, no ports, no endpoints.
# Used to reference external services (databases, APIs) with
# a stable internal K8s DNS name.
# ============================================================

apiVersion: v1
kind: Service
metadata:
name: external-database
namespace: production
spec:
type: ExternalName
externalName: [Link] # External DNS name
# Pods can connect to:
# [Link]
# K8s DNS returns CNAME → [Link]

# ============================================================
# Use case:
# Your app connects to "external-database:5432"
# Later, if you migrate the DB into the cluster, just change
# this Service to a ClusterIP type — app code stays the same!
# ============================================================

6. Ingress & Ingress Controller

[Link] Page 26 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Definition
Ingress is a Kubernetes resource that manages external HTTP/HTTPS access to services within the
cluster. It provides URL-based routing, SSL termination, virtual hosting (multiple domains), and load
balancing — all through a single entry point. Unlike LoadBalancer Services (one LB per service), Ingress
routes traffic for multiple services through a single load balancer, saving cost. An Ingress Controller
(e.g., NGINX, Traefik, HAProxy) is the actual component that implements the Ingress rules — without it,
Ingress resources have no effect.

Production Usage
Ingress is the standard way to expose HTTP/HTTPS services in production. It replaces the need for
multiple LoadBalancer Services (which create one cloud LB each, costing money). A single Ingress
Controller handles all external traffic routing. Common controllers: NGINX Ingress Controller (most
popular), Traefik (auto-discovery), AWS ALB Ingress Controller (native AWS integration).

# ============================================================
# Ingress Manifest — Complete Production Example
# ============================================================
# File: [Link]
# Prerequisites: An Ingress Controller must be deployed first!
# kubectl apply -f [Link]
# ingress-nginx/controller-v1.9.0/deploy/static/provider/cloud/[Link]
# ============================================================

apiVersion: [Link]/v1 # Ingress API group

kind: Ingress
metadata:
name: webapp-ingress
namespace: production
labels:
app: webapp
annotations:
# --- NGINX Ingress Controller Annotations ---
[Link]/rewrite-target: /
# Rewrite the URL path before forwarding
# /api/v1/users → /users (strips prefix)

[Link]/ssl-redirect: "true"
# Force HTTP → HTTPS redirect

[Link]/proxy-body-size: "50m"
# Max upload size (default: 1m)

[Link]/rate-limit: "10"
# Rate limiting: 10 requests/second per IP

[Link]/proxy-connect-timeout: "30"
[Link]/proxy-read-timeout: "60"

[Link] Page 27 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# --- TLS with cert-manager (auto SSL) ---

[Link]/cluster-issuer: "letsencrypt-prod"
# Automatically provision SSL certificates
# using Let's Encrypt via cert-manager

# --- AWS ALB Annotations (if using AWS ALB Controller) ---
# [Link]/[Link]: alb
# [Link]/scheme: internet-facing
# [Link]/target-type: ip

spec:
ingressClassName: nginx # Which Ingress Controller handles this
# Replaces the deprecated annotation:
# [Link]/[Link]: nginx

tls: # --- TLS / HTTPS CONFIGURATION ---

- hosts:
- [Link] # Domain(s) covered by this certificate
- [Link]
secretName: webapp-tls-secret
# K8s Secret containing TLS cert and key
# Created by cert-manager or manually:
# kubectl create secret tls webapp-tls-secret \
# --cert=[Link] --key=[Link]

rules: # --- ROUTING RULES ---

# Rule 1: Route [Link] traffic
- host: [Link] # Virtual host (domain-based routing)
http:
paths:
- path: / # URL path to match
pathType: Prefix # Matching type:
# Prefix — matches /foo, /foo/bar, etc.
# Exact — matches only the exact path
# ImplementationSpecific — depends on controller
backend:
service:
name: webapp-service # Forward to this Service
port:
number: 80 # Service port

- path: /api
pathType: Prefix
backend:
service:
name: api-service # /api/* goes to a different Service
port:
number: 8080

# Rule 2: Route [Link] traffic

[Link] Page 28 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

- host: [Link]
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 8080

# defaultBackend: # Catch-all for unmatched requests

# service:
# name: default-service
# port:
# number: 80

# ============================================================
# How it works:
#
# Internet → Ingress Controller (NGINX Pod) → Ingress Rules
# → Route to correct Service → Pod
#
# Single IP/LB handles ALL domains and paths!
# Much cheaper than one LoadBalancer Service per app.
# ============================================================

7. ConfigMap & Secrets

Definition
ConfigMap stores non-confidential configuration data as key-value pairs, decoupling configuration
from container images. Secrets store sensitive data (passwords, tokens, keys) in base64-encoded
format with additional access controls. Both can be consumed by Pods as environment variables,
command-line arguments, or mounted as files. The key principle: configuration and secrets should
never be baked into container images — they should be injected at runtime through ConfigMaps and
Secrets.

Production Usage
ConfigMaps store application config (database URLs, feature flags, config files like [Link]). Secrets
store credentials (DB passwords, API keys, TLS certificates). In production, Secrets should be
encrypted at rest (enable EncryptionConfiguration on the API server) and managed via external
secret managers (HashiCorp Vault, AWS Secrets Manager) using tools like External Secrets Operator.

[Link] Page 29 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# ConfigMap — Key-Value Configuration
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# View: kubectl get configmap app-config -o yaml
# ============================================================

apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: production
labels:
app: webapp
data: # Key-value pairs (plain text)
# --- Simple key-value pairs ---
database_host: "[Link]"
database_port: "5432"
database_name: "webapp_db"
log_level: "info"
feature_flag_dark_mode: "true"
max_connections: "100"

# --- Full config file embedded as a multi-line value ---

[Link]: |
server {
listen 80;
server_name [Link];
location / {
proxy_pass [Link]
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}

[Link]: |
[Link]=jdbc:postgresql://postgres:5432/webapp_db
[Link]-auto=update
[Link]=8080

---
# ============================================================
# Secret — Sensitive Data (Base64 Encoded)
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# SECURITY: Secrets are base64 encoded, NOT encrypted!
# Enable encryption at rest for production security.
# ============================================================

[Link] Page 30 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: v1
kind: Secret
metadata:
name: app-secrets
namespace: production
labels:
app: webapp
type: Opaque # Secret types:
# Opaque — generic secret (most common)
# [Link]/dockerconfigjson — Docker registry auth
# [Link]/tls — TLS certificate + key
# [Link]/basic-auth — username/password
# [Link]/ssh-auth — SSH private key

data: # Values MUST be base64 encoded

# echo -n 'mypassword' | base64
db-password: bXlwYXNzd29yZA== # base64 of "mypassword"
api-key: YWJjZGVmZzEyMzQ1Ng== # base64 of "abcdefg123456"
jwt-secret: c3VwZXJfc2VjcmV0X2tleQ==

# Alternative: use stringData (plain text, auto-encoded)

# stringData: # K8s automatically base64-encodes these
# db-password: "mypassword" # More readable, same result
# api-key: "abcdefg123456"

---
# ============================================================
# TLS Secret — For Ingress HTTPS
# ============================================================

apiVersion: v1
kind: Secret
metadata:
name: webapp-tls-secret
namespace: production
type: [Link]/tls # Special type for TLS secrets
data:
[Link]: LS0tLS1CRUdJ... # base64-encoded TLS certificate
[Link]: LS0tLS1CRUdJ... # base64-encoded TLS private key

# CLI alternative:
# kubectl create secret tls webapp-tls-secret \
# --cert=path/to/[Link] \
# --key=path/to/[Link] \
# -n production

---
# ============================================================
# Docker Registry Secret — Pull Private Images
# ============================================================

[Link] Page 31 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: v1
kind: Secret
metadata:
name: docker-registry-creds
namespace: production
type: [Link]/dockerconfigjson
data:
.dockerconfigjson: eyJhdXRocyI6... # base64 of Docker config JSON

# CLI alternative (easier):

# kubectl create secret docker-registry docker-registry-creds \
# --docker-server=[Link] \
# --docker-username=user \
# --docker-password=pass \
# -n production

# ============================================================
# Using ConfigMap & Secrets in a Pod
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: app-with-config
spec:
containers:
- name: app
image: myapp:v1.0

# --- Method 1: Environment Variables ---

env:
- name: DB_HOST
valueFrom:
configMapKeyRef: # Single key from ConfigMap
name: app-config
key: database_host

- name: DB_PASSWORD
valueFrom:
secretKeyRef: # Single key from Secret
name: app-secrets
key: db-password

# --- Method 2: Load ALL keys as environment variables ---

envFrom:
- configMapRef: # Every key in ConfigMap → env var
name: app-config
- secretRef: # Every key in Secret → env var
name: app-secrets
# prefix: SECRET_ # Optional: prefix all keys

[Link] Page 32 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# --- Method 3: Mount as Files ---

volumeMounts:
- name: config-volume
mountPath: /etc/app/config # ConfigMap keys become files
readOnly: true
- name: secret-volume
mountPath: /etc/app/secrets # Secret keys become files
readOnly: true
- name: nginx-config
mountPath: /etc/nginx/[Link]
subPath: [Link] # Mount SINGLE file, not whole directory
readOnly: true

volumes:
- name: config-volume
configMap:
name: app-config
- name: secret-volume
secret:
secretName: app-secrets
defaultMode: 0400 # File permissions (read-only by owner)
- name: nginx-config
configMap:
name: app-config
items: # Select specific keys
- key: [Link] # ConfigMap key
path: [Link] # Filename in the mount

imagePullSecrets: # Use Docker registry secret

- name: docker-registry-creds

8. Namespaces

Definition
A Namespace is a virtual cluster within a Kubernetes cluster that provides logical isolation for
resources. Namespaces allow multiple teams, projects, or environments to share the same physical
cluster while maintaining separation of resources, access control (RBAC), and resource quotas.
Resources within a namespace must have unique names, but the same name can exist across different
namespaces. Cluster-scoped resources (Nodes, PersistentVolumes, ClusterRoles) are NOT
namespaced.

Production Usage

[Link] Page 33 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Production clusters use namespaces to separate environments ( dev , staging , production ),

teams ( team-frontend , team-backend ), or applications ( payment-service , auth-service ).
Combined with ResourceQuotas and NetworkPolicies, namespaces enforce resource limits and
network isolation between teams.

# ============================================================
# Namespace Manifest
# ============================================================

apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
environment: production # Used by NetworkPolicies to target this namespace
team: platform
annotations:
description: "Production environment for all microservices"

---
# ============================================================
# ResourceQuota — Limit Resources per Namespace
# ============================================================
# Prevents a single team/namespace from consuming all cluster resources.
# ============================================================

apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
# --- Compute Resources ---
[Link]: "20" # Total CPU requests across all Pods: 20 cores
[Link]: "40Gi" # Total memory requests: 40 GiB
[Link]: "40" # Total CPU limits: 40 cores
[Link]: "80Gi" # Total memory limits: 80 GiB

# --- Object Count Limits ---

pods: "100" # Max 100 Pods in this namespace
services: "20" # Max 20 Services
secrets: "50" # Max 50 Secrets
configmaps: "50"
persistentvolumeclaims: "30"

# --- Storage ---

[Link]: "500Gi" # Total storage requests

---

[Link] Page 34 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# LimitRange — Default Resource Limits for Pods
# ============================================================
# Sets default requests/limits for containers that don't specify them.
# Also enforces min/max per container.
# ============================================================

apiVersion: v1
kind: LimitRange
metadata:
name: production-limits
namespace: production
spec:
limits:
- type: Container
default: # Default LIMITS (if container doesn't specify)
cpu: "500m"
memory: "256Mi"
defaultRequest: # Default REQUESTS (if container doesn't specify)
cpu: "100m"
memory: "128Mi"
max: # Maximum any single container can request
cpu: "4"
memory: "8Gi"
min: # Minimum any single container must request
cpu: "50m"
memory: "64Mi"

---
# ============================================================
# NetworkPolicy — Namespace Isolation
# ============================================================
# Restrict network traffic between namespaces.
# By default, all Pods can communicate with all other Pods.
# NetworkPolicy changes this to explicit allow-listing.
# ============================================================

apiVersion: [Link]/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
namespace: production
spec:
podSelector: {} # Apply to ALL Pods in this namespace
policyTypes:
- Ingress # Control incoming traffic
ingress: [] # Empty = deny ALL ingress traffic
# Only traffic from explicitly allowed sources
# will be permitted (add rules below)

---

[Link] Page 35 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: [Link]/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: production
spec:
podSelector:
matchLabels:
tier: backend # Apply to backend Pods
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
tier: frontend # Allow traffic FROM frontend Pods
- namespaceSelector:
matchLabels:
environment: production # Only from production namespace
ports:
- protocol: TCP
port: 8080

9. Kubernetes Volumes

Definition
Volumes in Kubernetes provide persistent or shared storage for containers within a Pod. Unlike
container filesystem (ephemeral — lost when container restarts), Volumes persist across container
restarts within the Pod lifecycle. PersistentVolume (PV) is a cluster-level storage resource provisioned
by an admin. PersistentVolumeClaim (PVC) is a user's request for storage — it binds to a matching
PV. StorageClass enables dynamic provisioning — PVs are automatically created when a PVC is
submitted.

Production Usage
In production, dynamic provisioning via StorageClasses is the standard. Admins create
StorageClasses (e.g., gp3 for AWS EBS, pd-ssd for GCP). Developers create PVCs referencing the
StorageClass, and PVs are auto-provisioned. Reclaim Policies determine what happens to the PV
when the PVC is deleted: Retain (keep data), Delete (destroy data), Recycle (deprecated).

# ============================================================
# StorageClass — Dynamic Volume Provisioning
# ============================================================

[Link] Page 36 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Defines HOW storage is provisioned dynamically.

# When a PVC references this StorageClass, a PV is auto-created.
# ============================================================

apiVersion: [Link]/v1
kind: StorageClass
metadata:
name: fast-storage # Name referenced by PVCs
annotations:
[Link]/is-default-class: "true"
# If true, PVCs without a storageClassName use this
provisioner: [Link] # CSI driver for the storage backend
# Examples:
# [Link] — AWS EBS
# [Link] — GCP Persistent Disk
# [Link] — Azure Disk
# [Link]/no-provisioner — manual (local storage)
parameters:
type: gp3 # AWS EBS volume type (gp3, io2, etc.)
fsType: ext4 # Filesystem type
encrypted: "true" # Enable encryption at rest
# iopsPerGB: "50" # For io1/io2 volumes

reclaimPolicy: Retain # What happens when PVC is deleted:

# Retain — PV and data preserved (manual cleanup)
# Delete — PV and underlying storage deleted
# Recycle — deprecated, don't use
# Production: Use "Retain" for important data

volumeBindingMode: WaitForFirstConsumer
# When to bind PV to PVC:
# Immediate — bind as soon as PVC created
# WaitForFirstConsumer — bind when Pod using PVC is sch
# "WaitForFirstConsumer" is BETTER for topology-aware sto
# (ensures PV is created in the same AZ as the Pod)

allowVolumeExpansion: true # Allow PVCs to request more storage later

# kubectl edit pvc → increase [Link]

mountOptions: # Mount options for the filesystem

- discard
- noatime

---
# ============================================================
# PersistentVolume (PV) — Cluster-Level Storage Resource
# ============================================================
# Usually auto-created by StorageClass (dynamic provisioning).
# Manual creation is for: local storage, pre-existing volumes,
# or on-prem clusters without dynamic provisioning.
# ============================================================

[Link] Page 37 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: v1
kind: PersistentVolume
metadata:
name: database-pv
labels:
type: database
environment: production
spec:
capacity:
storage: 100Gi # Size of the volume

accessModes: # How the volume can be mounted:

- ReadWriteOnce # ReadWriteOnce (RWO) — single node read-write
# ReadOnlyMany (ROX) — multiple nodes read-only
# ReadWriteMany (RWX) — multiple nodes read-write
# ReadWriteOncePod (RWOP) — single Pod read-write (K8s
# Most block storage (EBS, PD) only supports RWO
# EFS, NFS support RWX

persistentVolumeReclaimPolicy: Retain # Same as StorageClass reclaimPolicy

storageClassName: fast-storage # Link to a StorageClass

# --- Backend-specific configuration ---

# For AWS EBS:
csi:
driver: [Link]
volumeHandle: vol-0abc123def456 # AWS volume ID (for pre-existing volumes)
fsType: ext4

# For NFS:
# nfs:
# server: [Link]
# path: /exports/data

# For hostPath (single-node testing ONLY — NOT for production):

# hostPath:
# path: /mnt/data
# type: DirectoryOrCreate

nodeAffinity: # Restrict which nodes can access this PV

required:
nodeSelectorTerms:
- matchExpressions:
- key: [Link]/zone
operator: In
values:
- us-east-1a # PV is in this availability zone

---

[Link] Page 38 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# PersistentVolumeClaim (PVC) — User's Storage Request
# ============================================================
# The developer creates a PVC; K8s binds it to a matching PV
# (either pre-existing or dynamically provisioned).
# ============================================================

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-pvc
namespace: production
labels:
app: database
spec:
accessModes:
- ReadWriteOnce # Must match or be subset of PV accessModes

resources:
requests:
storage: 50Gi # Requested storage size
# PV capacity must be >= this value
# With dynamic provisioning, PV is created at this size

storageClassName: fast-storage # Which StorageClass to use

# "" (empty string) = use a manually created PV
# Omitted = use the default StorageClass

# selector: # Optional: select specific PV by labels

# matchLabels:
# type: database

---
# ============================================================
# Pod Using PVC
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: database-pod
namespace: production
spec:
containers:
- name: postgres
image: postgres:16-alpine
ports:
- containerPort: 5432
env:
- name: POSTGRES_PASSWORD
valueFrom:

[Link] Page 39 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

secretKeyRef:
name: db-secrets
key: password
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
volumeMounts:
- name: db-storage
mountPath: /var/lib/postgresql/data # Mount PVC here

volumes:
- name: db-storage
persistentVolumeClaim:
claimName: database-pvc # Reference the PVC by name

[Link] Page 40 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# Volume Types Quick Reference
# ============================================================

# emptyDir — Ephemeral volume, created when Pod starts, deleted when Pod dies
# volumes:
# - name: temp-data
# emptyDir: {} # Uses node's disk
# - name: cache
# emptyDir:
# medium: Memory # Uses RAM (tmpfs) — faster but limited
# sizeLimit: 256Mi

# hostPath — Mounts a file/directory from the node's filesystem

# volumes:
# - name: host-data
# hostPath:
# path: /var/log # Path on the HOST node
# type: Directory # Must be an existing directory

# configMap — Mount ConfigMap as files

# volumes:
# - name: config
# configMap:
# name: my-config

# secret — Mount Secret as files

# volumes:
# - name: secrets
# secret:
# secretName: my-secret
# defaultMode: 0400 # File permissions

# projected — Combine multiple volume sources into one mount

# volumes:
# - name: combined
# projected:
# sources:
# - configMap:
# name: app-config
# - secret:
# name: app-secrets
# - downwardAPI: # Pod metadata as files
# items:
# - path: "labels"
# fieldRef:
# fieldPath: [Link]

[Link] Page 41 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

10. RBAC — Role Based Access Control

Definition
RBAC (Role-Based Access Control) controls who can perform what actions on which Kubernetes
resources. It uses four objects: Role (namespace-scoped permissions), ClusterRole (cluster-scoped
permissions), RoleBinding (assigns a Role to users/groups/service accounts within a namespace), and
ClusterRoleBinding (assigns a ClusterRole cluster-wide). RBAC follows the principle of least privilege
— grant only the minimum permissions required.

Production Usage
RBAC is critical for multi-tenant clusters. In production, each team gets a Role with access only to their
namespace. CI/CD pipelines use ServiceAccounts with specific permissions. Admins use ClusterRoles
for cluster-wide operations. Always disable anonymous access and audit RBAC policies regularly.

# ============================================================
# ServiceAccount — Identity for Pods
# ============================================================
# Every Pod runs as a ServiceAccount. If not specified, uses "default".
# Production: ALWAYS create dedicated ServiceAccounts.
# ============================================================

apiVersion: v1
kind: ServiceAccount
metadata:
name: webapp-sa
namespace: production
labels:
app: webapp
annotations:
# AWS: Link to IAM Role for AWS API access (IRSA)
[Link]/role-arn: "arn:aws:iam::123456789:role/webapp-role"
automountServiceAccountToken: true # Mount API token in Pod
# Set to false if Pod doesn't need K8s API access

---
# ============================================================
# Role — Namespace-Scoped Permissions
# ============================================================
# Defines WHAT actions are allowed on WHICH resources
# within a SPECIFIC namespace.
# ============================================================

apiVersion: [Link]/v1
kind: Role
metadata:

[Link] Page 42 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

name: webapp-role
namespace: production
rules:
- apiGroups: [""] # "" = core API group (Pods, Services, ConfigMaps)
resources: ["pods"] # Resource types
verbs: ["get", "list", "watch"] # Allowed actions
# All verbs: get, list, watch, create, update,
# patch, delete, deletecollection

- apiGroups: [""]
resources: ["services", "configmaps"]
verbs: ["get", "list"]

- apiGroups: ["apps"] # "apps" API group (Deployments, ReplicaSets)

resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch"]

- apiGroups: [""]
resources: ["pods/log"] # Sub-resource: Pod logs
verbs: ["get"]

- apiGroups: [""]
resources: ["pods/exec"] # Sub-resource: exec into Pods
verbs: ["create"] # kubectl exec requires "create" on pods/exec

---
# ============================================================
# RoleBinding — Assign Role to Users/ServiceAccounts
# ============================================================
# Links a Role to subjects (users, groups, service accounts)
# within a namespace.
# ============================================================

apiVersion: [Link]/v1
kind: RoleBinding
metadata:
name: webapp-rolebinding
namespace: production
subjects:
- kind: ServiceAccount # Subject type: User, Group, ServiceAccount
name: webapp-sa # ServiceAccount name
namespace: production # SA's namespace

- kind: User # Kubernetes User (from certificate CN)

name: john@[Link]
apiGroup: [Link]

- kind: Group # Kubernetes Group (from certificate O)

name: dev-team
apiGroup: [Link]

[Link] Page 43 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

roleRef: # Which Role to bind

kind: Role # Role or ClusterRole
name: webapp-role # Name of the Role
apiGroup: [Link]

---
# ============================================================
# ClusterRole — Cluster-Scoped Permissions
# ============================================================
# Like Role but applies across ALL namespaces.
# Also used for cluster-scoped resources (Nodes, PVs, Namespaces).
# ============================================================

apiVersion: [Link]/v1
kind: ClusterRole
metadata:
name: cluster-monitoring
rules:
- apiGroups: [""]
resources: ["nodes", "namespaces", "persistentvolumes"]
verbs: ["get", "list", "watch"] # Read-only cluster-wide access

- apiGroups: ["[Link]"]
resources: ["nodes", "pods"]
verbs: ["get", "list"] # Access to metrics API

- nonResourceURLs: ["/healthz", "/metrics"] # Non-resource endpoints

verbs: ["get"]

---
# ============================================================
# ClusterRoleBinding — Cluster-Wide Role Assignment
# ============================================================

apiVersion: [Link]/v1
kind: ClusterRoleBinding
metadata:
name: monitoring-binding
subjects:
- kind: ServiceAccount
name: monitoring-sa
namespace: monitoring # SA from the monitoring namespace
roleRef:
kind: ClusterRole
name: cluster-monitoring
apiGroup: [Link]

[Link] Page 44 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

11. DaemonSet

Definition
A DaemonSet ensures that a copy of a specific Pod runs on every node (or a subset of nodes) in the
cluster. When a new node is added, a DaemonSet Pod is automatically scheduled on it. When a node is
removed, the DaemonSet Pod is garbage collected. Unlike Deployments (which run N replicas
anywhere), DaemonSets run exactly one Pod per node — they are used for node-level infrastructure
services.

Production Usage
DaemonSets are used for infrastructure services that must run on every node: log collectors (Fluentd,
Fluent Bit), monitoring agents (Prometheus Node Exporter, Datadog Agent), network plugins (Calico,
Cilium), and storage drivers (CSI plugins). They are essential for cluster-wide observability and
networking.

# ============================================================
# DaemonSet Manifest — Log Collector Example
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# Check: kubectl get ds -n kube-system
# ============================================================

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-daemonset
namespace: kube-system # Infrastructure components often run here
labels:
app: fluentd
purpose: log-collection
spec:
selector:
matchLabels:
app: fluentd

updateStrategy:
type: RollingUpdate # How to update DaemonSet Pods:
# RollingUpdate — one node at a time (default)
# OnDelete — only update when manually deleted
rollingUpdate:
maxUnavailable: 1 # Max Pods updated simultaneously
# Use 1 for critical infrastructure
# Use higher for faster rollouts

[Link] Page 45 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

template:
metadata:
labels:
app: fluentd
spec:
tolerations: # IMPORTANT for DaemonSets:
# By default, master/control-plane nodes have taints
# that prevent scheduling. Add tolerations to
# run on ALL nodes including masters.
- key: [Link]/control-plane
operator: Exists
effect: NoSchedule
- key: [Link]/master
operator: Exists
effect: NoSchedule

# nodeSelector: # Optional: Run only on specific nodes

# monitoring: enabled

serviceAccountName: fluentd-sa

containers:
- name: fluentd
image: fluent/fluentd-kubernetes-daemonset:v1.16

env:
- name: FLUENT_ELASTICSEARCH_HOST
value: "[Link]"
- name: FLUENT_ELASTICSEARCH_PORT
value: "9200"
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: [Link] # Inject the node name as env var

resources:
requests:
cpu: "100m"
memory: "200Mi"
limits:
cpu: "500m"
memory: "500Mi"

volumeMounts:
- name: varlog
mountPath: /var/log # Access host's /var/log
readOnly: true
- name: containers-log
mountPath: /var/lib/docker/containers
readOnly: true
- name: fluentd-config

[Link] Page 46 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

mountPath: /fluentd/etc

terminationGracePeriodSeconds: 30

volumes:
- name: varlog
hostPath:
path: /var/log # Host's log directory
- name: containers-log
hostPath:
path: /var/lib/docker/containers
- name: fluentd-config
configMap:
name: fluentd-config

# ============================================================
# DaemonSet vs Deployment:
# Deployment: "Run N replicas wherever there's capacity"
# DaemonSet: "Run exactly 1 Pod on every (selected) node"
#
# Common DaemonSet use cases:
# - Log collection (Fluentd, Fluent Bit, Filebeat)
# - Monitoring agents (Node Exporter, Datadog, New Relic)
# - Network plugins (Calico, Cilium, kube-proxy)
# - Storage plugins (CSI drivers)
# - Security agents (Falco, Aqua)
# ============================================================

12. StatefulSet

Definition
A StatefulSet manages stateful applications that require stable network identities, persistent
storage, and ordered deployment/scaling. Unlike Deployments (where Pods are interchangeable),
StatefulSet Pods get predictable names ( app-0 , app-1 , app-2 ), stable DNS hostnames, and
dedicated PersistentVolumes that survive Pod restarts. Pods are created in order (0→1→2) and deleted
in reverse (2→1→0), ensuring proper startup and shutdown sequences.

Production Usage
StatefulSets are used for databases (PostgreSQL, MySQL, MongoDB), message queues (Kafka,
RabbitMQ), distributed systems (Elasticsearch, Cassandra, ZooKeeper), and any application where
identity and storage must persist across restarts. They are paired with Headless Services for DNS-
based peer discovery.

[Link] Page 47 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# StatefulSet Manifest — PostgreSQL Cluster
# ============================================================
# File: [Link]
# Apply: kubectl apply -f [Link]
# ============================================================

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
namespace: production
labels:
app: postgres
spec:
serviceName: postgres-headless # REQUIRED: Name of the Headless Service
# This creates DNS records:
# [Link].l
# [Link].l
# [Link].l

replicas: 3 # 3 PostgreSQL instances (primary + replicas)

selector:
matchLabels:
app: postgres

# --- Ordering Guarantees ---

podManagementPolicy: OrderedReady
# OrderedReady (default):
# - Pods created sequentially: 0 → 1 → 2
# - Pod N+1 not created until Pod N is Ready
# - Pods deleted in reverse: 2 → 1 → 0
# Parallel:
# - All Pods created/deleted simultaneously
# - Use for applications that don't need ordering

updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 0 # Only update Pods with ordinal >= partition
# partition: 2 → only Pod 2 gets updated (canary)
# partition: 0 → all Pods updated (normal)

template:
metadata:
labels:
app: postgres
spec:
serviceAccountName: postgres-sa

[Link] Page 48 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

initContainers:
- name: init-permissions
image: busybox:1.36
command: ["sh", "-c", "chown -R 999:999 /var/lib/postgresql/data"]
volumeMounts:
- name: postgres-data
mountPath: /var/lib/postgresql/data

containers:
- name: postgres
image: postgres:16-alpine
ports:
- containerPort: 5432
name: postgres

env:
- name: POSTGRES_DB
value: "appdb"
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgres-secrets
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgres-secrets
key: password
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: [Link] # "postgres-0", "postgres-1", etc.

resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "2"
memory: "4Gi"

volumeMounts:
- name: postgres-data
mountPath: /var/lib/postgresql/data

livenessProbe:
exec:
command: ["pg_isready", "-U", "postgres"]
initialDelaySeconds: 30

[Link] Page 49 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

periodSeconds: 10

readinessProbe:
exec:
command: ["pg_isready", "-U", "postgres"]
initialDelaySeconds: 5
periodSeconds: 5

# --- Volume Claim Templates ---

# Unlike Deployments, StatefulSets use volumeClaimTemplates
# to create a UNIQUE PVC for EACH Pod
volumeClaimTemplates:
- metadata:
name: postgres-data # PVC names: postgres-data-postgres-0,
# postgres-data-postgres-1,
# postgres-data-postgres-2
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: fast-storage
resources:
requests:
storage: 50Gi

# ============================================================
# StatefulSet vs Deployment:
#
# Feature Deployment StatefulSet
# ──────────────────── ────────────────── ──────────────────
# Pod names Random (abc-xyz) Ordinal (app-0,1,2)
# Storage Shared PVC Unique PVC per Pod
# DNS Via Service only Per-Pod DNS names
# Scaling order Parallel Sequential
# Use case Stateless apps Databases, queues
#
# When StatefulSet Pods are deleted:
# - PVCs are NOT deleted (data is preserved)
# - When Pod is recreated, it rebinds to the SAME PVC
# - This ensures data persistence across restarts
# ============================================================

13. Headless Services

Definition
A Headless Service is a Service with clusterIP: None . Instead of providing a single virtual IP that
load-balances traffic, it creates individual DNS records for each Pod behind it. This enables clients to

[Link] Page 50 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

discover and connect to specific Pods directly, which is essential for StatefulSet applications where
each Pod has a unique identity (e.g., database primary vs replica). DNS resolution returns all Pod IPs
instead of a single Service IP.

Production Usage
Headless Services are always paired with StatefulSets for applications like databases (PostgreSQL,
MySQL clusters), distributed caches (Redis Cluster), and message brokers (Kafka, ZooKeeper). They
enable peer discovery — e.g., a Kafka broker at [Link]-
[Link] can discover kafka-1 and kafka-2 for cluster
formation.

[Link] Page 51 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# Headless Service Manifest
# ============================================================
# A Headless Service does NOT allocate a Cluster IP.
# Instead, it creates DNS A records for each individual Pod.
# ============================================================

apiVersion: v1
kind: Service
metadata:
name: postgres-headless
namespace: production
labels:
app: postgres
spec:
clusterIP: None # THIS makes it a Headless Service
# No virtual IP is assigned
# DNS resolves to individual Pod IPs

selector:
app: postgres # Selects StatefulSet Pods

ports:
- name: postgres
port: 5432
targetPort: 5432

# ============================================================
# DNS Resolution Comparison:
#
# Regular ClusterIP Service:
# nslookup postgres-service → [Link] (single VIP)
#
# Headless Service:
# nslookup postgres-headless →
# [Link] (postgres-0)
# [Link] (postgres-1)
# [Link] (postgres-2)
#
# Per-Pod DNS (with StatefulSet):
# [Link] → [Link]
# [Link] → [Link]
# [Link] → [Link]
#
# This enables:
# - Direct connection to a specific database replica
# - Peer discovery in distributed systems
# - Client-side load balancing
# ============================================================

[Link] Page 52 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

14. Autoscaling

Definition
Autoscaling in Kubernetes automatically adjusts resource capacity based on demand. Horizontal Pod
Autoscaler (HPA) scales the number of Pod replicas based on CPU, memory, or custom metrics.
Vertical Pod Autoscaler (VPA) adjusts CPU/memory requests and limits of existing Pods. Cluster
Autoscaler adds or removes worker nodes based on pending Pods. Together, these ensure your
application handles traffic spikes without over-provisioning (wasting money) or under-provisioning
(causing outages).

Production Usage
HPA is the most commonly used — it scales web services based on CPU/request metrics during traffic
spikes. VPA is used for batch jobs and workloads with unpredictable resource patterns. Cluster
Autoscaler is essential in cloud environments to dynamically add nodes when Pods can't be scheduled.
HPA + Cluster Autoscaler is the most common production combination.

# ============================================================
# Horizontal Pod Autoscaler (HPA) — Scale Pod Count
# ============================================================
# File: [Link]
# Prerequisites: Metrics Server must be installed
# kubectl apply -f [Link]
# metrics-server/releases/latest/download/[Link]
# Check: kubectl get hpa
# ============================================================

apiVersion: autoscaling/v2 # v2 supports custom metrics

# v1 only supports CPU
kind: HorizontalPodAutoscaler
metadata:
name: webapp-hpa
namespace: production
spec:
scaleTargetRef: # WHAT to scale
apiVersion: apps/v1
kind: Deployment # Can be Deployment, ReplicaSet, StatefulSet
name: webapp-deployment # Name of the target Deployment

minReplicas: 3 # Minimum Pod count (never go below this)

# Production: Set to handle your baseline traffic
maxReplicas: 20 # Maximum Pod count (cost protection)
# Production: Set based on budget & node capacity

[Link] Page 53 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

metrics: # WHEN to scale — based on these metrics

# --- CPU-Based Scaling ---
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # Scale up when average CPU > 70%
# Scale down when average CPU < 70%
# Production: 60-80% is typical

# --- Memory-Based Scaling ---

- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80 # Scale up when average memory > 80%

# --- Custom Metrics (e.g., requests per second) ---

# Requires Prometheus Adapter or KEDA
# - type: Pods
# pods:
# metric:
# name: http_requests_per_second
# target:
# type: AverageValue
# averageValue: 1000 # Scale up when avg RPS > 1000

behavior: # Fine-tune scaling behavior

scaleUp:
stabilizationWindowSeconds: 30
# Wait 30s after a scale-up event before scaling again
# Prevents rapid scaling from traffic spikes
policies:
- type: Percent
value: 100 # Can double Pod count in one scale-up
periodSeconds: 60
- type: Pods
value: 4 # Or add max 4 Pods per minute
periodSeconds: 60
selectPolicy: Max # Use whichever policy allows MORE scaling

scaleDown:
stabilizationWindowSeconds: 300
# Wait 5 minutes before scaling down
# Prevents flapping (scale up → down → up)
# Production: Set to 5-10 minutes
policies:
- type: Percent
value: 10 # Remove max 10% of Pods per period

[Link] Page 54 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

periodSeconds: 60
selectPolicy: Min # Use whichever policy allows LESS scaling
# Conservative scale-down prevents disruption

# ============================================================
# HPA Commands:
# kubectl get hpa # View HPA status
# kubectl describe hpa webapp-hpa # Detailed info with events
# kubectl top pods # See current resource usage
#
# How HPA calculates desired replicas:
# desiredReplicas = ceil(currentReplicas × (currentMetric / targetMetric))
# Example: 3 replicas, CPU at 90%, target 70%
# desired = ceil(3 × (90/70)) = ceil(3.86) = 4 replicas
# ============================================================

[Link] Page 55 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# Vertical Pod Autoscaler (VPA) — Adjust Resource Requests
# ============================================================
# VPA adjusts CPU/memory requests and limits of Pods.
# It analyzes historical usage and recommends optimal values.
# NOTE: VPA and HPA should NOT target the same metric (CPU/memory).
# ============================================================

apiVersion: [Link]/v1
kind: VerticalPodAutoscaler
metadata:
name: webapp-vpa
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: webapp-deployment

updatePolicy:
updateMode: "Auto" # Modes:
# "Off" — Only recommendations, no action
# "Initial" — Set on Pod creation, no live update
# "Recreate" — Kill & recreate Pods with new values
# "Auto" — Same as Recreate (for now)
# Production: Start with "Off" to review recommendations

resourcePolicy:
containerPolicies:
- containerName: webapp
minAllowed: # Don't go below these values
cpu: "100m"
memory: "128Mi"
maxAllowed: # Don't exceed these values
cpu: "4"
memory: "8Gi"
controlledResources: ["cpu", "memory"]

# ============================================================
# Check VPA recommendations:
# kubectl describe vpa webapp-vpa
# Look for: "recommendation" section with target/lower/upper bounds
# ============================================================

15. Scheduling

[Link] Page 56 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Definition
Kubernetes Scheduling is the process of assigning Pods to Nodes. The scheduler considers resource
requirements, constraints (taints/tolerations, affinity rules, node selectors), and priorities. Taints and
Tolerations work together — taints on nodes repel Pods; tolerations on Pods allow them to be
scheduled on tainted nodes. Node Affinity attracts Pods to specific nodes. Pod Affinity/Anti-Affinity
controls Pod placement relative to other Pods (co-locate or separate).

Production Usage
In production: GPU nodes are tainted so only ML workloads run on them. Taints mark nodes for
maintenance ( kubectl taint nodes node1 maintenance=true:NoSchedule ). Pod anti-affinity
spreads replicas across failure domains (zones, nodes). Node affinity targets specific hardware (SSD
nodes, high-memory nodes).

# ============================================================
# Taints & Tolerations
# ============================================================
# Taint a node (CLI):
# kubectl taint nodes node1 dedicated=gpu:NoSchedule
# kubectl taint nodes node1 dedicated=gpu:NoSchedule- (remove)
#
# Taint Effects:
# NoSchedule — Don't schedule new Pods (existing stay)
# PreferNoSchedule — Try to avoid, but not guaranteed
# NoExecute — Evict existing Pods AND don't schedule new ones
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: gpu-workload
spec:
tolerations: # This Pod CAN run on tainted nodes
- key: "dedicated"
operator: "Equal" # Operators: Equal (match value) or Exists (any value)
value: "gpu"
effect: "NoSchedule" # Must match the taint's effect

- key: "[Link]/not-ready"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 300 # Stay on NotReady node for 5 minutes
# After 300s, Pod is evicted

# Tolerate ALL taints (use cautiously):

# - operator: "Exists" # No key = match all keys

containers:

[Link] Page 57 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

- name: ml-training
image: tensorflow/tensorflow:latest-gpu
resources:
limits:
[Link]/gpu: 1 # Request 1 GPU

---
# ============================================================
# Node Selector (Simple)
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: ssd-pod
spec:
nodeSelector: # Simple key-value node selection
disktype: ssd # Only schedule on nodes with this label
# Label a node: kubectl label nodes node1 disktype=ssd
containers:
- name: app
image: myapp:v1.0

---
# ============================================================
# Node Affinity (Advanced)
# ============================================================

apiVersion: v1
kind: Pod
metadata:
name: affinity-pod
spec:
affinity:
# --- Node Affinity: Which NODES should this Pod run on? ---
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
# HARD requirement — Pod won't schedule without this
nodeSelectorTerms:
- matchExpressions:
- key: [Link]/zone
operator: In # Operators: In, NotIn, Exists, DoesNotExist, Gt, Lt
values:
- us-east-1a
- us-east-1b # Must be in zone a or b

preferredDuringSchedulingIgnoredDuringExecution:
# SOFT preference — try but don't block
- weight: 80 # Priority weight (1-100), higher = stronger preference
preference:
matchExpressions:

[Link] Page 58 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

- key: node-type
operator: In
values:
- high-memory # Prefer high-memory nodes

# --- Pod Affinity: Co-locate with OTHER Pods ---

podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- cache # Schedule on same node as cache Pods
topologyKey: [Link]/hostname
# "Same node" = same hostname

# --- Pod Anti-Affinity: Avoid OTHER Pods ---

podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- webapp # Don't put 2 webapp Pods on the same node
topologyKey: [Link]/hostname
# Spread across different nodes

containers:
- name: app
image: myapp:v1.0

16. Probes

Definition
Probes are health-checking mechanisms that the kubelet uses to determine the state of a container.
Liveness Probe checks if the container is alive — if it fails, the container is restarted. Readiness Probe
checks if the container is ready to serve traffic — if it fails, the Pod is removed from Service endpoints
(no traffic sent). Startup Probe checks if the application has finished starting up — if present, liveness
and readiness probes are disabled until it succeeds, preventing slow-starting apps from being killed
prematurely.

[Link] Page 59 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Production Usage
Every production container should have at least a liveness and readiness probe. Liveness probes catch
deadlocks and unresponsive states. Readiness probes ensure traffic is only sent to fully initialized Pods
(critical during rolling updates). Startup probes are essential for applications with long initialization (Java
apps, database migrations).

# ============================================================
# Probes — Complete Example with All Three Types
# ============================================================

apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-with-probes
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: myapp:v2.0
ports:
- containerPort: 8080

# ============================================
# STARTUP PROBE
# ============================================
# Purpose: Wait for the app to START UP
# When: Checked FIRST, before liveness/readiness
# Fail: Container is killed and restarted
#
# Why needed: Slow-starting apps (Java, .NET) might
# take 60+ seconds to initialize. Without startup
# probe, the liveness probe would kill them too early.
# ============================================
startupProbe:
httpGet:
path: /healthz # Endpoint to check
port: 8080
initialDelaySeconds: 10 # Wait 10s before first probe
periodSeconds: 5 # Check every 5 seconds
failureThreshold: 30 # Allow 30 failures = 5s × 30 = 150s total startup time

[Link] Page 60 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# After 150s, if still not ready → restart container

successThreshold: 1 # 1 success = startup complete

# ============================================
# LIVENESS PROBE
# ============================================
# Purpose: Is the container ALIVE and functioning?
# When: Runs continuously after startup succeeds
# Fail: Container is RESTARTED
#
# Catches: Deadlocks, infinite loops, hung processes,
# memory leaks causing unresponsiveness
# ============================================
livenessProbe:
httpGet: # HTTP probe — most common for web apps
path: /healthz # Health check endpoint
port: 8080
httpHeaders: # Optional custom headers
- name: X-Custom-Header
value: LivenessCheck
initialDelaySeconds: 0 # 0 because startup probe handles init wait
periodSeconds: 10 # Check every 10 seconds
timeoutSeconds: 5 # Timeout per probe attempt
failureThreshold: 3 # 3 failures → restart
successThreshold: 1 # 1 success → healthy

# ============================================
# READINESS PROBE
# ============================================
# Purpose: Is the container READY to receive traffic?
# When: Runs continuously after startup succeeds
# Fail: Pod removed from Service endpoints (no traffic)
# Container is NOT restarted
#
# Use for: Dependency checks (DB connection, cache warmup),
# graceful maintenance mode
# ============================================
readinessProbe:
httpGet:
path: /ready # Different endpoint from liveness!
# /ready might check DB connection, cache state
# /healthz only checks if process is alive
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
successThreshold: 1

# ============================================================
# Probe Methods:
#

[Link] Page 61 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# 1. httpGet — Send HTTP GET request

# livenessProbe:
# httpGet:
# path: /healthz
# port: 8080
# Success: HTTP 200-399
#
# 2. tcpSocket — Check if port is open
# livenessProbe:
# tcpSocket:
# port: 3306 # Good for databases, TCP services
# Success: Connection established
#
# 3. exec — Run a command in the container
# livenessProbe:
# exec:
# command:
# - sh
# - -c
# - "pg_isready -U postgres" # Good for custom checks
# Success: Exit code 0
#
# 4. grpc — gRPC health check (K8s 1.27+)
# livenessProbe:
# grpc:
# port: 50051
# service: [Link] # gRPC service name
# Success: SERVING status
# ============================================================

17. KubeConfig Details

Definition
KubeConfig is the configuration file ( ~/.kube/config ) that kubectl uses to connect to Kubernetes
clusters. It contains three main elements: Clusters (API server addresses and CA certificates), Users
(authentication credentials — certificates, tokens, or auth plugins), and Contexts (which combine a
cluster, user, and namespace into a working configuration). You can switch between multiple
clusters/environments using contexts.

Production Usage
In production, teams maintain multiple kubeconfig contexts (dev, staging, prod). Access is controlled
via RBAC — different users have different permissions per cluster. Tools like kubectx and kubens
simplify context/namespace switching. CI/CD pipelines use service account tokens or OIDC tokens in

[Link] Page 62 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

kubeconfig for authentication.

# ============================================================
# KubeConfig File — ~/.kube/config
# ============================================================
# This is NOT a K8s manifest — it's a local configuration file
# that kubectl uses to connect to clusters.
# View current: kubectl config view
# ============================================================

apiVersion: v1
kind: Config

# --- Current Context ---

current-context: production-admin # Active context (which cluster you're using)
# Switch: kubectl config use-context staging-dev

# --- Clusters ---

# Define K8s API server endpoints
clusters:
- name: production-cluster
cluster:
server: [Link] # API server URL
certificate-authority-data: LS0tLS1C... # Base64 CA cert
# Validates the API server's TLS certificate
# certificate-authority: /path/to/[Link] # Alternative: file path
# insecure-skip-tls-verify: true # NEVER in production!

- name: staging-cluster
cluster:
server: [Link]
certificate-authority-data: LS0tLS1C...

- name: eks-cluster
cluster:
server: [Link]
certificate-authority-data: LS0tLS1C...

# --- Users ---

# Authentication methods
users:
- name: admin-user
user:
client-certificate-data: LS0tLS1C... # Base64 client cert
client-key-data: LS0tLS1C... # Base64 client key
# Method: X.509 client certificate authentication

- name: dev-user
user:
token: eyJhbGciOiJSUz... # Bearer token

[Link] Page 63 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Method: Token-based authentication (ServiceAccount token)

- name: eks-user
user:
exec: # Method: External auth plugin
apiVersion: [Link]/v1beta1
command: aws # AWS CLI for EKS auth
args:
- eks
- get-token
- --cluster-name
- my-eks-cluster
- --region
- us-east-1
# This runs 'aws eks get-token' to get a temporary token

- name: oidc-user
user:
exec:
apiVersion: [Link]/v1beta1
command: kubectl
args:
- oidc-login
- get-token
- --oidc-issuer-url=[Link]
- --oidc-client-id=my-client-id
# OIDC authentication (Google, Okta, Azure AD)

# --- Contexts ---

# Combine cluster + user + namespace into a named configuration
contexts:
- name: production-admin
context:
cluster: production-cluster # Which cluster to connect to
user: admin-user # Which credentials to use
namespace: production # Default namespace for this context
# Commands without -n flag use this namespace

- name: staging-dev
context:
cluster: staging-cluster
user: dev-user
namespace: staging

- name: eks-production
context:
cluster: eks-cluster
user: eks-user
namespace: default

# ============================================================

[Link] Page 64 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Useful kubectl config commands:

#
# kubectl config view # View kubeconfig
# kubectl config current-context # Show current context
# kubectl config use-context staging-dev # Switch context
# kubectl config get-contexts # List all contexts
# kubectl config set-context --current --namespace=kube-system
# # Change default namespace
#
# Multi-kubeconfig:
# export KUBECONFIG=~/.kube/config:~/.kube/prod-config
# kubectl config view --flatten > merged-config
#
# Handy tools:
# kubectx — fast context switching
# kubens — fast namespace switching
# ============================================================

18. Init Containers

Definition
Init Containers are specialized containers that run to completion before the app containers start. They
run sequentially — each init container must succeed before the next one starts. If an init container fails,
the Pod restarts (according to the restart policy). Init containers are used for setup tasks that must
complete before the main application starts: database migrations, downloading config files, waiting for
dependent services, or setting file permissions.

Production Usage
Init containers are used extensively for: waiting for dependent services (database, cache) before app
startup, running database migrations before the app connects, downloading configuration from
Vault/S3, generating TLS certificates, and setting up sidecar proxies. They ensure predictable
application startup by guaranteeing prerequisites are met.

# ============================================================
# Init Containers — Complete Example
# ============================================================
# File: [Link]
# Init containers run BEFORE app containers, sequentially.
# ============================================================

apiVersion: v1
kind: Pod

[Link] Page 65 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

metadata:
name: webapp-with-init
namespace: production
labels:
app: webapp
spec:
# --- INIT CONTAINERS ---
# Run in ORDER: init-1 → init-2 → init-3 → then app containers
initContainers:
# Init Container 1: Wait for database to be ready
- name: wait-for-db
image: busybox:1.36
command: ['sh', '-c']
args:
- |
echo "Waiting for PostgreSQL..."
until nc -z [Link] 5432; do
echo "DB not ready, sleeping 2s..."
sleep 2
done
echo "Database is ready!"
# This init container blocks until the database accepts connections
# Without this, the app might crash trying to connect to a non-ready DB

# Init Container 2: Run database migrations

- name: db-migrate
image: myapp-migrations:v1.3.0 # Image containing migration scripts
command: ['python', '[Link]', 'migrate']
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: app-secrets
key: database-url
# Migrations run ONCE before the app starts
# If migration fails, the Pod restarts and retries

# Init Container 3: Download config from S3

- name: config-downloader
image: amazon/aws-cli:2.15
command: ['sh', '-c']
args:
- |
aws s3 cp s3://my-bucket/config/[Link] /config/[Link]
echo "Config downloaded successfully"
volumeMounts:
- name: config-volume
mountPath: /config # Downloaded config is shared with app container

# --- APP CONTAINERS ---

# Start ONLY after ALL init containers succeed

[Link] Page 66 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

containers:
- name: webapp
image: myapp:v1.3.0
ports:
- containerPort: 8080
env:
- name: CONFIG_PATH
value: /config/[Link]
volumeMounts:
- name: config-volume
mountPath: /config
readOnly: true

volumes:
- name: config-volume
emptyDir: {} # Shared between init and app containers

# ============================================================
# Init Container vs Regular Container:
#
# Feature Init Container Regular Container
# ──────────────────── ──────────────────── ────────────────────
# Run order Sequential Parallel
# Must succeed Yes (blocks startup) No (depends on policy)
# Probes Not supported Liveness/Readiness
# Resource limits Separate from app Counted for Pod
# Restart Restarts whole Pod Depends on policy
# Use case Setup/prerequisites Application logic
#
# Init container resources:
# - The HIGHEST init container resource request is used for scheduling
# - Init containers run one-at-a-time, so the max of all init containers
# is compared with the sum of all app containers
# - Pod effective resources = max(max(init containers), sum(app containers))
# ============================================================

19. Troubleshooting

Definition
Troubleshooting in Kubernetes involves diagnosing and resolving issues with Pods, Nodes, Services,
and cluster components. Common problems include: Pods stuck in Pending (scheduling issues),
CrashLoopBackOff (application crashes), ImagePullBackOff (wrong image or registry auth), and
Services not routing traffic (selector mismatch). Effective troubleshooting follows a systematic
approach: check events, examine logs, verify configurations, and test network connectivity.

[Link] Page 67 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Production Usage
Production troubleshooting relies on centralized logging (ELK, Loki), monitoring (Prometheus +
Grafana), and alerting (PagerDuty, Opsgenie). kubectl describe and kubectl logs are the first-
response tools. For advanced debugging, ephemeral debug containers ( kubectl debug ) allow
attaching debugging tools to running Pods without modifying their images.

# ============================================================
# Troubleshooting Reference — NOT a manifest, a commands guide
# ============================================================

# =====================
# NODE ERRORS
# =====================

# Check node status:

# kubectl get nodes
# kubectl describe node <node-name>
# kubectl top nodes # Resource usage

# Common Node issues:

# NotReady — kubelet not running, network issues, disk pressure
# MemoryPressure — Node running out of memory
# DiskPressure — Node running out of disk
# PIDPressure — Too many processes
# NetworkUnavailable — CNI plugin issue

# Debug a node:
# kubectl debug node/<node-name> -it --image=busybox
# ssh into node → journalctl -u kubelet # Check kubelet logs
# ssh into node → systemctl status kubelet # Kubelet service status

# =====================
# POD ERRORS
# =====================

# Check Pod status:

# kubectl get pods -o wide # Overview with node info
# kubectl describe pod <pod-name> # DETAILED info + events
# kubectl logs <pod-name> # Container logs
# kubectl logs <pod-name> -c <container> # Specific container logs
# kubectl logs <pod-name> --previous # Logs from CRASHED container

# --- Pending ---

# Cause: No node has enough resources, or scheduling constraints can't be met
# Fix:
# kubectl describe pod <name> # Look at Events section
# Check: resource requests vs available, nodeSelector, taints/tolerations
# Fix: Add nodes, adjust requests, fix constraints

[Link] Page 68 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# --- CrashLoopBackOff ---

# Cause: Container starts and immediately crashes, K8s keeps restarting it
# Fix:
# kubectl logs <pod-name> --previous # See crash logs
# kubectl describe pod <name> # Check exit code
# Common causes: wrong command, missing env vars, config errors,
# permission issues, OOMKilled (memory limit too low)

# --- ImagePullBackOff ---

# Cause: Cannot pull the container image
# Fix:
# kubectl describe pod <name> # Check image name in events
# Common causes: wrong image name/tag, private registry without
# imagePullSecrets, network issues

# --- OOMKilled ---

# Cause: Container exceeded memory limit
# Fix:
# kubectl describe pod <name> # Look for "OOMKilled" in status
# Increase memory limit or fix memory leak

# --- Evicted ---

# Cause: Node under resource pressure (disk, memory)
# Fix:
# Check node conditions: kubectl describe node <name>
# Clean up disk space or add node capacity

# =====================
# SERVICE TROUBLESHOOTING
# =====================

# Service not routing traffic:

# kubectl get endpoints <svc-name> # Check if Pods are registered
# kubectl describe svc <svc-name> # Verify selector matches Pod labels
# kubectl get pods --show-labels # Check Pod labels

# Test from inside cluster:

# kubectl run debug --rm -it --image=busybox -- sh
# nslookup [Link] # DNS works?
# wget -qO- [Link] # Connection works?

# =====================
# DEBUG CONTAINERS (K8s 1.25+)
# =====================

# Attach a debug container to a running Pod:

# kubectl debug pod/<pod-name> -it --image=busybox --target=<container>
# # Shares the process namespace — can see app processes

# Create a copy of the Pod with debug image:

# kubectl debug pod/<pod-name> -it --image=ubuntu --copy-to=debug-pod

[Link] Page 69 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

20. Kubectl Commands

Definition
kubectl is the command-line tool for interacting with Kubernetes clusters. It communicates with the
API Server to create, inspect, update, and delete Kubernetes resources. Every operation in Kubernetes
can be performed via kubectl — from deploying applications to debugging issues to managing cluster
configuration. It supports imperative commands (quick actions), declarative management (applying
YAML files), and output formatting (JSON, YAML, wide, custom columns).

Production Usage
In production, kubectl apply -f (declarative) is preferred over imperative commands for
reproducibility and GitOps workflows. Teams use kubectl for monitoring ( get , describe , logs ,
top ), debugging ( exec , port-forward , debug ), and emergency operations ( scale , rollout
undo ). Access is controlled via RBAC — operators have full access, developers have read-only + logs.

# ============================================================
# Kubectl Commands — Complete Reference
# ============================================================
# NOT a manifest — a command reference guide
# ============================================================

# =====================
# CLUSTER INFO
# =====================
# kubectl cluster-info # API server and CoreDNS endpoints
# kubectl get componentstatuses # Control plane health (deprecated in newer K
# kubectl api-resources # All available resource types
# kubectl api-versions # All available API versions
# kubectl version # Client and server versions

# =====================
# GET RESOURCES
# =====================
# kubectl get pods # List Pods in current namespace
# kubectl get pods -n kube-system # Pods in specific namespace
# kubectl get pods --all-namespaces (-A) # Pods in ALL namespaces
# kubectl get pods -o wide # Extra columns (node, IP)
# kubectl get pods -o yaml # Full YAML output
# kubectl get pods -o json # Full JSON output
# kubectl get pods -l app=webapp # Filter by label
# kubectl get pods --field-selector [Link]=Running
# kubectl get pods --sort-by=.[Link]

[Link] Page 70 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# kubectl get pods -w # Watch mode (live updates)

#
# kubectl get all # Pods, Services, Deployments, ReplicaSets
# kubectl get nodes
# kubectl get svc
# kubectl get deploy
# kubectl get rs # ReplicaSets
# kubectl get ds # DaemonSets
# kubectl get sts # StatefulSets
# kubectl get pv # PersistentVolumes
# kubectl get pvc # PersistentVolumeClaims
# kubectl get ingress
# kubectl get configmap
# kubectl get secrets
# kubectl get events --sort-by=.lastTimestamp # Recent cluster events

# Custom columns:
# kubectl get pods -o custom-columns=\
# NAME:.[Link],\
# STATUS:.[Link],\
# NODE:.[Link],\
# IP:.[Link]

# =====================
# DESCRIBE (Detailed Info)
# =====================
# kubectl describe pod <pod-name> # MOST USEFUL debug command
# kubectl describe node <node-name> # Node capacity, conditions
# kubectl describe svc <service-name> # Endpoints, selectors
# kubectl describe deploy <deployment-name> # Rollout history, conditions

# =====================
# CREATE / APPLY
# =====================
# kubectl apply -f [Link] # Declarative — create or update
# kubectl apply -f ./manifests/ # Apply all YAML in directory
# kubectl apply -f [Link] # Apply from URL
# kubectl create -f [Link] # Imperative create (error if exists)
#
# Imperative commands (quick & dirty):
# kubectl run nginx --image=nginx:1.25 # Create a Pod
# kubectl create deployment web --image=nginx # Create a Deployment
# kubectl expose deploy web --port=80 --type=NodePort # Create Service
# kubectl create configmap my-config --from-literal=key=value
# kubectl create secret generic my-secret --from-literal=password=abc123
# kubectl create namespace my-namespace

# =====================
# EDIT / UPDATE
# =====================
# kubectl edit deploy <name> # Open in $EDITOR

[Link] Page 71 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# kubectl set image deploy/<name> container=image:tag # Update image

# kubectl scale deploy <name> --replicas=5 # Scale
# kubectl patch svc <name> -p '{"spec":{"type":"NodePort"}}'
# kubectl label pod <name> env=prod # Add label
# kubectl label pod <name> env- # Remove label
# kubectl annotate pod <name> desc="my pod" # Add annotation

# =====================
# DELETE
# =====================
# kubectl delete -f [Link] # Delete what's defined in file
# kubectl delete pod <name> # Delete specific Pod
# kubectl delete pod <name> --grace-period=0 --force # Force delete
# kubectl delete pods --all -n <namespace> # Delete all Pods
# kubectl delete namespace <name> # Delete namespace + all resources

# =====================
# DEBUGGING
# =====================
# kubectl logs <pod-name> # Container logs
# kubectl logs <pod-name> -c <container> # Specific container
# kubectl logs <pod-name> --previous # Previous (crashed) container
# kubectl logs <pod-name> -f # Follow/stream logs
# kubectl logs <pod-name> --tail=100 # Last 100 lines
# kubectl logs -l app=webapp # Logs from all Pods with label
#
# kubectl exec -it <pod-name> -- /bin/sh # Shell into container
# kubectl exec <pod-name> -- ls /app # Run single command
# kubectl exec -it <pod> -c <container> -- sh # Specific container
#
# kubectl port-forward pod/<name> 8080:80 # Forward local:8080 → Pod:80
# kubectl port-forward svc/<name> 8080:80 # Forward via Service
#
# kubectl cp <pod>:/path/file ./local-file # Copy from Pod
# kubectl cp ./local-file <pod>:/path/file # Copy to Pod
#
# kubectl top pods # CPU/memory usage
# kubectl top pods --sort-by=memory
# kubectl top nodes

# =====================
# ROLLOUT MANAGEMENT
# =====================
# kubectl rollout status deploy/<name> # Watch rollout progress
# kubectl rollout history deploy/<name> # View revision history
# kubectl rollout undo deploy/<name> # Rollback to previous version
# kubectl rollout undo deploy/<name> --to-revision=3 # Rollback to specific
# kubectl rollout pause deploy/<name> # Pause rollout
# kubectl rollout resume deploy/<name> # Resume rollout
# kubectl rollout restart deploy/<name> # Restart all Pods

[Link] Page 72 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# =====================
# DRY RUN & GENERATE YAML
# =====================
# kubectl run nginx --image=nginx --dry-run=client -o yaml > [Link]
# kubectl create deploy web --image=nginx --dry-run=client -o yaml
# kubectl expose deploy web --port=80 --dry-run=client -o yaml
# Very useful for generating manifest templates quickly!

# =====================
# CONTEXT & NAMESPACE
# =====================
# kubectl config current-context # Current context
# kubectl config get-contexts # List all contexts
# kubectl config use-context <name> # Switch context
# kubectl config set-context --current --namespace=production

21. Reverse Proxy

Definition
A Reverse Proxy sits in front of backend servers and forwards client requests to the appropriate
backend. In Kubernetes, the Ingress Controller (NGINX, Traefik, HAProxy) acts as a reverse proxy for
HTTP/HTTPS traffic. It handles: SSL termination, load balancing, URL routing, header manipulation,
rate limiting, and caching. Unlike a forward proxy (which serves clients), a reverse proxy protects and
manages backend services.

Production Usage
In production, NGINX Ingress Controller is the most common reverse proxy. It terminates SSL at the
edge, routes traffic based on URL paths and hostnames, adds security headers, implements rate
limiting, and provides access logging. For advanced use cases, Envoy (used by Istio) or Traefik provide
more features like circuit breaking and tracing.

# ============================================================
# NGINX Ingress as Reverse Proxy — Production Configuration
# ============================================================
# The NGINX Ingress Controller is a reverse proxy that
# handles all incoming HTTP/HTTPS traffic for the cluster.
# ============================================================

apiVersion: [Link]/v1
kind: Ingress
metadata:
name: reverse-proxy-ingress

[Link] Page 73 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

namespace: production
annotations:
# --- Reverse Proxy Behavior ---
[Link]/proxy-pass-headers: "X-Custom-Header"
[Link]/proxy-set-headers: "production/custom-headers"

# --- Load Balancing ---

[Link]/upstream-hash-by: "$request_uri"
# Consistent hashing based on URI

# --- SSL Termination ---

[Link]/ssl-redirect: "true"
[Link]/force-ssl-redirect: "true"

# --- Security Headers ---

[Link]/configuration-snippet: |
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Strict-Transport-Security "max-age=31536000" always;

# --- Rate Limiting ---

[Link]/limit-rps: "50"
# 50 requests per second per IP
[Link]/limit-burst-multiplier: "5"

# --- Timeouts ---

[Link]/proxy-connect-timeout: "10"
[Link]/proxy-read-timeout: "60"
[Link]/proxy-send-timeout: "60"

# --- Request Size ---

[Link]/proxy-body-size: "100m"

# --- CORS ---

[Link]/enable-cors: "true"
[Link]/cors-allow-origin: "[Link]
[Link]/cors-allow-methods: "GET, POST, PUT, DELETE"

spec:
ingressClassName: nginx
tls:
- hosts:
- [Link]
secretName: api-tls
rules:
- host: [Link]
http:
paths:
- path: /
pathType: Prefix

[Link] Page 74 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

backend:
service:
name: api-service
port:
number: 80

# ============================================================
# How Reverse Proxy works in K8s:
#
# Client → DNS → Cloud LB → Ingress Controller (NGINX Pod)
# → URL/Host matching → Route to Service → Pod
#
# The Ingress Controller Pod IS the reverse proxy.
# It reads Ingress resources and configures NGINX dynamically.
# ============================================================

22. SSL/TLS Certificate Information

Definition
SSL/TLS certificates enable encrypted HTTPS communication between clients and servers. In
Kubernetes, TLS is implemented at the Ingress level (SSL termination) using TLS Secrets that contain
the certificate and private key. cert-manager is the most popular tool for automating certificate
lifecycle — it provisions, renews, and manages certificates from issuers like Let's Encrypt, Vault, and
Venafi. TLS can also be configured for Pod-to-Pod encryption using service meshes (Istio mTLS).

Production Usage
Every production service exposed to the internet must use HTTPS. cert-manager + Let's Encrypt is
the standard free setup for automatic SSL. For internal services, organizations use private CAs. Service
meshes (Istio) enable mutual TLS (mTLS) for encrypted Pod-to-Pod communication without
application changes. TLS Secrets must be rotated before expiry — cert-manager handles this
automatically.

# ============================================================
# TLS Secret — Manual Certificate Storage
# ============================================================

apiVersion: v1
kind: Secret
metadata:
name: webapp-tls
namespace: production
type: [Link]/tls

[Link] Page 75 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

data:
[Link]: LS0tLS1CRUdJTi... # base64-encoded certificate chain
[Link]: LS0tLS1CRUdJTi... # base64-encoded private key

# Create via CLI:

# kubectl create secret tls webapp-tls \
# --cert=[Link] \
# --key=[Link] \
# -n production

---
# ============================================================
# cert-manager — Automated Certificate Management
# ============================================================
# Install cert-manager first:
# kubectl apply -f [Link]
# releases/download/v1.14.0/[Link]
# ============================================================

# Step 1: Create a ClusterIssuer (Let's Encrypt)

apiVersion: [Link]/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: [Link]
# Let's Encrypt production API
email: admin@[Link] # Notifications for cert expiry
privateKeySecretRef:
name: letsencrypt-prod-key # Secret to store ACME account key
solvers:
- http01:
ingress:
class: nginx # Use NGINX Ingress for HTTP-01 challenge
# cert-manager creates temporary Ingress rules
# to prove domain ownership

# Alternative: DNS-01 challenge (for wildcard certs)

# - dns01:
# route53: # AWS Route53
# region: us-east-1
# hostedZoneID: Z12345

---
# Step 2: Create a Certificate resource
apiVersion: [Link]/v1
kind: Certificate
metadata:
name: webapp-cert
namespace: production

[Link] Page 76 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

spec:
secretName: webapp-tls-auto # cert-manager creates this Secret automatically
# Contains [Link] and [Link]

issuerRef:
name: letsencrypt-prod # Reference the ClusterIssuer
kind: ClusterIssuer

dnsNames: # Domains to include in the certificate

- [Link]
- [Link]
- [Link]

duration: 2160h # 90 days (Let's Encrypt default)

renewBefore: 360h # Renew 15 days before expiry
# cert-manager handles renewal automatically!

---
# Step 3: Use the auto-generated cert in Ingress
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: webapp-ingress
namespace: production
annotations:
[Link]/cluster-issuer: "letsencrypt-prod"
# This annotation tells cert-manager to
# automatically create a Certificate resource
spec:
ingressClassName: nginx
tls:
- hosts:
- [Link]
secretName: webapp-tls-auto # cert-manager populates this Secret
rules:
- host: [Link]
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp-service
port:
number: 80

23. EKS Cluster Backup — Velero

[Link] Page 77 of 106
Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Definition
Velero is an open-source tool for backing up and restoring Kubernetes cluster resources and persistent
volumes. It captures the state of all Kubernetes objects (Deployments, Services, ConfigMaps, etc.) and
volume snapshots, storing them in object storage (S3, GCS, Azure Blob). Velero enables disaster
recovery, cluster migration, and development environment cloning. It runs as a Deployment inside the
cluster and is controlled via the velero CLI.

Production Usage
In production, Velero is configured with scheduled backups (e.g., daily full cluster backups, hourly
namespace backups). It's essential for disaster recovery — restoring a cluster after accidental deletion
or corruption. Velero also enables cluster migration (backup from one cluster, restore to another) and
environment cloning (copy production to staging for testing).

# ============================================================
# Velero Backup — Scheduled Backup Configuration
# ============================================================
# Install Velero CLI + Server first:
# velero install \
# --provider aws \
# --bucket my-velero-backups \
# --secret-file ./credentials-velero \
# --backup-location-config region=us-east-1 \
# --snapshot-location-config region=us-east-1
# ============================================================

# --- Backup Storage Location ---

apiVersion: [Link]/v1
kind: BackupStorageLocation
metadata:
name: default
namespace: velero
spec:
provider: aws # Cloud provider: aws, gcp, azure
objectStorage:
bucket: my-velero-backups # S3 bucket name
prefix: backups # Folder prefix in the bucket
config:
region: us-east-1
s3ForcePathStyle: "false"
default: true # Default backup location

---
# --- Volume Snapshot Location ---
apiVersion: [Link]/v1
kind: VolumeSnapshotLocation
metadata:
name: default

[Link] Page 78 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

namespace: velero
spec:
provider: aws
config:
region: us-east-1 # Region for EBS snapshots

---
# --- Scheduled Backup ---
apiVersion: [Link]/v1
kind: Schedule
metadata:
name: daily-full-backup
namespace: velero
spec:
schedule: "0 2 * * *" # Cron: Daily at 2:00 AM UTC

template:
includedNamespaces: # Which namespaces to back up
- production
- staging
# excludedNamespaces: # Or exclude specific ones
# - kube-system

includedResources: # Which resource types (default: all)

- '*' # Everything

excludedResources: # Skip these resources

- events # Events are noisy and transient

labelSelector: # Optional: only back up resources with label

matchLabels:
backup: enabled

storageLocation: default # BackupStorageLocation to use

volumeSnapshotLocations:
- default # VolumeSnapshotLocation for PV snapshots

ttl: 720h # Retain backup for 30 days

# After TTL, backup is automatically deleted

snapshotVolumes: true # Snapshot PersistentVolumes (EBS snapshots)

defaultVolumesToRestic: false # Set true for file-level backups via Restic

# Restic = cross-provider, slower but more portable
# Snapshots = provider-specific, faster

# ============================================================
# Velero CLI Commands:
#
# BACKUP:
# velero backup create my-backup # Full backup

[Link] Page 79 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# velero backup create my-backup --include-namespaces production

# velero backup create my-backup --selector app=webapp
# velero backup get # List backups
# velero backup describe my-backup --details # Backup details
# velero backup logs my-backup # Backup logs
#
# RESTORE:
# velero restore create --from-backup my-backup # Full restore
# velero restore create --from-backup my-backup \
# --include-namespaces production # Restore specific namespace
# velero restore create --from-backup my-backup \
# --restore-volumes=true # Include volume data
# velero restore get # List restores
#
# SCHEDULE:
# velero schedule create daily --schedule="0 2 * * *"
# velero schedule get
# velero schedule delete daily
#
# DISASTER RECOVERY WORKFLOW:
# 1. Install Velero on new cluster
# 2. Point to same S3 bucket
# 3. velero backup get # See available backups
# 4. velero restore create --from-backup <latest> # Restore everything
# ============================================================

24. Service Mesh

Definition
A Service Mesh is an infrastructure layer that manages service-to-service communication within a
microservices architecture. It provides: traffic management (load balancing, routing, retries), security
(mutual TLS, authorization), and observability (metrics, tracing, logging) — all without changing
application code. The most popular service mesh is Istio, which injects a sidecar proxy (Envoy) into
every Pod. Kiali provides a visual dashboard, and Jaeger provides distributed tracing.

Production Usage
Service meshes are used in production for: encrypting all Pod-to-Pod traffic with mTLS (zero-trust
security), implementing canary deployments with traffic splitting (e.g., 95% to v1, 5% to v2), circuit
breaking to prevent cascading failures, retry policies for transient errors, and distributed tracing to
debug latency across microservices. Istio is the most widely adopted, but Linkerd is lighter-weight.

# ============================================================

[Link] Page 80 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Istio — VirtualService (Traffic Routing)

# ============================================================
# VirtualService defines HOW traffic is routed to services.
# Enables canary deployments, A/B testing, fault injection.
# ============================================================

apiVersion: [Link]/v1beta1
kind: VirtualService
metadata:
name: webapp-vs
namespace: production
spec:
hosts:
- webapp # Kubernetes Service name
- [Link] # External hostname

gateways:
- webapp-gateway # Istio Gateway for external traffic
- mesh # "mesh" = internal service-to-service traffic

http:
# --- Canary Routing (Traffic Split) ---
- match:
- headers:
x-canary:
exact: "true" # Route canary header traffic to v2
route:
- destination:
host: webapp
subset: v2 # DestinationRule subset
weight: 100

# --- Default Routing (weighted traffic split) ---

- route:
- destination:
host: webapp
subset: v1 # 90% to v1
weight: 90
- destination:
host: webapp
subset: v2 # 10% to v2 (canary)
weight: 10

# --- Retry Policy ---

retries:
attempts: 3 # Retry up to 3 times
perTryTimeout: 2s # Timeout per retry
retryOn: "5xx,connect-failure" # Retry on server errors

# --- Timeout ---

timeout: 10s # Overall request timeout

[Link] Page 81 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# --- Fault Injection (testing) ---

# fault:
# delay:
# percentage:
# value: 10 # Inject 10% artificial delay
# fixedDelay: 5s
# abort:
# percentage:
# value: 5 # Abort 5% of requests
# httpStatus: 500

---
# ============================================================
# Istio — DestinationRule (Traffic Policy)
# ============================================================
# Defines traffic policies applied AFTER routing (VirtualService).
# Includes: load balancing, connection pools, circuit breakers, mTLS.
# ============================================================

apiVersion: [Link]/v1beta1
kind: DestinationRule
metadata:
name: webapp-dr
namespace: production
spec:
host: webapp # Target Kubernetes Service

trafficPolicy:
# --- Mutual TLS ---
tls:
mode: ISTIO_MUTUAL # Enable mTLS for all traffic
# Modes: DISABLE, SIMPLE, MUTUAL, ISTIO_MUTUAL

# --- Load Balancing ---

loadBalancer:
simple: LEAST_REQUEST # Options: ROUND_ROBIN, LEAST_REQUEST,
# RANDOM, PASSTHROUGH

# --- Circuit Breaker ---

connectionPool:
tcp:
maxConnections: 100 # Max TCP connections
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 100
http2MaxRequests: 1000

outlierDetection: # Circuit breaker settings

consecutive5xxErrors: 5 # 5 consecutive 5xx errors
interval: 30s # Check every 30 seconds

[Link] Page 82 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

baseEjectionTime: 30s # Eject unhealthy endpoint for 30s

maxEjectionPercent: 50 # Max 50% of endpoints can be ejected

# --- Subsets (versions) ---

subsets:
- name: v1
labels:
version: v1 # Pods with label version=v1
- name: v2
labels:
version: v2 # Pods with label version=v2

---
# ============================================================
# Istio — Gateway (External Traffic Entry Point)
# ============================================================

apiVersion: [Link]/v1beta1
kind: Gateway
metadata:
name: webapp-gateway
namespace: production
spec:
selector:
istio: ingressgateway # Use Istio's built-in ingress gateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: webapp-tls # TLS Secret in istio-system namespace
hosts:
- [Link]
- port:
number: 80
name: http
protocol: HTTP
tls:
httpsRedirect: true # Redirect HTTP → HTTPS
hosts:
- [Link]

---
# ============================================================
# Istio — PeerAuthentication (mTLS Policy)
# ============================================================
# Enforce mutual TLS for all Pods in the namespace.
# ============================================================

[Link] Page 83 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

apiVersion: [Link]/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT # STRICT = require mTLS for all traffic
# PERMISSIVE = accept both plain and mTLS
# DISABLE = no mTLS

# ============================================================
# Observability Tools:
#
# KIALI — Service Mesh Dashboard
# - Visualizes microservice topology
# - Shows traffic flow, error rates, latency
# - Validates Istio configuration
# Access: kubectl port-forward svc/kiali -n istio-system 20001:20001
# URL: [Link]
#
# JAEGER — Distributed Tracing
# - Traces requests across multiple microservices
# - Shows where latency occurs in the call chain
# - Helps identify bottlenecks
# Access: kubectl port-forward svc/tracing -n istio-system 16686:80
# URL: [Link]
#
# PROMETHEUS — Metrics Collection
# - Collects Istio proxy metrics (request count, latency, error rate)
# - Used by HPA for autoscaling
# - Dashboards in Grafana
#
# GRAFANA — Metrics Dashboard
# - Pre-built Istio dashboards
# - Service-level metrics visualization
# ============================================================

25. Cluster Upgradation

Definition
Cluster Upgradation is the process of upgrading Kubernetes components (API Server, etcd,
Scheduler, Controller Manager, Kubelet) to a newer version. Kubernetes supports version skew of one
minor version between control plane and worker nodes (e.g., control plane 1.29, nodes 1.28).
Upgrades must follow the order: etcd → API Server → Controller Manager/Scheduler →

[Link] Page 84 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Kubelet/kube-proxy. Managed services (EKS, GKE, AKS) handle control plane upgrades; you only
upgrade worker nodes.

Production Usage
Production clusters should upgrade regularly (every 3-4 months) to stay within the supported version
window. Upgrades are performed with zero downtime using rolling upgrades — one node at a time is
cordoned, drained, upgraded, and uncordoned. Always test upgrades in staging first. Read release
notes for breaking changes and deprecated APIs.

# ============================================================
# Cluster Upgrade — Step-by-Step Commands
# ============================================================
# NOT a manifest — upgrade procedure reference
# ============================================================

# =====================
# SELF-MANAGED CLUSTER (kubeadm)
# =====================

# Step 1: Check current version and available upgrades

# kubectl version
# kubeadm upgrade plan

# Step 2: Upgrade Control Plane (one master at a time)

# # On master node:
# apt-get update
# apt-get install -y kubeadm=1.29.0-00
# kubeadm upgrade apply v1.29.0
# apt-get install -y kubelet=1.29.0-00 kubectl=1.29.0-00
# systemctl daemon-reload
# systemctl restart kubelet

# Step 3: Upgrade Worker Nodes (one at a time)

# # From control plane:
# kubectl cordon <node-name> # Mark node as unschedulable
# kubectl drain <node-name> \
# --ignore-daemonsets \ # Keep DaemonSets running
# --delete-emptydir-data # Allow emptyDir data loss
#
# # On worker node:
# apt-get update
# apt-get install -y kubeadm=1.29.0-00
# kubeadm upgrade node
# apt-get install -y kubelet=1.29.0-00
# systemctl daemon-reload
# systemctl restart kubelet
#
# # From control plane:

[Link] Page 85 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# kubectl uncordon <node-name> # Mark node as schedulable again

# =====================
# MANAGED CLUSTER (EKS)
# =====================

# Step 1: Upgrade Control Plane

# aws eks update-cluster-version \
# --name my-cluster \
# --kubernetes-version 1.29
# # EKS handles control plane upgrade (takes ~25 minutes)

# Step 2: Upgrade Node Groups

# aws eks update-nodegroup-version \
# --cluster-name my-cluster \
# --nodegroup-name my-nodegroup \
# --kubernetes-version 1.29
# # EKS performs rolling replacement of nodes

# Step 3: Update add-ons

# aws eks update-addon \
# --cluster-name my-cluster \
# --addon-name vpc-cni \
# --addon-version v1.16.0-eksbuild.1

# =====================
# PRE-UPGRADE CHECKLIST
# =====================
# 1. Read release notes for breaking changes
# 2. Check deprecated API versions:
# kubectl get --raw /apis | jq
# kubectl api-versions
# 3. Test in staging first
# 4. Backup etcd: etcdctl snapshot save /backup/[Link]
# 5. Backup Velero: velero backup create pre-upgrade
# 6. Check PodDisruptionBudgets won't block drain
# 7. Verify all Pods are healthy: kubectl get pods -A

[Link] Page 86 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# ============================================================
# PodDisruptionBudget (PDB) — Safe Upgrades
# ============================================================
# Ensures minimum availability during voluntary disruptions
# (node drain, cluster upgrade, scaling down).
# Does NOT protect against involuntary disruptions (node crash).
# ============================================================

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: webapp-pdb
namespace: production
spec:
# Use ONE of these:
minAvailable: 2 # At least 2 Pods must remain running
# OR
# maxUnavailable: 1 # At most 1 Pod can be down at a time

selector:
matchLabels:
app: webapp # Apply to Pods matching this selector

# ============================================================
# During 'kubectl drain', if draining this node would violate
# the PDB (e.g., take available Pods below minAvailable),
# the drain will WAIT until Pods are rescheduled elsewhere.
# This ensures zero-downtime during cluster upgrades.
# ============================================================

26. Cluster Communication & Multi-Cluster

Definition
Cluster Communication involves connecting services across multiple Kubernetes clusters. Multi-
cluster setups provide: high availability (survive entire cluster failures), geographic distribution (low
latency for global users), environment isolation (separate prod/staging clusters), and compliance (data
residency requirements). Communication between clusters can be achieved through Service Meshes
(Istio multi-cluster), DNS-based discovery, API gateway federation, or direct VPC/VPN peering.

Production Usage
Large enterprises run multiple clusters across regions. Istio multi-cluster enables transparent service
discovery and mTLS across clusters. Kubernetes Federation (KubeFed) synchronizes resources

[Link] Page 87 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

across clusters. Submariner provides network connectivity between clusters. Cloud-native approaches
include AWS PrivateLink, GCP Multi-cluster Services, and Azure Arc for multi-cluster management.

# ============================================================
# Multi-Cluster Service Export (KEP-1645)
# ============================================================
# Kubernetes Multi-Cluster Services API (MCS)
# Allows exporting a Service from one cluster to be
# discoverable in other clusters.
# ============================================================

# In the exporting cluster:

apiVersion: [Link]/v1alpha1
kind: ServiceExport
metadata:
name: webapp-service
namespace: production
# This makes webapp-service available to other clusters
# Other clusters can reach it via:
# [Link]

---
# In the consuming cluster:
apiVersion: [Link]/v1alpha1
kind: ServiceImport
metadata:
name: webapp-service
namespace: production
spec:
type: ClusterSetIP # Assign a VIP in the consuming cluster
ports:
- port: 80
protocol: TCP

# ============================================================
# Multi-Cluster Patterns:
#
# 1. REPLICATED SERVICES
# Same service deployed in multiple clusters
# Global load balancer routes to nearest cluster
# Use: High availability, geo-distribution
#
# 2. SHARED SERVICES
# Central services (auth, logging) in one cluster
# Other clusters connect to shared services
# Use: Reduce duplication, centralize management
#
# 3. FEDERATED DEPLOYMENT
# KubeFed pushes resources to multiple clusters
# Single control plane manages all clusters

[Link] Page 88 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Use: Consistent deployments across clusters

#
# Multi-Cluster Tools:
# - Istio Multi-Cluster: Service mesh across clusters
# - Submariner: Layer 3 connectivity between clusters
# - Cilium Cluster Mesh: eBPF-based multi-cluster networking
# - Liqo: Virtual node for cross-cluster Pod scheduling
# - KubeFed: Kubernetes Federation for resource sync
# ============================================================

27. Jobs & CronJob

Definition
A Job creates one or more Pods and ensures a specified number of them successfully terminate.
Unlike Deployments (which keep Pods running forever), Jobs run to completion. A CronJob creates
Jobs on a recurring schedule using cron syntax. Jobs use restartPolicy: Never or OnFailure
(never Always ). They are essential for batch processing, database migrations, report generation, and
scheduled maintenance tasks.

Production Usage
In production, Jobs handle batch workloads (data processing, ETL), one-off tasks (database
migrations), and cleanup routines. CronJobs automate recurring tasks (nightly backups, certificate
rotation, log cleanup). Always set activeDeadlineSeconds to prevent stuck Jobs. Use
backoffLimit to control retries. CronJobs should set concurrencyPolicy to prevent overlapping
runs.

[Link] Page 89 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Job Manifest — Minimal

apiVersion: batch/v1
kind: Job
metadata:
name: data-migration
spec:
backoffLimit: 3
activeDeadlineSeconds: 600
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: myapp/migrate:v2.1
command: ["python", "[Link]"]

---
# CronJob Manifest — Minimal
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
jobTemplate:
spec:
backoffLimit: 2
template:
spec:
restartPolicy: OnFailure
containers:
- name: backup
image: myapp/backup:latest
command: ["sh", "-c", "[Link]"]

Field Description

backoffLimit Number of retries before marking Job as failed

activeDeadlineSeconds Max time the Job can run; kills after this

completions Number of successful completions required (default 1)

parallelism Number of Pods running in parallel

concurrencyPolicy Allow (default), Forbid (skip if running), Replace (kill and restart)

[Link] Page 90 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

28. DNS & CoreDNS

Definition
CoreDNS is the default DNS server in Kubernetes (replaced kube-dns since K8s 1.13). It provides
service discovery within the cluster — every Service gets a DNS name in the format <service>.
<namespace>.[Link] . CoreDNS runs as a Deployment in the kube-system namespace
and is configured via a Corefile stored in a ConfigMap. It resolves internal cluster DNS and forwards
external queries to upstream nameservers.

Production Usage
CoreDNS is critical infrastructure — if it fails, Pods cannot resolve Service names. In production, run at
least 2 replicas for HA. Monitor CoreDNS metrics via Prometheus. For high-traffic clusters, tune
CoreDNS cache settings and consider using NodeLocal DNSCache to reduce cross-node DNS traffic.

# DNS Resolution Pattern:

# [Link]
# Example: [Link]

# CoreDNS Corefile ConfigMap — Minimal

apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health { lagging 5s }
ready
kubernetes [Link] [Link] [Link] {
pods insecure
fallthrough [Link] [Link]
ttl 30
}
forward . /etc/[Link]
cache 30
loop
reload
loadbalance
}

[Link] Page 91 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

DNS Record
Format Example
Type

ClusterIP [Link] [Link]

Service

Headless [Link] db-

Service [Link]

Pod [Link] [Link]

29. Network Policy

Definition
A NetworkPolicy is a firewall for Pod-to-Pod communication. By default, all Pods can communicate
with each other. NetworkPolicies enable explicit allow-listing — once a policy selects a Pod, only
traffic matching the policy rules is permitted. Policies are namespace-scoped and enforced by the CNI
plugin (Calico, Cilium — Flannel does NOT support NetworkPolicies).

Production Usage
In production, apply a default-deny policy in every namespace and then whitelist specific traffic. This
follows zero-trust networking. Essential for compliance (PCI-DSS, HIPAA) and multi-tenant isolation.

[Link] Page 92 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Default Deny All Ingress

apiVersion: [Link]/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress

---
# Allow frontend to backend on port 8080
apiVersion: [Link]/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: production
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080

30. Labels & Selectors

Definition
Labels are key-value pairs attached to Kubernetes objects for identification and grouping. Selectors
are queries that filter objects based on their labels. Labels are the fundamental mechanism that
connects Kubernetes objects — Services find Pods via label selectors, Deployments manage
ReplicaSets by labels. Labels are NOT unique — multiple objects can share the same labels.

Production Usage
Establish a consistent labeling convention. Common labels: app , environment , version , team ,
tier . Kubernetes recommends the [Link]/* label prefix. Labels enable efficient

[Link] Page 93 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

querying ( kubectl get pods -l app=webapp ), cost tracking, and operational management.

# Recommended Labels
apiVersion: v1
kind: Pod
metadata:
name: webapp
labels:
[Link]/name: webapp
[Link]/version: "1.2.0"
[Link]/component: frontend
[Link]/part-of: ecommerce
[Link]/managed-by: helm
environment: production
team: platform
spec:
containers:
- name: webapp
image: webapp:1.2.0

# Selector Types:
# Equality-based: app = webapp, environment != staging
# Set-based: app in (webapp, api), tier notin (test)
#
# kubectl examples:
# kubectl get pods -l app=webapp
# kubectl get pods -l 'app in (webapp,api)'
# kubectl get pods -l app=webapp,environment=production

31. Pod Security Standards

Definition
Pod Security Standards (PSS) define three security levels: Privileged (unrestricted), Baseline
(prevents known privilege escalations), and Restricted (hardened — must run as non-root, drop all
capabilities). PSS replaced PodSecurityPolicy (PSP) in K8s 1.25. Enforcement is via the built-in Pod
Security Admission controller using namespace labels.

Production Usage
Apply Restricted level to all application namespaces and Baseline to system namespaces. Use
enforce to block non-compliant Pods, warn to alert, audit to log violations.

[Link] Page 94 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Enforce via Namespace Labels

apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
[Link]/enforce: restricted
[Link]/enforce-version: latest
[Link]/warn: restricted
[Link]/audit: restricted

Level Description Use Case

Privileged No restrictions CNI, storage drivers

Baseline Prevents known escalations System namespaces

Restricted Non-root, drop caps, read-only FS All application workloads

32. TLS in Cluster Communication

Definition
TLS encrypts communication between Kubernetes components and between services. K8s uses TLS
for: API Server ↔ etcd, API Server ↔ Kubelet, and Pod-to-Pod (via service mesh mTLS). The cluster
PKI is bootstrapped by kubeadm and certificates are stored in /etc/kubernetes/pki/ . Certificates
expire (default 1 year) and must be rotated.

Production Usage
Use cert-manager to automate certificate lifecycle. Enable mTLS via Istio or Linkerd for Pod-to-Pod
encryption. Monitor certificate expiration. Rotate before expiry using kubeadm certs renew all .

[Link] Page 95 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# TLS Secret for Ingress — Minimal

apiVersion: v1
kind: Secret
metadata:
name: webapp-tls
namespace: production
type: [Link]/tls
data:
[Link]: LS0tLS1CRUdJTi...
[Link]: LS0tLS1CRUdJTi...

# Key commands:
# kubeadm certs check-expiration
# kubeadm certs renew all
# systemctl restart kubelet

33. Secrets Encryption

Definition
Secrets Encryption at Rest ensures Secrets in etcd are encrypted rather than plain base64. By
default, Secrets are only base64-encoded (NOT encrypted). Encryption at rest is configured via an
EncryptionConfiguration file passed to the API Server. Providers include aescbc , secretbox , and
cloud KMS (AWS KMS, GCP Cloud KMS).

Production Usage
Production clusters MUST enable encryption at rest. Cloud-managed clusters support KMS envelope
encryption. For self-managed clusters, use aescbc or secretbox . Rotate keys periodically. Consider
external secret management (HashiCorp Vault, External Secrets Operator).

[Link] Page 96 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# EncryptionConfiguration — /etc/kubernetes/enc/[Link]
# Pass to API Server: --encryption-provider-config=/etc/kubernetes/enc/[Link]
apiVersion: [Link]/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: c2VjcmV0LWtleS0xMjM0NTY3ODkw
- identity: {}

# After enabling, re-encrypt existing Secrets:

# kubectl get secrets -A -o json | kubectl replace -f -

34. Helm

Definition
Helm is the package manager for Kubernetes — it packages K8s manifests into reusable Charts. A
Chart is a collection of templates, default values, and metadata installed as a Release. Three core
concepts: Chart (package), Release (installed instance), Repository (chart storage). Helm 3 removed
Tiller, making it more secure.

Production Usage
Helm is the standard for deploying third-party software (NGINX Ingress, Prometheus, cert-manager)
and internal apps. Pin chart versions, use [Link] overrides per environment, and store charts in
private registries. Use helm diff plugin to preview changes before upgrading.

[Link] Page 97 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Helm CLI Commands:

# helm repo add bitnami [Link]
# helm repo update
# helm search repo nginx
# helm install my-release bitnami/nginx -n production -f [Link]
# helm upgrade my-release bitnami/nginx -f [Link]
# helm rollback my-release 1
# helm list -n production
# helm uninstall my-release -n production
# helm template my-release bitnami/nginx -f [Link]

# Chart Structure:
# mychart/
# ├── [Link] # Metadata (name, version)
# ├── [Link] # Default configuration
# ├── templates/ # K8s manifest templates
# │ ├── [Link]
# │ ├── [Link]
# │ └── _helpers.tpl
# └── charts/ # Sub-chart dependencies

35. Disaster Recovery Strategy

Definition
Disaster Recovery (DR) is the strategy for restoring cluster state after catastrophic failures. DR covers:
etcd backups (cluster state), Velero backups (resources + PV data), GitOps (manifests in Git as
source of truth), and multi-cluster failover. RPO = max data loss; RTO = max downtime.

Production Usage
Production DR: (1) Automated etcd snapshots every 1-2 hours to object storage. (2) Velero scheduled
backups. (3) GitOps (ArgoCD/Flux) for declarative state. (4) Multi-region clusters with DNS failover. (5)
Regular DR drills quarterly.

[Link] Page 98 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# Disaster Recovery Checklist:

#
# 1. ETCD BACKUP:
# ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db \
# --endpoints=[Link] \
# --cacert=/etc/kubernetes/pki/etcd/[Link] \
# --cert=/etc/kubernetes/pki/etcd/[Link] \
# --key=/etc/kubernetes/pki/etcd/[Link]
#
# 2. ETCD RESTORE:
# ETCDCTL_API=3 etcdctl snapshot restore /backup/[Link] \
# --data-dir=/var/lib/etcd-restored
#
# 3. VELERO BACKUP:
# velero backup create full-backup --include-namespaces production
# velero schedule create daily --schedule="0 1 * * *" --ttl 720h0m0s
#
# 4. VELERO RESTORE:
# velero restore create --from-backup full-backup
#
# 5. GITOPS REBUILD:
# New cluster → install ArgoCD → point to Git repo → auto-rebuild

36. Logs — kubectl logs & Logging Stack

Definition
Logging operates at multiple levels: container logs (stdout/stderr), node-level logs (kubelet, runtime),
and cluster-level logs (API audit). kubectl logs is the primary tool for container logs. For
production, a centralized logging stack (EFK, Loki+Grafana) collects logs using DaemonSet-based
log shippers.

Production Usage
Never rely solely on kubectl logs — logs are lost when Pods are deleted. Deploy a logging pipeline:
Fluent Bit (DaemonSet) → Elasticsearch/Loki (storage) → Kibana/Grafana (visualization). Enable API
Server audit logging for compliance. Use structured JSON logging.

[Link] Page 99 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

# kubectl logs — Essential Commands

# kubectl logs pod-name
# kubectl logs pod-name -c container-name # specific container
# kubectl logs -f pod-name # follow/stream
# kubectl logs pod-name --previous # previous container
# kubectl logs pod-name --tail=100 # last 100 lines
# kubectl logs pod-name --since=1h # last 1 hour
# kubectl logs -l app=webapp --all-containers # by label
# kubectl logs deployment/webapp # from Deployment
#
# Log file locations on nodes:
# /var/log/containers/ — Container log symlinks
# /var/log/pods/ — Pod log directories
# /var/log/syslog — System logs

37. Monitoring & Observability — Prometheus, Grafana,

AlertManager

Definition
The standard monitoring stack: Prometheus (pull-based metrics collection, time-series DB, PromQL),
Grafana (visualization dashboards), and AlertManager (alert routing to Slack, PagerDuty, email).
Prometheus auto-discovers targets using K8s service discovery. Typically deployed via kube-
prometheus-stack Helm chart.

Prometheus
Pull-based monitoring — scrapes /metrics endpoints at intervals. Metric types: Counter (ever-
increasing), Gauge (up/down), Histogram (distribution), Summary (quantiles). Uses PromQL for
querying.

Grafana
Connects to Prometheus as data source. Pre-built dashboards for K8s cluster monitoring, node health,
Pod resources. Supports alerts, annotations, multi-data-source correlation.

AlertManager
Handles alerts from Prometheus — deduplicates, groups, and routes to notification channels. Supports
silencing (mute during maintenance) and inhibition (suppress lower-priority alerts).

Production Usage

[Link] Page 100 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Deploy via helm install kube-prometheus-stack . Monitor: node CPU/memory, Pod usage, API
Server latency, etcd health. Alert on: high Pod restarts, node NotReady, PVC near capacity, certificate
expiry.

# Install:
# helm repo add prometheus-community [Link]
# helm install monitoring prometheus-community/kube-prometheus-stack \
# -n monitoring --create-namespace

# ServiceMonitor — Minimal
apiVersion: [Link]/v1
kind: ServiceMonitor
metadata:
name: webapp-metrics
namespace: monitoring
spec:
selector:
matchLabels:
app: webapp
endpoints:
- port: metrics
interval: 15s

---
# PrometheusRule — Alert Definition
apiVersion: [Link]/v1
kind: PrometheusRule
metadata:
name: pod-alerts
namespace: monitoring
spec:
groups:
- name: pod-health
rules:
- alert: HighPodRestarts
expr: increase(kube_pod_container_status_restarts_total[1h]) > 5
for: 10m
labels:
severity: warning

# Key PromQL Queries:

# CPU: sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)
# Memory: container_memory_working_set_bytes{container!=""}
# Disk: node_filesystem_avail_bytes / node_filesystem_size_bytes

38. EFK Stack

[Link] Page 101 of 106
Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Definition
The EFK Stack (Elasticsearch, Fluent Bit/Fluentd, Kibana) is a centralized logging solution. Fluent Bit
runs as a DaemonSet collecting container logs from /var/log/containers/ . Logs are shipped to
Elasticsearch for storage and indexing. Kibana provides the web UI for searching and visualizing logs.

Production Usage
Use Fluent Bit over Fluentd for lower resource usage. Size Elasticsearch based on log volume (7-30
days retention). Use index lifecycle management (ILM) to auto-delete old indices. For cost-effective
alternatives, consider Grafana Loki or managed services (AWS OpenSearch, GCP Cloud Logging).

# Fluent Bit DaemonSet — Minimal

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit
namespace: logging
spec:
selector:
matchLabels:
app: fluent-bit
template:
metadata:
labels:
app: fluent-bit
spec:
containers:
- name: fluent-bit
image: fluent/fluent-bit:latest
volumeMounts:
- name: varlog
mountPath: /var/log
- name: containers
mountPath: /var/log/containers
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/log
- name: containers
hostPath:
path: /var/log/containers

# EFK Flow:
# Fluent Bit (DaemonSet) → Elasticsearch (StatefulSet) → Kibana (Deployment)

[Link] Page 102 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

39. Metrics Server

Definition
Metrics Server is a lightweight, in-memory metrics aggregator. It collects CPU and memory usage
from Kubelets and exposes them via the Metrics API. Required for kubectl top and HPA to
function. NOT a monitoring solution — stores only the latest snapshot (no history).

Production Usage
Install in every cluster. Enables kubectl top nodes and kubectl top pods . HPA reads metrics
from Metrics Server for scaling. Managed clusters usually pre-install it.

# Install:
# kubectl apply -f [Link]
#
# Verify:
# kubectl top nodes
# kubectl top pods -n production

# Metrics Server Deployment — Minimal

apiVersion: apps/v1
kind: Deployment
metadata:
name: metrics-server
namespace: kube-system
spec:
template:
spec:
containers:
- name: metrics-server
args:
- --cert-dir=/tmp
- --secure-port=10250
- --kubelet-preferred-address-types=InternalIP
- --metric-resolution=15s

40. Cordon, Drain & PodDisruptionBudget

Definition
Cordon marks a node as unschedulable. Drain cordons the node AND evicts all Pods. Uncordon
marks it schedulable again. PodDisruptionBudget (PDB) sets minimum available (or max unavailable)

[Link] Page 103 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Pods during voluntary disruptions. PDBs prevent drain from removing too many Pods at once.

Production Usage
Used during node maintenance and upgrades: (1) Create PDBs. (2) Cordon. (3) Drain (respects PDBs).
(4) Perform maintenance. (5) Uncordon. Always use --ignore-daemonsets with drain.

# Commands:
# kubectl cordon node-1
# kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
# kubectl uncordon node-1
# kubectl get nodes # SchedulingDisabled = cordoned

# PDB — Minimal
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: webapp-pdb
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app: webapp

# PDB ensures:
# - During drain, at least 2 webapp Pods remain running
# - Drain WAITS if evicting would violate the budget
# - Only for VOLUNTARY disruptions (drain, upgrade)
# - Does NOT protect against node crashes

Quick Interview Reference Card

Topic One-Liner

Pod Smallest deployable unit; one or more containers sharing network/storage

ReplicaSet Ensures N identical Pod replicas are always running

Deployment Manages ReplicaSets with rolling updates and rollbacks

Service Stable network endpoint for a set of Pods (ClusterIP/NodePort/LB)

Ingress HTTP/HTTPS routing, SSL termination, virtual hosting

ConfigMap Non-sensitive configuration as key-value pairs

[Link] Page 104 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Secret Sensitive data (passwords, keys) in base64 encoding

Namespace Virtual cluster for logical resource isolation

PV/PVC PV = storage resource; PVC = user's request for storage

StorageClass Enables dynamic PV provisioning

RBAC Who (subjects) can do what (verbs) on which (resources)

DaemonSet One Pod per node (logging, monitoring agents)

StatefulSet Ordered, persistent identity for stateful apps (databases)

Headless Service No ClusterIP; DNS resolves to individual Pod IPs

HPA Auto-scale Pod count based on CPU/memory/custom metrics

VPA Auto-adjust Pod resource requests/limits

Taints Node repels Pods unless they tolerate the taint

Tolerations Pod's permission to run on tainted nodes

Node Affinity Schedule Pods on specific nodes (hard/soft rules)

Pod Anti-Affinity Spread Pods across different nodes/zones

Liveness Probe Is container alive? If no → restart

Readiness Probe Is container ready? If no → remove from Service

Startup Probe Has container started? Protects slow-starting apps

Init Container Setup container that runs before app containers

CNI Network plugin that assigns IPs and routes to Pods

cert-manager Automates TLS certificate provisioning and renewal

Velero Backup and restore cluster resources and volumes

Istio Service mesh for traffic management, security, observability

PDB Ensures minimum availability during disruptions

Job Runs Pods to completion; for batch tasks, migrations, one-off scripts

CronJob Creates Jobs on a cron schedule (backups, cleanup, reports)

CoreDNS Cluster DNS server; resolves [Link]

NetworkPolicy Firewall for Pod-to-Pod traffic; default-deny + allow-list

Labels & Selectors Key-value pairs for grouping; selectors query/filter objects by labels

[Link] Page 105 of 106

Complete Kubernetes Guide — Interview Ready 30/06/26, 7:00 PM

Pod Security Standards Privileged/Baseline/Restricted security levels via namespace labels

TLS (Cluster) Encrypts component communication; certs in /etc/kubernetes/pki/

Secrets Encryption Encrypts Secrets at rest in etcd (aescbc/KMS); base64 ≠ encrypted

Helm K8s package manager; Charts = templated manifests + values

Disaster Recovery etcd snapshots + Velero + GitOps + multi-cluster failover

kubectl logs View container stdout/stderr; use -f, --previous, --since, --tail

Prometheus Pull-based metrics collection; PromQL; scrapes /metrics endpoints

Grafana Visualization dashboards for Prometheus metrics

AlertManager Routes, deduplicates, groups Prometheus alerts to Slack/PagerDuty

EFK Stack Elasticsearch + Fluent Bit + Kibana for centralized log aggregation

Metrics Server In-memory CPU/memory aggregator; required for kubectl top and HPA

Cordon/Drain Cordon = unschedulable; Drain = evict Pods + cordon; Uncordon = restore

Last Updated: June 2026

Covers: Kubernetes 1.28 – 1.31
Format: Interview-Ready with YAML Manifests

Complete Kubernetes Guide — Interview Ready • Generated May 2026

[Link] Page 106 of 106