Thursday, September 17, 2026

Kubernetes: A Comprehensive Guide to Containers, Pods, Deployments, Services, Networking, Storage, Security & Production

Kubernetes has become one of the most widely used platforms for running containerized applications at scale.

Docker makes it relatively easy to build and run containers.

Kubernetes answers the much larger question:

What happens when you have hundreds or thousands of containers running across multiple servers and those applications need to be deployed, scaled, monitored, updated, and recovered automatically?

Kubernetes provides an orchestration layer for that problem.

This guide starts with the fundamentals and progresses toward production architecture, networking, storage, security, troubleshooting, and real-world deployment patterns.

1. What Is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform.

It helps automate:

Container deployment
Scheduling
Scaling
Service discovery
Load balancing
Rolling updates
Rollbacks
Self-healing
Configuration management
Secret management
Storage orchestration
Workload placement

Without Kubernetes, you might manually manage:


Server 1
 ├── Container A
 ├── Container B
 └── Container C

Server 2
 ├── Container D
 ├── Container E
 └── Container F

Server 3
 ├── Container G
 └── Container H

Kubernetes turns this into a cluster that can manage workloads declaratively.


                  Kubernetes Cluster
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
      Node 1            Node 2            Node 3
        │                │                │
      Pods             Pods             Pods

2. Why Do We Need Kubernetes?

Imagine you have an application with:


Frontend
Backend API
Authentication
Payment
Redis
PostgreSQL
Kafka
Workers
Monitoring

Initially you might run:


10 containers

Then your application grows:


100 containers

Eventually:


1,000+ containers

Now several questions appear:

Which server should run each container?
What happens if a server fails?
What happens if a container crashes?
How do we deploy a new application version?
How do we roll back?
How do we expose applications to users?
How do containers discover each other?
How do we scale based on traffic?
How do we manage configuration?
How do we attach persistent storage?

Kubernetes automates many of these operations.

3. Kubernetes vs Docker

This distinction is extremely important.

Docker

Docker primarily provides container tooling:


Build image
    ↓
Store image
    ↓
Run container

Kubernetes

Kubernetes orchestrates containerized workloads:


Deploy
   ↓
Schedule
   ↓
Run
   ↓
Monitor
   ↓
Scale
   ↓
Replace failed workloads
   ↓
Update
   ↓
Rollback

A simplified relationship:


Docker / Build Tools
        │
        ▼
Container Image
        │
        ▼
Container Runtime
        │
        ▼
Kubernetes
        │
        ├── Scheduling
        ├── Networking
        ├── Scaling
        ├── Storage
        ├── Self-healing
        └── Deployments

Modern Kubernetes clusters commonly use containerd or another Kubernetes-compatible container runtime. Docker Engine itself is no longer required as Kubernetes' runtime.

4. Kubernetes Architecture

A Kubernetes cluster has two major conceptual parts:


Control Plane
      │
      ▼
Worker Nodes

For example:


                 Kubernetes Cluster
                         │
              ┌──────────┴──────────┐
              │                     │
         Control Plane          Worker Nodes
              │              ┌──────┼──────┐
              │              │      │      │
              ▼              ▼      ▼      ▼
         API Server         Node   Node   Node
         etcd
         Scheduler
         Controllers

5. Control Plane

The control plane manages the cluster.

Major components include:

kube-apiserver

The central API endpoint for Kubernetes.

Almost everything interacts with the Kubernetes API.


kubectl
   │
   ▼
API Server
   │
   ├── etcd
   ├── Scheduler
   └── Controllers

6. etcd

etcd is a distributed key-value store used by Kubernetes to store cluster state.

Conceptually:


etcd
 │
 ├── Pods
 ├── Deployments
 ├── Services
 ├── Secrets
 ├── Configurations
 └── Cluster metadata

Because etcd contains critical cluster state, its availability and backup strategy are extremely important.

A production cluster should have a proper etcd backup and recovery strategy.

7. kube-scheduler

The scheduler decides where Pods should run.

Suppose you have:


Node 1 → 2 CPU available
Node 2 → 8 CPU available
Node 3 → 1 CPU available

A new Pod arrives requesting:


4 CPU

The scheduler evaluates the available nodes and constraints and selects a suitable node.

It considers factors such as:

CPU
Memory
Resource requests
Taints
Tolerations
Node affinity
Pod affinity
Pod anti-affinity
Scheduling policies

8. Controller Manager

Kubernetes controllers continuously compare:


Desired State
       vs
Current State

Example:

You specify:


replicas: 3

Kubernetes observes:


Desired = 3
Actual = 2

The controller works toward:


Desired = 3
Actual = 3

This reconciliation model is one of the fundamental ideas behind Kubernetes.

9. Worker Nodes

Worker nodes run application workloads.

A typical node contains:


Worker Node
│
├── kubelet
├── Container Runtime
├── kube-proxy
└── Pods

10. kubelet

The kubelet is the node-level agent.

Its responsibility is essentially:

Make sure the workloads assigned to this node are running as specified.

The kubelet communicates with the Kubernetes API server and interacts with the container runtime.

11. Container Runtime

The container runtime actually runs containers.

Common runtime technology includes:


containerd
CRI-O

Kubernetes interacts with the runtime through the Kubernetes Container Runtime Interface (CRI).

12. kube-proxy

kube-proxy historically provides node-level networking functionality associated with Kubernetes Services.

Depending on the cluster networking implementation, some or much of this functionality may be implemented by the CNI/networking stack instead.

The important concept is that Kubernetes needs mechanisms to route traffic toward Service backends.

13. Pods

The Pod is the smallest deployable unit in Kubernetes.

This is one of the most important concepts to understand.

You normally don't deploy a container directly.

You deploy a:

Pod

A Pod can contain one or more containers.

Most commonly:


Pod
└── Application Container

But sometimes:


Pod
├── Application Container
└── Sidecar Container

Containers inside the same Pod share:

Network namespace
Pod IP
localhost
Certain storage volumes

14. Why Not Just Run Containers?

Because Kubernetes needs a higher-level abstraction around containers.

Think:


Container
   ↓
Pod
   ↓
Deployment
   ↓
Service
   ↓
Ingress / Gateway

Each layer solves a different problem.

15. Creating Your First Pod

Example:


apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.28
      ports:
        - containerPort: 80

Save as:


pod.yaml

Apply:


kubectl apply -f pod.yaml

Check:


kubectl get pods

16. kubectl

kubectl is the primary command-line tool for interacting with Kubernetes.

Basic commands:


kubectl get nodes


kubectl get pods


kubectl get services


kubectl get deployments

Detailed information:


kubectl describe pod nginx-pod

Logs:


kubectl logs nginx-pod

Execute a command:


kubectl exec -it nginx-pod -- /bin/sh

Delete:


kubectl delete pod nginx-pod

17. Namespaces

Namespaces provide logical isolation within a cluster.

For example:


Cluster
│
├── development
│   ├── frontend
│   └── backend
│
├── staging
│   ├── frontend
│   └── backend
│
└── production
    ├── frontend
    └── backend

Create:


kubectl create namespace development

Deploy into it:


kubectl apply -f app.yaml -n development

List Pods:


kubectl get pods -n development

Namespaces are useful for organization, access control, policies, and resource management, but they are not equivalent to a separate physical cluster.

18. Deployments

You generally shouldn't manage individual application Pods manually.

Instead, use a Deployment for stateless applications.

Example:


apiVersion: apps/v1
kind: Deployment

metadata:
  name: nginx

spec:
  replicas: 3

  selector:
    matchLabels:
      app: nginx

  template:
    metadata:
      labels:
        app: nginx

    spec:
      containers:
        - name: nginx
          image: nginx:1.28
          ports:
            - containerPort: 80

Apply:


kubectl apply -f deployment.yaml

Check:


kubectl get deployments

Then:


kubectl get pods

You should see approximately:


nginx-xxxxx
nginx-yyyyy
nginx-zzzzz

19. ReplicaSets

A Deployment manages ReplicaSets.

Conceptually:


Deployment
     │
     ▼
ReplicaSet
     │
     ├── Pod
     ├── Pod
     └── Pod

If one Pod disappears:


Desired = 3
Actual = 2

The ReplicaSet works to create another Pod.

This is Kubernetes' self-healing model.

20. Scaling Deployments

You can scale manually:


kubectl scale deployment nginx --replicas=5

Now:


Desired Pods = 5

Check:


kubectl get pods

21. Rolling Updates

Suppose you currently have:


nginx:1.27

You want:


nginx:1.28

Update:


kubectl set image deployment/nginx nginx=nginx:1.28

Kubernetes can progressively replace old Pods with new ones.


Old Version
Pod A
Pod B
Pod C

        ↓

New Version
Pod A
Pod B
Pod C

The exact rollout behavior depends on the Deployment strategy and configuration.

22. Checking a Rollout


kubectl rollout status deployment/nginx

History:


kubectl rollout history deployment/nginx

Rollback:


kubectl rollout undo deployment/nginx

This is extremely useful during production deployments.

23. Services

Pods are ephemeral.

Their IP addresses can change.

So this is a bad architecture:


Frontend
   ↓
Pod IP: 10.244.1.15

Instead:


Frontend
   ↓
Service
   ↓
Pods

A Kubernetes Service provides a stable network endpoint for a set of Pods.

24. Service Example


apiVersion: v1
kind: Service

metadata:
  name: nginx-service

spec:
  selector:
    app: nginx

  ports:
    - port: 80
      targetPort: 80

Apply:


kubectl apply -f service.yaml

Check:


kubectl get services

The Service selects Pods using:


selector:
  app: nginx

This is why matching labels are critical.

25. Kubernetes Service Types

Common Service types are:


ClusterIP
NodePort
LoadBalancer
ExternalName

ClusterIP

Default.

Accessible within the cluster.


Backend
   ↓
ClusterIP Service
   ↓
Pods

NodePort

Exposes the Service through a port on each node.


Client
  ↓
NodeIP:NodePort
  ↓
Service
  ↓
Pods

LoadBalancer

Usually integrates with a cloud provider or external load-balancing implementation.


Internet
   ↓
Cloud Load Balancer
   ↓
Kubernetes Service
   ↓
Pods

26. Kubernetes Networking

Kubernetes networking can initially feel complicated.

A simplified model is:


Pod A
10.244.1.10
      │
      ▼
Pod B
10.244.2.20

Pods generally need to be able to communicate with each other across nodes without requiring application-level NAT between Pods.

The actual networking is implemented by a CNI plugin.

Examples include:

Cilium
Calico
Flannel
cloud-provider networking implementations

27. Container Network Interface — CNI

Kubernetes relies on CNI-based networking implementations for Pod networking.

The CNI layer handles things such as:


Pod Network
     │
     ├── Pod IP allocation
     ├── Interfaces
     ├── Routing
     └── Network policy capabilities

The specific capabilities depend on the CNI implementation.

28. DNS in Kubernetes

Kubernetes normally provides cluster DNS.

Suppose:


Service:
database

Another application can typically reach it using:


database

or a fully qualified Service DNS name such as:


database.default.svc.cluster.local

This means applications generally don't need hard-coded Pod IP addresses.

29. ConfigMaps

Configuration that isn't sensitive can be stored in a ConfigMap.

Example:


apiVersion: v1
kind: ConfigMap

metadata:
  name: app-config

data:
  LOG_LEVEL: "INFO"
  APP_MODE: "production"

Then expose it to a Pod as environment variables or mounted files.


envFrom:
  - configMapRef:
      name: app-config

30. Secrets

Sensitive configuration should use Kubernetes Secrets or, preferably in many production environments, an integrated external secret-management solution.

Example:


apiVersion: v1
kind: Secret

metadata:
  name: database-secret

type: Opaque

stringData:
  username: appuser
  password: change-me

Reference:


envFrom:
  - secretRef:
      name: database-secret

Important

Kubernetes Secrets are not automatically equivalent to a secure external vault.

Depending on cluster configuration, Secret data may be stored in etcd, so production clusters should consider:

Encryption at rest
Strict RBAC
Secret rotation
External secret managers
Audit logging

31. Persistent Storage

Pods are ephemeral.

Applications such as databases need persistent storage.

Kubernetes provides storage abstractions including:


PersistentVolume
PersistentVolumeClaim
StorageClass

Conceptually:


Application Pod
      │
      ▼
PersistentVolumeClaim
      │
      ▼
StorageClass / PersistentVolume
      │
      ▼
Storage Backend

32. PersistentVolumeClaim

A Pod can request storage using a PVC.

Example:


apiVersion: v1
kind: PersistentVolumeClaim

metadata:
  name: app-data

spec:
  accessModes:
    - ReadWriteOnce

  resources:
    requests:
      storage: 10Gi

The cluster's storage configuration can dynamically provision suitable storage.

33. StorageClass

A StorageClass describes a class of storage that can be dynamically provisioned.

For example:


StorageClass
     ↓
Cloud Disk / SAN / CSI Backend
     ↓
PersistentVolume
     ↓
PVC
     ↓
Pod

Kubernetes commonly uses the Container Storage Interface (CSI) to integrate with storage systems.

34. StatefulSets

Deployments are excellent for stateless applications.

But what about:

Databases
Kafka
ZooKeeper-like systems
Stateful services

That's where StatefulSet can be useful.

A StatefulSet provides stable identity and ordered management semantics for Pods.

Example:


database-0
database-1
database-2

Instead of random names.

Stateful workloads still require careful architecture, backups, replication, and storage planning. A StatefulSet does not magically make a database highly available.

35. DaemonSets

A DaemonSet ensures that a Pod runs on selected nodes, commonly one Pod per eligible node.

Typical examples:


Node 1 → Monitoring Agent
Node 2 → Monitoring Agent
Node 3 → Monitoring Agent
Node 4 → Monitoring Agent

Use cases include:

Log collectors
Node monitoring
Security agents
Networking components

36. Jobs

A Job is designed for a workload that should run to completion.

Example:


Database Migration
      ↓
Run
      ↓
Complete

Example:


apiVersion: batch/v1
kind: Job

metadata:
  name: database-migration

spec:
  template:
    spec:
      restartPolicy: Never

      containers:
        - name: migration
          image: myapp:1.0
          command:
            - ./migrate

37. CronJobs

A CronJob runs Jobs on a schedule.

For example:


Every night at 02:00
        ↓
Database backup

Example:


apiVersion: batch/v1
kind: CronJob

metadata:
  name: backup

spec:
  schedule: "0 2 * * *"

  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure

          containers:
            - name: backup
              image: backup-image:1.0

38. Ingress

Ingress provides HTTP/HTTPS routing into a cluster.

Example:


                  Internet
                     │
                     ▼
                  Ingress
                /           \
               /             \
              ▼               ▼
         frontend.example   api.example
              │               │
              ▼               ▼
          Frontend          Backend

Ingress itself is an API object; you also need an Ingress Controller to implement the behavior.

Examples include controllers based on:

NGINX
HAProxy
Traefik
cloud-provider load balancers

39. Gateway API

The Kubernetes ecosystem also has the newer Gateway API, which provides a more expressive model for traffic management than the traditional Ingress API.

Conceptually:


Internet
   │
   ▼
Gateway
   │
   ├── HTTPRoute
   ├── TLSRoute
   └── Backend

For new platform designs, Gateway API may be worth evaluating alongside Ingress depending on your Kubernetes distribution and networking stack.

40. Resource Requests and Limits

This is extremely important in production.

A container can specify:


resources:
  requests:
    cpu: "500m"
    memory: "512Mi"

  limits:
    cpu: "1"
    memory: "1Gi"

Request

Represents the resources Kubernetes should consider when scheduling the Pod.

Limit

Caps resource consumption according to Kubernetes/container-runtime behavior.

For CPU:


500m = 0.5 CPU
1000m = 1 CPU

For memory:


512Mi
1Gi
2Gi

41. QoS Classes

Based on resource configuration, Kubernetes assigns Pods a QoS classification such as:


Guaranteed
Burstable
BestEffort

These classifications can affect resource pressure behavior and eviction decisions.

Production workloads should have resource requests configured thoughtfully.

42. Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) changes the number of Pod replicas based on metrics.

For example:


CPU 20%
   ↓
2 Pods

CPU 70%
   ↓
5 Pods

CPU 90%
   ↓
8 Pods

Conceptually:


Metrics
   ↓
HPA
   ↓
Deployment
   ↓
More/Fewer Pods

Example:


kubectl autoscale deployment nginx \
  --cpu-percent=70 \
  --min=2 \
  --max=10

In production, autoscaling can also be based on custom or external metrics depending on the metrics stack.

43. Vertical Pod Autoscaler

The Vertical Pod Autoscaler (VPA) focuses on resource requests/limits rather than primarily changing replica count.

Conceptually:


Application
     ↓
Observed Resource Usage
     ↓
VPA Recommendation
     ↓
CPU / Memory Adjustment

VPA and HPA solve different scaling dimensions and require careful configuration when used together.

44. Cluster Autoscaling

HPA might increase Pods from:


3 → 20

But what if the existing nodes don't have enough capacity?

A cluster autoscaling mechanism can add or remove nodes according to workload demand.


More Pods
   ↓
Insufficient Capacity
   ↓
More Nodes

Cloud environments commonly integrate node autoscaling with their compute infrastructure.

45. Node Labels

Nodes can have labels.


kubectl label nodes node1 workload=database

Then a workload can request:


nodeSelector:
  workload: database

This means the Pod should be scheduled onto nodes matching that label.

46. Taints and Tolerations

Taints allow nodes to repel Pods unless those Pods explicitly tolerate the taint.

Example:


GPU Node
   │
   └── taint: gpu=true

A GPU workload can have:


tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

This is useful for dedicated node pools.

47. Node Affinity

Node affinity provides more expressive scheduling rules than a simple nodeSelector.

For example:


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: workload
              operator: In
              values:
                - high-memory

This is particularly useful in heterogeneous clusters.

48. Pod Affinity and Anti-Affinity

Sometimes you want Pods close to each other.

Example:


API Pod
   ↕
Cache Pod

That's affinity.

Sometimes you want replicas separated:


Node 1 → API replica 1
Node 2 → API replica 2
Node 3 → API replica 3

That's anti-affinity.

This can improve resilience against node failures.

49. Labels and Selectors

Kubernetes relies heavily on labels.

Example:


labels:
  app: payment
  tier: backend

A Service can select:


selector:
  app: payment

A Deployment can manage Pods using:


matchLabels:
  app: payment

Think of labels as Kubernetes' way of answering:

Which objects belong to this workload?

50. Probes

Kubernetes supports three important types of application probes.

Startup Probe

Used when an application takes significant time to start.

Liveness Probe

Answers:

Is the application still alive?

If it repeatedly fails, Kubernetes may restart the container.

Readiness Probe

Answers:

Can this application currently receive traffic?

This is different from liveness.

For example:


Application running
       │
       ├── Liveness = OK
       │
       └── Readiness = NOT OK

The container may remain running but should not receive Service traffic.

51. Example Probes


livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

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

A well-designed application should expose health endpoints appropriate to its architecture.

52. Security Architecture

Kubernetes security operates at multiple layers.


User
 │
 ▼
Authentication
 │
 ▼
Authorization / RBAC
 │
 ▼
API Server
 │
 ▼
Namespace / Resource
 │
 ▼
Pod Security
 │
 ▼
Network Policy
 │
 ▼
Container

Security should not be treated as a single feature.

53. RBAC

Role-Based Access Control determines what users and service accounts can do.

For example:


Developer
   ↓
Can read Pods
Can view logs
Cannot delete production workloads

A Role might look like:


apiVersion: rbac.authorization.k8s.io/v1
kind: Role

metadata:
  namespace: development
  name: pod-reader

rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Then a RoleBinding associates that Role with a user or ServiceAccount.

54. ServiceAccounts

Applications running inside Kubernetes can use ServiceAccounts to authenticate to the Kubernetes API when necessary.

Example:


serviceAccountName: backend

Avoid giving applications unnecessarily broad permissions.

The principle should be:

Least privilege.

55. Network Policies

Without appropriate network restrictions, workloads may have broader network connectivity than necessary.

NetworkPolicy can express rules such as:


Frontend
   ↓
Backend

Backend
   ↓
Database

Frontend ─X→ Database

Support depends on the cluster's networking implementation.

56. Pod Security

Containers should ideally:

Run as non-root
Drop unnecessary Linux capabilities
Use read-only filesystems where practical
Avoid privileged mode
Minimize permissions
Use security contexts

Example:


securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

Not every application can use every restriction, but they should be evaluated deliberately.

57. Service Mesh

For large microservice environments, a service mesh can provide infrastructure-level capabilities such as:

mTLS
Traffic management
Service identity
Telemetry
Retries
Policy

Architecture:


Service A
   │
Sidecar / Node Proxy
   │
   ▼
Network
   │
Sidecar / Node Proxy
   │
   ▼
Service B

Depending on the technology, the data-plane architecture can differ. Service meshes should be introduced only when their operational complexity is justified.

58. Kubernetes Observability

Production Kubernetes needs observability across several layers.


                    Observability
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Metrics          Logs          Traces
          │              │              │
          ▼              ▼              ▼
      Prometheus       Loki/ELK       OpenTelemetry

Commonly monitored components include:

Nodes
Pods
Containers
API server
Scheduler
Controller manager
Network
Storage
Applications

59. Prometheus and Kubernetes

Prometheus is widely used for Kubernetes metrics.

Typical architecture:


Kubernetes
    │
    ├── kube-state-metrics
    ├── Node metrics
    └── Application metrics
             │
             ▼
         Prometheus
             │
             ▼
          Grafana

Grafana can visualize:

CPU
Memory
Pod restarts
Network
Request rates
Latency
Error rates
Node health

60. Logging

A common architecture is:


Container stdout/stderr
          │
          ▼
     Log Collector
          │
          ▼
    Central Log Store
          │
          ▼
       Dashboard

Popular technologies include combinations involving:

Fluent Bit
Fluentd
OpenSearch
Elasticsearch
Loki
Grafana

The exact stack depends on organizational requirements.

61. Kubernetes Deployment Architecture

A typical production architecture might look like:


                       Internet
                          │
                          ▼
                 Load Balancer / Gateway
                          │
                          ▼
                       Ingress
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
          Frontend                 Backend
              │                       │
              │                 ┌─────┴─────┐
              │                 ▼           ▼
              │              Redis      PostgreSQL
              │
              ▼
        Kubernetes Cluster

Behind this you may also have:


Monitoring
Logging
Tracing
Secrets
Storage
CI/CD
Registry

62. Complete Kubernetes Application Flow

Consider a user opening:


https://example.com

A simplified request flow might be:


Internet
   │
   ▼
DNS
   │
   ▼
Cloud Load Balancer
   │
   ▼
Ingress / Gateway
   │
   ▼
Frontend Service
   │
   ▼
Frontend Pods
   │
   ▼
Backend Service
   │
   ▼
Backend Pods
   │
   ├── Redis
   │
   └── Database

Kubernetes manages much of the workload lifecycle underneath.

63. A Realistic Application Manifest

A simple production-oriented Deployment might look like:


apiVersion: apps/v1
kind: Deployment

metadata:
  name: backend

spec:
  replicas: 3

  strategy:
    type: RollingUpdate

  selector:
    matchLabels:
      app: backend

  template:
    metadata:
      labels:
        app: backend

    spec:
      containers:
        - name: backend
          image: registry.example.com/backend:1.4.0

          ports:
            - containerPort: 8080

          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"

            limits:
              cpu: "1"
              memory: "1Gi"

          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

          livenessProbe:
            httpGet:
              path: /health
              port: 8080

Then expose it:


apiVersion: v1
kind: Service

metadata:
  name: backend

spec:
  selector:
    app: backend

  ports:
    - port: 80
      targetPort: 8080

64. Kubernetes Declarative Model

This is arguably the most important conceptual difference from traditional administration.

Traditional approach:


Run command
Restart service
Copy files
Change configuration
Manually scale

Kubernetes approach:


Desired State
      ↓
YAML
      ↓
Kubernetes API
      ↓
Controllers
      ↓
Actual State

For example:


replicas: 5

You're not telling Kubernetes:

“Create five containers.”

You're declaring:

“The desired state is five replicas.”

Kubernetes continuously works toward that state.

65. Imperative vs Declarative

Imperative


kubectl scale deployment app --replicas=5

You're directly asking Kubernetes to perform an action.

Declarative


spec:
  replicas: 5

Then:


kubectl apply -f deployment.yaml

You're defining the desired state.

Declarative configuration is particularly valuable for:

GitOps
Infrastructure as Code
Auditing
Reproducibility
Automated deployments

66. Kubernetes and GitOps

A common modern architecture is:


Git Repository
      │
      ▼
Kubernetes YAML / Helm / Kustomize
      │
      ▼
GitOps Controller
      │
      ▼
Kubernetes Cluster

Common GitOps technologies include:

Argo CD
Flux

The repository becomes the source of truth for desired configuration.

67. Helm

Kubernetes YAML can become repetitive.

Helm provides a packaging and templating mechanism commonly used for Kubernetes applications.

Typical structure:


mychart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

Install:


helm install myapp ./mychart

Upgrade:


helm upgrade myapp ./mychart

Rollback:


helm rollback myapp 1

Helm is often described as a package manager for Kubernetes, though it also provides templating and release-management functionality.

68. Kustomize

Kustomize takes another approach.

Instead of templates, it allows you to compose and customize Kubernetes manifests.

Example:


base/
├── deployment.yaml
├── service.yaml
└── kustomization.yaml

overlays/
├── dev/
├── staging/
└── production/

Conceptually:


Base Configuration
       │
       ├── Development
       ├── Staging
       └── Production

Kustomize is integrated into kubectl.

69. Kubernetes Upgrade Strategy

Kubernetes itself needs upgrades.

A production upgrade involves more than:


apt upgrade

You need to consider:


Control Plane
     ↓
Worker Nodes
     ↓
CNI
     ↓
CSI
     ↓
Ingress / Gateway
     ↓
Helm Charts
     ↓
Applications

Before upgrading:

Check version compatibility
Review deprecated APIs
Back up critical cluster state
Test in a non-production environment
Review admission policies
Validate CNI/CSI compatibility
Have a rollback/recovery plan

70. Kubernetes Troubleshooting

A structured troubleshooting process is essential.

Start with:


kubectl get nodes

Then:


kubectl get pods -A

Look for:


Pending
CrashLoopBackOff
ImagePullBackOff
ErrImagePull
ContainerCreating
Terminating

71. CrashLoopBackOff

If you see:


CrashLoopBackOff

inspect:


kubectl logs <pod>

If there are multiple containers:


kubectl logs <pod> -c <container>

Also check:


kubectl describe pod <pod>

Potential causes include:

Application crash
Incorrect command
Missing environment variables
Configuration error
Dependency failure
Probe failure
Permission issue

72. ImagePullBackOff

Check:


kubectl describe pod <pod>

Potential causes:

Image doesn't exist
Incorrect tag
Private registry authentication failure
Network problem
Registry availability issue

For private registries, Kubernetes may need an appropriate image pull secret or workload identity mechanism.

73. Pending Pods

If a Pod remains:


Pending

check:


kubectl describe pod <pod>

Common causes:

Insufficient CPU
Insufficient memory
Node affinity constraints
Taints
Missing storage
Unsatisfied scheduling constraints

Check:


kubectl get nodes

and:


kubectl describe node <node>

74. Service Not Working

Check:


kubectl get svc

Then:


kubectl describe svc <service>

Check endpoints:


kubectl get endpoints

or EndpointSlices:


kubectl get endpointslices

A common problem is a selector mismatch.

For example:

Service:


selector:
  app: backend

Pod:


labels:
  app: api

Result:


Service
   ↓
No matching Pods

No endpoints means there is nothing for the Service to route to.

75. Useful kubectl Commands

Cluster


kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide

Everything


kubectl get all

Pods


kubectl get pods
kubectl get pods -o wide
kubectl describe pod <pod>
kubectl logs <pod>

Deployments


kubectl get deployments
kubectl describe deployment <deployment>
kubectl rollout status deployment/<deployment>

Services


kubectl get svc
kubectl describe svc <service>

Events


kubectl get events --sort-by=.lastTimestamp

Resource usage

If metrics-server is installed:


kubectl top nodes
kubectl top pods

Execute


kubectl exec -it <pod> -- /bin/sh

76. Kubernetes Object Hierarchy

A useful mental model is:


Cluster
│
├── Namespace
│
├── Deployment
│      │
│      └── ReplicaSet
│             │
│             └── Pods
│                    │
│                    └── Containers
│
├── Service
│      │
│      └── Selects Pods
│
├── ConfigMap
├── Secret
├── PVC
└── Ingress / Gateway

77. Kubernetes Production Checklist

Before putting an application into production, consider:

Application

Container image is versioned
Application logs to stdout/stderr
Graceful shutdown implemented
Health endpoints available
Readiness probe configured
Liveness probe configured where appropriate
Startup probe used for slow-starting applications

Resources

Security

Networking

Storage

Persistent storage configured where necessary
Backup strategy defined
Restore procedure tested

Operations

78. Kubernetes vs Docker Compose

Feature	Docker Compose	Kubernetes
Local development	Excellent	Possible but heavier
Multi-container apps	Yes	Yes
Multi-node orchestration	Limited	Yes
Self-healing	Basic restart mechanisms	Extensive
Autoscaling	Limited	Yes
Rolling deployments	Limited	Yes
Service discovery	Yes	Yes
Advanced scheduling	Limited	Yes
RBAC	Limited	Extensive
Production cluster orchestration	Limited	Designed for it
Learning curve	Lower	Higher

A common workflow is:


Docker / Compose
       ↓
Development
       ↓
Container Registry
       ↓
Kubernetes
       ↓
Production

79. Kubernetes vs Virtual Machines

Kubernetes doesn't necessarily replace virtual machines.

A very common architecture is:


Physical Infrastructure
        ↓
Cloud / Virtual Machines
        ↓
Kubernetes Nodes
        ↓
Pods
        ↓
Containers

So you might have:


VM
└── Kubernetes Node
    ├── Pod
    ├── Pod
    └── Pod

Kubernetes handles application orchestration while the underlying infrastructure provides compute, networking, and storage.

80. Kubernetes for Big Data

Kubernetes can also be used for data workloads, although the suitability depends heavily on the workload and operational requirements.

For example:


Kubernetes
│
├── Spark workloads
├── Kafka
├── Trino
├── Airflow
├── Jupyter
├── ML workloads
└── Data APIs

For someone working with Hadoop/Spark ecosystems, an important distinction is:


Traditional Hadoop
        ↓
YARN
        ↓
Resource Scheduling

Kubernetes
        ↓
Pod Scheduling
        ↓
Containerized Workloads

Modern data platforms increasingly use Kubernetes for selected workloads, while traditional Hadoop distributions and storage architectures may continue using their own cluster-management models.

81. Kubernetes for AI/ML

Kubernetes is particularly useful when an organization has many AI workloads.

Example:


                    Kubernetes
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
   LLM Service       Embedding API      Training
       │                 │                 │
       ▼                 ▼                 ▼
     GPU               CPU/GPU            GPU

GPU nodes can be labeled and tainted:


gpu=true

AI workloads can then request GPU resources.

Conceptually:


resources:
  limits:
    nvidia.com/gpu: 1

The exact GPU setup depends on the Kubernetes distribution, GPU operator/device-plugin stack, driver installation, and container runtime configuration.

82. A Complete Kubernetes Platform

A mature Kubernetes platform can look like:


                         USERS
                           │
                           ▼
                    DNS / CDN / WAF
                           │
                           ▼
                    Load Balancer
                           │
                           ▼
                    Gateway / Ingress
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
        Frontend                       APIs
                                         │
                         ┌───────────────┼──────────────┐
                         ▼               ▼              ▼
                       Redis          Kafka          Database
                         
                    ───── Kubernetes ─────
                         │
             ┌───────────┼───────────┐
             ▼           ▼           ▼
           Node        Node        Node
             │           │           │
            Pods        Pods        Pods

                    Supporting Platform
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   Prometheus         Logging          Tracing
        │                │                │
        └────────────────┼────────────────┘
                         ▼
                      Grafana

                         +
                     CI/CD
                         │
                         ▼
                    Registry
                         │
                         ▼
                    Kubernetes

83. The Most Important Kubernetes Concepts

If you're learning Kubernetes, don't try to memorize hundreds of commands first.

Master these concepts in this order:


1. Containers
      ↓
2. Pods
      ↓
3. Deployments
      ↓
4. ReplicaSets
      ↓
5. Services
      ↓
6. Labels & Selectors
      ↓
7. ConfigMaps & Secrets
      ↓
8. Volumes & PVCs
      ↓
9. Ingress / Gateway
      ↓
10. Probes
      ↓
11. Resource Requests/Limits
      ↓
12. HPA
      ↓
13. RBAC
      ↓
14. NetworkPolicy
      ↓
15. Helm / Kustomize
      ↓
16. Observability
      ↓
17. GitOps
      ↓
18. Production Operations

84. The Kubernetes Mental Model

If you remember only one architecture, remember this:


                  KUBERNETES

                     Cluster
                       │
             ┌─────────┴─────────┐
             │                   │
        Control Plane        Worker Nodes
             │                   │
             │                   ▼
             │                  Pods
             │                   │
             │             ┌─────┴─────┐
             │             ▼           ▼
             │        Container    Container
             │
             ├── API Server
             ├── etcd
             ├── Scheduler
             └── Controllers

Pods
 │
 └── managed by Deployments / StatefulSets / Jobs

Services
 │
 └── provide stable networking to Pods

Ingress / Gateway
 │
 └── expose HTTP(S) applications

PVC
 │
 └── provides persistent storage

ConfigMap / Secret
 │
 └── provides configuration

HPA
 │
 └── scales workloads

RBAC
 │
 └── controls access

CNI
 │
 └── provides cluster networking

CSI
 │
 └── integrates storage

85. Kubernetes in One Sentence

Docker packages and runs applications in containers; Kubernetes coordinates those workloads across a cluster and continuously works to keep the declared desired state running.

The key transition is:


docker run
     ↓
"Run this container."

Kubernetes
     ↓
"Keep this application running,
with this configuration,
this many replicas,
this networking,
this storage,
and these operational policies."

That is the fundamental idea behind Kubernetes.

Once you understand Pods → Deployments → Services → Networking → Storage → Configuration → Security → Scaling → Observability, you have the foundation needed to move from simply running Kubernetes commands to designing and operating Kubernetes platforms.