Kubernetes Fundamentals

From Docker Containers to Kubernetes Orchestration

0%
Lesson 1 of 5

The Need for Orchestration: From Docker to Kubernetes

Why Kubernetes?

While Docker introduced a revolutionary philosophy for packaging applications, it addresses only part of the challenge. Docker allows you to containerize your application, but what happens when you need to:

  • Run hundreds or thousands of containers across multiple machines
  • Ensure containers automatically restart when they fail
  • Scale applications up or down based on demand
  • Distribute traffic evenly across containers
  • Deploy updates without downtime

This is where Kubernetes comes in as the essential next step after adopting Docker.

Docker's Limitation

Docker is like a single "semi-truck" carrying one container. It packages your application, but doesn't manage it at scale.

Kubernetes' Role

K8s acts as the container orchestrator—a "tugboat" or "tractor" that coordinates, scales, and centrally manages multiple containers across a cluster of machines (nodes).

Production Environment Needs

In production, you need a system to:

  • Manage containers across multiple servers
  • Scale applications automatically
  • Ensure availability even when containers or servers fail
  • Centralize operations for easier administration

What Kubernetes Provides

Kubernetes is a container orchestration platform that enables:

  • Flexible deployment: Deploy containers across a cluster of machines
  • Centralized management: Control all containers from a single point
  • High availability: Automatically replace failed containers
  • Load distribution: Balance workloads across available resources
  • Rolling updates: Update applications without downtime

Key Takeaway

Kubernetes transforms Docker containers from individual units into a managed, scalable, and resilient production system.

Lesson 2 of 5

Core Kubernetes Philosophy and Management

Operational Philosophy

The key advantage of Kubernetes is rooted in its operational philosophy, which enables stable and repeatable deployments. Understanding these principles is crucial to working effectively with K8s.

1. Immutable Infrastructure

Kubernetes resources are designed to be immutable. This means:

  • You don't connect to running servers to modify or update software
  • Instead, you create a new, updated version of your application
  • Then you replace the old version entirely with the new one

Traditional vs. Immutable Approach

Traditional: SSH into server → Edit configuration → Restart service

Kubernetes: Create new container image → Deploy new version → Replace old containers

Benefits of Immutability

  • Consistency: Every deployment is identical
  • Reliability: No configuration drift over time
  • Rollback: Easy to revert to previous versions
  • Traceability: Clear history of what was deployed when

2. Declarative Management

With Kubernetes, you define the desired state of your application, not the steps to achieve it.

# Example: Declarative YAML manifest apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 # Desired state: I want 3 replicas running selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-app:1.0.0 ports: - containerPort: 8080

How It Works

  • You declare: "I want 3 replicas of this container running"
  • Kubernetes constantly monitors the cluster's current state
  • It works to reconcile the current state with your desired state
  • If a container fails, K8s automatically creates a new one to maintain 3 replicas

Declarative vs. Imperative

Imperative: "Create a container, then create another, then start them"

Declarative: "Here's what I want running. Make it happen."

Kubernetes uses the declarative approach, which is more resilient and easier to manage.

3. kubectl: The Command-Line Tool

The primary tool for interacting with Kubernetes clusters and applying manifests is kubectl (pronounced "kube-control" or "kube-cuttle").

# Apply a manifest file (create/update resources) kubectl apply -f deployment.yaml # View running pods kubectl get pods # View deployments kubectl get deployments # Describe a specific resource kubectl describe pod my-app-12345 # View logs from a pod kubectl logs my-app-12345 # Delete resources defined in a file kubectl delete -f deployment.yaml

Key Principles Summary

  • Immutable: Replace, don't modify
  • Declarative: Define desired state in YAML
  • Self-healing: Kubernetes reconciles actual state with desired state
  • kubectl: Your primary interface to the cluster
Lesson 3 of 5

The Pod: The Smallest Deployable Unit

What is a Pod?

The Pod is the most basic and smallest unit that can be created and deployed in Kubernetes.

Definition

A Pod is an abstraction that groups one or more containers together. All containers in a Pod are guaranteed to run on the same node and share critical resources.

Pod Characteristics

1. Container Grouping

While most Pods contain a single container, a Pod can hold multiple containers that work together:

  • Main application container
  • Helper containers (sidecars) for logging, monitoring, or proxying
  • Init containers that run before the main container starts

2. Shared Resources

Containers within a Pod share:

  • Network stack: All containers share the same IP address
  • localhost communication: Containers can talk to each other using localhost
  • Volumes: Shared storage accessible to all containers in the Pod
  • Lifecycle: All containers start and stop together
# Example: Simple Pod manifest apiVersion: v1 kind: Pod metadata: name: my-app-pod labels: app: my-app spec: containers: - name: web-container image: nginx:1.21 ports: - containerPort: 80 - name: sidecar-container image: logging-agent:1.0 # This container can access nginx on localhost:80

The Critical Concept: Pods are Ephemeral

This is the most important thing to understand about Pods:

Pods Are NOT Self-Healing

Crucial Point: Pods are inherently ephemeral (short-lived). If a Pod crashes or dies, Kubernetes does NOT automatically restart or replace it—it is simply terminated.

This is a fundamental design decision. Pods themselves have no self-healing capability.

What This Means in Practice

  • You should never create standalone Pods in production
  • Always use higher-level controllers (like ReplicaSets or Deployments) to manage Pods
  • Pods are meant to be disposable and replaceable
  • Don't rely on a specific Pod always being available
# Don't do this in production (Pod will not restart if it fails): kubectl run my-app --image=my-app:1.0 # Do this instead (use a Deployment which manages Pods): kubectl create deployment my-app --image=my-app:1.0

Pod Lifecycle

A Pod goes through several phases:

  1. Pending: Pod has been accepted but containers aren't running yet
  2. Running: Pod has been bound to a node and all containers are running
  3. Succeeded: All containers completed successfully and won't restart
  4. Failed: All containers terminated, and at least one failed
  5. Unknown: State cannot be determined

Key Takeaways

  • Pods are the smallest deployable units in Kubernetes
  • Pods group one or more containers with shared resources
  • Pods are ephemeral and not self-healing
  • This limitation necessitates higher-level controllers
Lesson 4 of 5

ReplicaSet: Ensuring Stability and Scale

Why ReplicaSets Exist

Since Pods are ephemeral and don't self-heal, Kubernetes provides the ReplicaSet controller to solve this problem.

ReplicaSet Purpose

A ReplicaSet's single responsibility is to maintain a stable set of Pods running at the desired scale.

How ReplicaSets Work

1. Desired State Maintenance

The ReplicaSet is configured to ensure a specific number of Pod replicas are always running:

  • You specify: "I want 3 replicas of this Pod"
  • ReplicaSet monitors the actual number running
  • If a Pod is deleted or fails, ReplicaSet immediately spawns a new one
  • If too many Pods exist, ReplicaSet terminates the excess
# Example: ReplicaSet manifest apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-app-replicaset spec: replicas: 3 # Always maintain 3 Pods selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-app:1.0.0 ports: - containerPort: 8080

2. Pod Identification with Labels

ReplicaSets use labels and selectors to track and manage their associated Pods:

  • Labels: Key-value pairs attached to Pods (e.g., app: my-app)
  • Selectors: Queries that match labels to find Pods
  • ReplicaSet monitors all Pods with matching labels
# View Pods with their labels kubectl get pods --show-labels # View Pods with a specific label kubectl get pods -l app=my-app # ReplicaSet manages all Pods matching its selector kubectl get replicaset my-app-replicaset

Self-Healing in Action

The ReplicaSet provides automatic self-healing:

# Scenario: You have 3 Pods running kubectl get pods # my-app-abc Running # my-app-def Running # my-app-ghi Running # Delete one Pod manually kubectl delete pod my-app-abc # ReplicaSet immediately creates a new Pod kubectl get pods # my-app-def Running # my-app-ghi Running # my-app-jkl Running ← New Pod created automatically!

The Critical Limitation of ReplicaSets

ReplicaSets Cannot Manage Updates

A ReplicaSet's only job is maintaining the count of the current Pod definition. It cannot manage updates or deploy new versions of your application.

What Happens During an Update

If you change the container image in the Pod template:

  • The ReplicaSet will continue maintaining 3 Pods with the old image
  • It won't automatically roll out the new version
  • You would need to manually delete the old Pods for new ones to be created
  • This creates downtime and is error-prone
# If you update the image in the ReplicaSet: kubectl edit replicaset my-app-replicaset # Change image: my-app:1.0.0 → my-app:2.0.0 # The existing 3 Pods still run version 1.0.0! # ReplicaSet won't update them automatically # You'd have to manually delete Pods to force recreation: kubectl delete pod my-app-abc my-app-def my-app-ghi # This causes downtime - not ideal!

When to Use ReplicaSets

In practice, you rarely create ReplicaSets directly. They are typically managed by higher-level controllers (Deployments). However, understanding ReplicaSets is crucial because:

  • Deployments create and manage ReplicaSets automatically
  • ReplicaSets are the mechanism that ensures Pod stability
  • Troubleshooting often requires understanding ReplicaSet behavior

Key Takeaways

  • ReplicaSets maintain a stable number of Pod replicas
  • They use labels and selectors to track Pods
  • ReplicaSets provide self-healing by replacing failed Pods
  • They cannot manage application updates
  • This limitation leads us to Deployments
Lesson 5 of 5

Next Steps: Deployments for Updates

The Update Problem

We've seen that ReplicaSets maintain Pod stability but cannot manage updates. This creates a critical challenge:

Production Update Challenge

How do you safely and consistently roll out an application update across multiple servers without downtime?

Common Update Scenarios

  • Deploying a new version of your application
  • Updating container images with security patches
  • Changing environment variables or configuration
  • Rolling back to a previous version after issues

Introduction to Deployments

The Deployment resource solves the update problem. It sits above the ReplicaSet and manages the process of rolling out changes.

How Deployments Work

A Deployment manages one or more ReplicaSets and provides declarative updates to Pods:

  • Creates new Pods with the updated version
  • Gradually terminates old Pods
  • Ensures availability during the transition
  • Allows rollback if something goes wrong

Rolling Update Strategy

The default update strategy is a Rolling Update:

  1. Deployment creates a new ReplicaSet with the updated Pod template
  2. New ReplicaSet scales up (creating new Pods)
  3. Old ReplicaSet scales down (terminating old Pods)
  4. Process continues until all Pods are updated
  5. Zero downtime is maintained throughout
# Example: Deployment manifest apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-app:2.0.0 # Update this to roll out new version ports: - containerPort: 8080 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # Max 1 extra Pod during update maxUnavailable: 0 # Always keep all Pods available

Deployment Operations

# Create a Deployment kubectl create deployment my-app --image=my-app:1.0.0 # Update the image (triggers rolling update) kubectl set image deployment/my-app my-app=my-app:2.0.0 # View rollout status kubectl rollout status deployment/my-app # View rollout history kubectl rollout history deployment/my-app # Rollback to previous version kubectl rollout undo deployment/my-app # Rollback to specific revision kubectl rollout undo deployment/my-app --to-revision=2

The Kubernetes Hierarchy

Understanding the relationship between these resources:

Deployment (manages updates and rollbacks) └── ReplicaSet (maintains desired number of Pods) └── Pod (runs the actual containers) └── Container (your application)

Best Practices

  • Always use Deployments in production, not bare Pods or ReplicaSets
  • Version your images (use my-app:1.0.0, not my-app:latest)
  • Test rollouts in staging environments first
  • Monitor rollouts and be ready to rollback if needed
  • Use health checks (readiness and liveness probes)

What We've Learned

This crash course covered the fundamental building blocks of Kubernetes:

  1. Orchestration Need: Docker containers require management at scale
  2. K8s Philosophy: Immutable infrastructure and declarative management
  3. Pods: Smallest deployable unit, but ephemeral (not self-healing)
  4. ReplicaSets: Maintain stable Pod count, but can't manage updates
  5. Deployments: Manage rolling updates and rollbacks

Continue Learning

Next topics to explore:

  • Services: Networking and load balancing for Pods
  • ConfigMaps and Secrets: Configuration management
  • Volumes: Persistent storage
  • Namespaces: Resource isolation
  • Helm: Package manager for Kubernetes
Final Assessment

Test Your Knowledge

Kubernetes Fundamentals Quiz

Question 1: Why is Kubernetes needed after Docker?

Question 2: What does "immutable infrastructure" mean in Kubernetes?

Question 3: What is the most critical characteristic of Pods?

Question 4: What is the single responsibility of a ReplicaSet?

Question 5: Why can't ReplicaSets manage application updates?

Question 6: What problem does a Deployment solve?