LFCA 78 🐧 What Kubernetes Is and Why It Exists - KandZ

You have learned how to run a container. You can build an image, start a container, map a port, and view logs. That works on a single machine. But production is not a single machine. It is a fleet of servers, and the application must run across them, survive failures, scale with demand, and update without downtime. Managing that manually is impossible. Kubernetes is the system that does it.

Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications . It was released by Google in 2014 and is based on over fifteen years of experience running production workloads at scale . The LFCA exam places containers and deployment environments under DevOps Fundamentals, which carries 16% of the total weight . Understanding what Kubernetes is and why it exists is the foundation for every container orchestration topic that follows.

Key point: Kubernetes does not run containers directly. It manages the desired state of a system. You tell Kubernetes what you want — “three copies of this application” — and Kubernetes works continuously to make the actual state match. If a container crashes, Kubernetes replaces it. If a node fails, Kubernetes reschedules the workloads. The system is self-healing because it never stops reconciling the desired state with reality .

Why Kubernetes exists

Docker solved the packaging problem. It made an application and its dependencies into a single portable artifact. But packaging is not the same as running at scale. When you have dozens of containers across multiple servers, new problems appear that Docker alone does not solve.

The scheduling problem. A container needs CPU, memory, and a node to run on. If you have ten servers and fifty containers, which container goes on which server? The answer depends on resource availability, affinity rules, and the current load. Manual placement does not scale. Kubernetes has a scheduler that watches for new containers and assigns them to nodes that have the resources they need .

The self-healing problem. A container crashes at 3 AM. A node loses power. A process runs out of memory. In a manual setup, someone must notice and restart the workload. Kubernetes notices automatically. It compares the desired state (three replicas) with the actual state (two replicas) and creates a replacement . This is the reconciliation loop: controllers constantly watch the cluster and fix any differences between what you asked for and what exists .

The scaling problem. Traffic spikes during a sale. The application needs more replicas. A human can add them manually, but that takes time. Kubernetes can scale automatically based on CPU usage or custom metrics. The Horizontal Pod Autoscaler adjusts the replica count without human intervention .

The networking problem. Containers are ephemeral. They get new IP addresses when they restart. If one container needs to talk to another, it cannot rely on a fixed IP. Kubernetes provides Services: stable DNS names and virtual IPs that route traffic to the healthy pods behind them, even as those pods are replaced .

The update problem. Deploying a new version of an application requires replacing containers without downtime. Kubernetes performs rolling updates: it gradually replaces old containers with new ones, verifying health at each step, and rolls back automatically if something goes wrong .

The trade-off. Kubernetes adds complexity. A single Docker container is simple. A Kubernetes cluster has a control plane, worker nodes, networking layers, storage abstractions, and a declarative configuration language. The complexity is the cost of the capabilities. For a single application on a single server, Kubernetes is overkill. For a fleet of services across many machines, it is the standard .

a. What Kubernetes Is Not

Understanding Kubernetes requires understanding what it does not do. The Kubernetes documentation is explicit about the boundaries .

It is not a Platform as a Service. Kubernetes operates at the container level, not the hardware level. It provides some PaaS-like features — deployments, scaling, load balancing — but it is not monolithic. The default solutions are optional and interchangeable .

It does not build or deploy your code. Kubernetes does not compile your application or run your CI/CD pipeline. It runs containers. The pipeline that builds the image and pushes it to a registry is a separate system .

It does not provide application services. Databases, message queues, caches, and data processing frameworks are not part of Kubernetes. You can run these workloads on Kubernetes, or connect to external services. But Kubernetes does not ship with them .

It does not dictate logging, monitoring, or alerting. There are integrations and mechanisms for collecting metrics and exporting logs, but Kubernetes does not prescribe a monitoring stack. You choose the tools .

It is not just an orchestrator. The documentation makes a subtle distinction. Orchestration implies a defined workflow: do A, then B, then C. Kubernetes does not work that way. It is a set of independent, composable control processes that drive the current state toward the desired state. The path from A to C does not matter. The system is more flexible and resilient because it is decentralized .

b. The Core Concepts

Kubernetes introduces a vocabulary. The LFCA exam expects you to know the terms, but for this chapter, the concepts matter more than the commands.

Pod. The smallest deployable unit. A Pod is a group of one or more containers that share storage and network resources. A Pod has its own IP address. Containers inside a Pod can communicate over localhost. Most Pods contain one container, but multi-container Pods are used for sidecars, proxies, and init containers .

Node. A worker machine in the cluster. Each node runs a container runtime (like containerd), a kubelet (the agent that talks to the control plane), and a kube-proxy (for network routing). A cluster has one or more nodes .

Cluster. A set of nodes managed by a control plane. The control plane makes decisions about the cluster: scheduling, scaling, and maintaining the desired state .

Service. A stable network endpoint for a set of Pods. A Service provides a DNS name and a virtual IP. Traffic to the Service is load-balanced across the healthy Pods that match its label selector .

Deployment. A declarative resource that manages a set of identical Pods. You specify the desired replica count and the container image. The Deployment controller creates a ReplicaSet, which creates the Pods. If a Pod fails, the ReplicaSet creates a new one .

ConfigMap and Secret. Resources for injecting configuration into Pods without rebuilding the image. ConfigMaps store non-sensitive data (hostnames, ports, feature flags). Secrets store sensitive data (passwords, tokens, certificates) .

Namespace. A logical isolation mechanism within a cluster. Resources in different namespaces can have the same name. Namespaces are used to separate teams, environments, or projects .

Label. A key-value pair attached to any resource. Labels are used by selectors to identify groups of resources. A Service selects Pods by label. A Deployment manages Pods by label .

c. The Architecture at a Glance

Kubernetes is divided into two parts: the control plane and the worker nodes .

The control plane is the brain of the cluster. It makes decisions about scheduling, scaling, and maintaining state. It includes:

API server. The central entry point. Every component talks to the API server. Only the API server writes to etcd .
etcd. A distributed key-value store. It is the source of truth for the cluster’s state .
Scheduler. Watches for new Pods and assigns them to nodes based on resource requirements, affinity rules, and other constraints .
Controller manager. Runs the controllers that reconcile desired state with actual state. The Deployment controller creates ReplicaSets. The ReplicaSet controller creates Pods .

The worker nodes run the actual workloads. Each node includes:

Kubelet. The agent that communicates with the control plane. It pulls container images and starts containers .
Container runtime. The software that runs containers (containerd, CRI-O, or similar) .
Kube-proxy. Manages network rules for Service routing .

The flow is declarative. You write a YAML manifest that describes the desired state. You send it to the API server. The API server stores it in etcd. Controllers watch for changes and create the necessary resources. The scheduler assigns Pods to nodes. The kubelet starts the containers. If anything drifts from the desired state, the controllers fix it .

Complete Example Session

This session demonstrates the declarative model by defining a Deployment, a Service, and observing Kubernetes maintain the desired state.

# ============================================
# PART 1: THE DEPLOYMENT MANIFEST
# ============================================

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:1.25
        ports:
        - containerPort: 80

The Deployment declares three replicas of the nginx container. The selector matches Pods with the label app: web-app. The template defines the Pod specification .

# ============================================
# PART 2: THE SERVICE MANIFEST
# ============================================

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

The Service selects Pods with the label app: web-app and exposes port 80. The Service provides a stable DNS name and virtual IP. Traffic to the Service is load-balanced across the healthy Pods .

# ============================================
# PART 3: THE CONFIGMAP
# ============================================

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"

The ConfigMap stores non-sensitive configuration. It can be mounted as environment variables or files in the Pod .

# ============================================
# PART 4: THE SECRET
# ============================================

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  password: cGFzc3dvcmQ=  # base64-encoded

The Secret stores sensitive data. The value is base64-encoded, not encrypted. Encryption is handled by the cluster configuration .

# ============================================
# PART 5: THE UPDATED DEPLOYMENT WITH CONFIG
# ============================================

# deployment-with-config.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:1.25
        ports:
        - containerPort: 80
        envFrom:
        - configMapRef:
            name: app-config
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password

The envFrom injects all keys from the ConfigMap as environment variables. The env block injects the Secret value into a specific variable .

# ============================================
# PART 6: APPLY THE MANIFESTS
# ============================================

# Apply all manifests in the current directory
kubectl apply -f .

# Output:
# deployment.apps/web-app created
# service/web-app-service created
# configmap/app-config created
# secret/db-credentials created

The kubectl apply command sends the desired state to the API server. Kubernetes creates the resources. The scheduler assigns the Pods to nodes. The kubelet starts the containers .

# ============================================
# PART 7: OBSERVE THE STATE
# ============================================

# List Pods
kubectl get pods

# Output:
# NAME                       READY   STATUS    RESTARTS   AGE
# web-app-7d9f8b6c5-2x4kz    1/1     Running   0          10s
# web-app-7d9f8b6c5-8m3np    1/1     Running   0          10s
# web-app-7d9f8b6c5-q7r5t    1/1     Running   0          10s

# List Services
kubectl get services

# Output:
# NAME              TYPE        CLUSTER-IP      PORT(S)
# web-app-service   ClusterIP   10.96.123.45    80/TCP

Three Pods are running. The Service has a cluster IP and exposes port 80 .

# ============================================
# PART 8: TEST SELF-HEALING
# ============================================

# Delete one Pod
kubectl delete pod web-app-7d9f8b6c5-2x4kz

# Observe the new Pod being created
kubectl get pods

# Output:
# NAME                       READY   STATUS    RESTARTS   AGE
# web-app-7d9f8b6c5-8m3np    1/1     Running   0          2m
# web-app-7d9f8b6c5-q7r5t    1/1     Running   0          2m
# web-app-7d9f8b6c5-x9w2v    1/1     Running   0          5s

Kubernetes noticed that the actual state (two Pods) did not match the desired state (three Pods) and created a replacement. This is the reconciliation loop in action .

# ============================================
# PART 9: SCALE THE DEPLOYMENT
# ============================================

# Change the replica count
kubectl scale deployment web-app --replicas=5

# Observe
kubectl get pods

# Output shows five Pods running.

The kubectl scale command updates the desired state. The Deployment controller creates two additional Pods. Kubernetes reconciles the difference .

# ============================================
# PART 10: ROLLING UPDATE
# ============================================

# Update the image
kubectl set image deployment/web-app web=nginx:1.26

# Watch the rollout
kubectl rollout status deployment/web-app

# Output:
# Waiting for deployment "web-app" rollout to finish:
# 2 out of 5 new replicas have been updated...
# ...
# deployment "web-app" successfully rolled out

Kubernetes replaces the Pods gradually. It creates new Pods with the updated image and terminates old ones only after the new ones are healthy. If the new version fails, Kubernetes can roll back .

Quick Reference

The Core Concepts

Concept	Definition
Pod	Smallest deployable unit; one or more containers
Node	Worker machine in the cluster
Cluster	Set of nodes managed by the control plane
Service	Stable network endpoint for a set of Pods
Deployment	Declarative resource managing a set of Pods
ConfigMap	Non-sensitive configuration data
Secret	Sensitive configuration data
Namespace	Logical isolation within a cluster
Label	Key-value pair for identifying resources

The Control Plane Components

Component	Purpose
API server	Central entry point; only writer to etcd
etcd	Distributed key-value store; cluster state
Scheduler	Assigns Pods to nodes
Controller manager	Reconciles desired state with actual state

The Node Components

Component	Purpose
Kubelet	Agent; starts containers, reports status
Container runtime	Runs containers (containerd, CRI-O)
Kube-proxy	Network rules for Service routing

The Key Features

Feature	Description
Self-healing	Replaces failed containers and Pods
Horizontal scaling	Adjusts replica count based on load
Service discovery	Stable DNS names for Pods
Load balancing	Distributes traffic across Pods
Rolling updates	Replaces Pods without downtime
Automated rollback	Reverts to previous version on failure
Secret management	Injects sensitive data securely

The Relationship to Docker

Docker	Kubernetes
Builds images	Orchestrates containers
Runs a single container	Manages a fleet of containers
Single machine	Cluster of machines
Manual scaling	Automatic scaling
No self-healing	Self-healing

Best Practices

✅ Do This:

# Declare the desired state in YAML
replicas: 3                                                  # ✅

# Use kubectl apply for declarative management
kubectl apply -f deployment.yaml                             # ✅

# Use labels to organize resources
labels:
  app: web-app                                               # ✅

# Use ConfigMaps for non-sensitive configuration
envFrom:
- configMapRef:
    name: app-config                                         # ✅

# Use Secrets for sensitive data
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:                                            # ✅

❌ Don’t Do This:

# Don't hardcode secrets in manifests
password: "mypassword"  # in plain text                      # ❌

# Don't use the latest tag in production
image: nginx:latest                                          # ❌ unpredictable

# Don't create Pods without a Deployment for production workloads
kubectl run my-pod --image=nginx                             # ❌ no self-healing

# Don't skip resource requests and limits
# Containers without requests may be over-scheduled.       # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Pods stuck in Pending	Insufficient resources or no matching node	Check resource requests and node labels
CrashLoopBackOff	Application error or missing config	Check `kubectl logs` and `kubectl describe`
Service not routing	Label selector mismatch	Verify Pod labels match Service selector
Secret not found	Missing Secret or wrong namespace	Create the Secret or check namespace
Rollout stuck	Image pull failure or readiness probe failing	Check `kubectl describe pod`

Real-World Examples

1. What Kubernetes Is

# An open-source platform for automating deployment, scaling,
# and management of containerized applications

2. Declarative Model

kubectl apply -f deployment.yaml
# "I want three replicas" → Kubernetes creates three Pods

3. Self-Healing

kubectl delete pod my-pod
# Kubernetes creates a replacement automatically

4. Scaling

kubectl scale deployment web-app --replicas=5

5. Rolling Update

kubectl set image deployment/web-app web=nginx:1.26

6. Service Discovery

# Pods communicate via Service DNS names, not IPs

7. ConfigMap

kubectl create configmap app-config --from-literal=ENV=prod

8. Secret

kubectl create secret generic db-creds --from-literal=password=secret

9. Namespace

kubectl create namespace dev

10. Cluster Info

kubectl cluster-info

Visual

The Declarative Model

┌──────────────────────────────────────────────┐
│  DESIRED STATE                               │
│    replicas: 3                               │
│       │                                      │
│       ▼                                      │
│  API SERVER                                  │
│    └─ Stores in etcd                         │
│       │                                      │
│       ▼                                      │
│  CONTROLLERS                                 │
│    └─ Compare desired vs actual              │
│       │                                      │
│       ├─ Match → do nothing                  │
│       └─ Mismatch → create/delete Pods       │
│                                              │
│  Kubernetes continuously reconciles.         │
│  You declare. It maintains.                  │
│                                              │
└──────────────────────────────────────────────┘

The Control Plane and Nodes

┌──────────────────────────────────────────────┐
│  CONTROL PLANE                               │
│    API server  ──> etcd                      │
│    Scheduler   ──> assigns Pods              │
│    Controller  ──> reconciles state          │
│                                              │
│  WORKER NODES                                │
│    ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│    │ Node 1  │ │ Node 2  │ │ Node 3  │       │
│    │ kubelet │ │ kubelet │ │ kubelet │       │
│    │ runtime │ │ runtime │ │ runtime │       │
│    │ Pods    │ │ Pods    │ │ Pods    │       │
│    └─────────┘ └─────────┘ └─────────┘       │
│                                              │
│  The control plane decides.                  │
│  The nodes run the workloads.                │
│                                              │
└──────────────────────────────────────────────┘

The Pod Lifecycle

┌──────────────────────────────────────────────┐
│  POD LIFECYCLE                               │
│                                              │
│  Pending ──> ContainerCreating ──> Running   │
│                                          │   │
│                                          ▼   │
│  Failed <── Error <── Succeeded <── Running  │
│                                              │
│  If a Pod fails, the ReplicaSet creates      │
│  a new one to maintain the desired count.    │
│                                              │
└──────────────────────────────────────────────┘

The Service and Pods

┌──────────────────────────────────────────────┐
│  SERVICE                                     │
│    Stable DNS name                           │
│    Virtual IP                                │
│       │                                      │
│       ├──> Pod 1 (healthy)                   │
│       ├──> Pod 2 (healthy)                   │
│       └──> Pod 3 (replaced automatically)    │
│                                              │
│  The Service routes traffic to healthy Pods. │
│  Pod IPs change. The Service IP does not.    │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
Kubernetes definition	Open-source platform for container orchestration
Released	2014 by Google
Based on	Borg, Google’s internal orchestration system
Model	Declarative; desired state
Core unit	Pod
Control plane	API server, etcd, scheduler, controller manager
Node components	Kubelet, container runtime, kube-proxy
Key features	Self-healing, scaling, service discovery, rolling updates
Configuration	YAML manifests
CLI	`kubectl`
LFCA weight	DevOps Fundamentals, 16%

Key takeaways:

Kubernetes is a platform for automating the deployment, scaling, and management of containerized applications. It was released by Google in 2014 and is based on over fifteen years of production experience .
The core model is declarative. You describe the desired state in YAML. Kubernetes continuously reconciles the actual state with the desired state. If a container crashes, Kubernetes replaces it. If you need more replicas, you change a number and Kubernetes creates them .
The Pod is the smallest deployable unit. A Pod is a group of one or more containers that share network and storage. Pods are ephemeral. They are created, run, and replaced .
The Service provides a stable network endpoint. Pods get new IP addresses when they restart. A Service gives a stable DNS name and virtual IP that routes traffic to the healthy Pods behind it .
The control plane is the brain of the cluster. The API server is the entry point. etcd stores the state. The scheduler assigns Pods to nodes. The controller manager reconciles desired state with actual state .
Kubernetes is not a PaaS, not a CI/CD system, and not a monitoring stack. It runs containers. It does not build code, provide databases, or dictate logging tools. It provides the primitives, and you choose the rest .
The LFCA exam tests the fundamentals. Containers, deployment environments, and the relationship between Docker and Kubernetes are covered under DevOps Fundamentals, which carries 16% of the total weight .

Remember: Kubernetes exists because running containers at scale is harder than running them on a single machine. It solves the scheduling, self-healing, scaling, networking, and update problems that appear when you have a fleet of servers and dozens of services. The declarative model is the key: you describe what you want, and Kubernetes makes it happen. The Pod is the unit. The Service is the address. The Deployment is the manager. The control plane is the brain. The nodes are the hands. And the reconciliation loop never stops.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!