Kubernetes Architecture & Components

Lesson 1 of 5

Kubernetes Cluster Architecture

What is a Kubernetes Cluster?

A Kubernetes cluster is a set of machines (physical or virtual) that work together to run containerized applications. The cluster provides a unified platform for deploying, scaling, and managing applications.

Cluster Components

A Kubernetes cluster consists of two main types of components:

Control Plane (Master) Components: Manage the overall state of the cluster
Node (Worker) Components: Run the actual application workloads

High-Level Architecture

Kubernetes Cluster Architecture

Control Plane (Master Node)

API Server - Central entry point
etcd - Distributed key-value store
Scheduler - Pod placement decisions
Controller Manager - Maintains desired state

⬇
Commands & State Management
⬇

Worker Nodes (Multiple)

Kubelet - Node agent
Container Runtime - Runs containers (Docker, containerd)
Kube-proxy - Network proxy
Pods - Running applications

Critical Understanding

Cluster Dependencies

Important: A cluster cannot function without its core components. If critical components like the API Server or etcd fail, the cluster loses its ability to manage workloads.

Control Plane vs. Worker Nodes

Aspect	Control Plane	Worker Nodes
Purpose	Manage and control the cluster	Run application workloads
Responsibilities	Scheduling, scaling, monitoring, updates	Execute containers and maintain Pods
Key Components	API Server, etcd, Scheduler, Controllers	Kubelet, Container Runtime, Kube-proxy
Typical Count	1-3 (HA setup)	Many (scales with workload)
Runs User Apps	No (usually)	Yes

Communication Flow

1. User/Developer
Creates resource (e.g., kubectl create deployment)

↓

2. API Server
Receives request, validates, authenticates

↓

3. etcd
Stores desired state

↓

4. Controller Manager
Detects new Deployment, creates ReplicaSet

↓

5. Scheduler
Selects appropriate node for Pod

↓

6. Kubelet (on selected node)
Receives instruction, starts containers

↓

7. Container Runtime
Actually runs the container

Cluster Characteristics

High Availability

Production clusters typically run multiple Control Plane nodes for redundancy:

3+ Control Plane nodes (odd number for quorum)
etcd distributed across multiple nodes
Load balancer in front of API Servers
Multiple worker nodes for application redundancy

Scalability

Kubernetes clusters can scale to support:

Up to 5,000 nodes
Up to 150,000 Pods
Up to 300,000 containers

Key Takeaways

Cluster = Control Plane + Worker Nodes
Control Plane manages, Workers execute
All components are essential for cluster operation
Communication flows through the API Server
etcd stores all cluster state

Lesson 2 of 5

Control Plane Components

The Control Plane

The Control Plane (also called Master components) is the brain of the Kubernetes cluster. It makes global decisions about the cluster and detects and responds to cluster events.

Control Plane Responsibilities

Accept and validate user requests
Store cluster state
Schedule Pods to nodes
Monitor cluster health
Maintain desired state

1. API Server (kube-apiserver)

The API Server is the central entry point and the heart of Kubernetes. It exposes the Kubernetes API and serves as the frontend for the Control Plane.

API Server Role

The API Server is the only component that directly communicates with etcd. All other components interact with the cluster state through the API Server.

Key Functions

Central communication hub: All internal component communication goes through it
External interface: All user requests (kubectl commands) are sent to it
Authentication & Authorization: Validates who can access the cluster and what they can do
Admission Control: Validates and potentially modifies requests
REST API: Provides HTTP REST interface for cluster operations

# All kubectl commands go to the API Server
kubectl create deployment nginx --image=nginx
  ↓
API Server receives request
  ↓
Authenticates user
  ↓
Authorizes action
  ↓
Validates resource
  ↓
Writes to etcd
  ↓
Returns response

API Server Communication

# Check API Server address
kubectl cluster-info

# Direct API call (instead of kubectl)
curl https://kubernetes-api-server:6443/api/v1/namespaces/default/pods \
  --header "Authorization: Bearer $TOKEN" \
  --cacert /path/to/ca.crt

# API Server listens on port 6443 (default)

2. etcd

etcd is a highly available, distributed key-value store that serves as Kubernetes' backing store for all cluster data.

Single Source of Truth

etcd is the single source of truth for the entire cluster. Everything Kubernetes knows is stored in etcd.

What etcd Stores

Cluster configuration: Settings and parameters
Desired state: All resource manifests (Deployments, Services, etc.)
Current state: Which Pods are running, on which nodes
Secrets and ConfigMaps: Configuration data
Network policies, RBAC rules: Security configurations
Node information: Available nodes and their status

# Example: When you create a Pod, this data is stored in etcd:
{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "nginx",
    "namespace": "default"
  },
  "spec": {
    "containers": [{
      "name": "nginx",
      "image": "nginx:1.21"
    }]
  },
  "status": {
    "phase": "Running",
    "podIP": "10.244.1.5"
  }
}

etcd Characteristics

Distributed: Runs on multiple nodes for redundancy
Consistent: Uses Raft consensus algorithm
Fast: Optimized for read and write operations
Secure: Supports TLS and authentication

Critical Component

If etcd fails, the cluster loses its memory. Always back up etcd in production!

Without etcd, the API Server can't function
Without etcd, you lose all cluster configuration
Regular backups are essential

3. Scheduler (kube-scheduler)

The Scheduler is responsible for selecting a suitable node for newly created Pods that don't yet have a node assignment.

Scheduling Process

1. Watch for unscheduled Pods
Scheduler monitors API Server for Pods with no node assigned

↓

2. Filtering
Eliminate nodes that don't meet requirements (resources, taints, affinity)

↓

3. Scoring
Rank remaining nodes based on factors (available resources, spread, etc.)

↓

4. Binding
Assign Pod to highest-scoring node

↓

5. Update API Server
Write the scheduling decision to etcd

Scheduling Factors

Resource requests: Does node have enough CPU/memory?
Node selectors: Does Pod require specific node labels?
Affinity/Anti-affinity: Should Pod be near or away from others?
Taints and tolerations: Can Pod tolerate node taints?
Resource balance: Spread load evenly across nodes

# Example: Pod with resource requests
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"

# Scheduler will only consider nodes with at least:
# - 256Mi free memory
# - 500m (0.5 CPU) available

4. Controller Manager (kube-controller-manager)

The Controller Manager runs multiple controllers that continuously monitor the cluster state and work to maintain the desired state.

What Controllers Do

Controller Loop (Reconciliation)

Watch the API Server for changes
Compare current state vs. desired state
Take action to reconcile the difference
Repeat continuously

Key Controllers

Node Controller: Monitors node health, marks unhealthy nodes
Replication Controller: Ensures correct number of Pod replicas
Endpoints Controller: Populates Endpoints objects (connects Services to Pods)
Service Account Controller: Creates default service accounts for namespaces
Deployment Controller: Manages Deployments and ReplicaSets
Job Controller: Manages one-off tasks

# Example: Replication Controller in action

Desired State (in etcd):
  Deployment "webapp" should have 3 replicas

Current State:
  Only 2 Pods are running

Controller Action:
  1. Detects discrepancy (2 vs 3)
  2. Creates 1 new Pod
  3. Waits for Pod to start
  4. Monitors until desired state is achieved

Controllers Work Together

# When you create a Deployment:

1. Deployment Controller:
   - Detects new Deployment
   - Creates ReplicaSet

2. ReplicaSet Controller:
   - Detects new ReplicaSet
   - Creates Pods

3. Scheduler:
   - Assigns Pods to nodes

4. Kubelet (on nodes):
   - Starts containers

All working together to achieve the desired state!

Control Plane Summary

API Server: Central hub for all communication
etcd: Single source of truth, stores all state
Scheduler: Decides where Pods should run
Controller Manager: Maintains desired state through controllers

All these components work together to manage the cluster!

Lesson 3 of 5

Node (Worker) Components

Worker Nodes

Worker nodes are the machines where your actual application containers run. Each node contains the services necessary to run Pods and is managed by the Control Plane.

Node Responsibilities

Run application containers
Monitor Pod health
Report status to Control Plane
Provide networking for Pods
Manage local resources

1. Kubelet

The Kubelet is the essential node agent that must run on every worker server in the cluster.

Critical Component

The Kubelet is the most important component on a node. Without it, the node cannot participate in the cluster.

Kubelet Responsibilities

Pod lifecycle management: Starts, stops, and monitors containers
Listens to API Server: Watches for Pod assignments to its node
Container runtime interface: Talks to Docker/containerd to run containers
Health checking: Runs liveness and readiness probes
Resource monitoring: Reports node and Pod resource usage
Volume management: Mounts volumes into containers

How Kubelet Works

1. Watch API Server
Kubelet continuously watches for Pods assigned to its node

↓

2. Receive Pod Spec
Gets Pod definition from API Server

↓

3. Talk to Container Runtime
Instructs runtime (Docker/containerd) to pull images

↓

4. Start Containers
Container runtime creates and starts containers

↓

5. Monitor Health
Continuously runs health probes

↓

6. Report Status
Updates Pod status in API Server

# Kubelet workflow example

API Server assigns Pod to Node-1
  ↓
Kubelet on Node-1 receives notification
  ↓
Kubelet checks Pod spec:
  - Image: nginx:1.21
  - Resources: 256Mi memory, 500m CPU
  - Probes: liveness and readiness
  ↓
Kubelet tells container runtime:
  "Pull nginx:1.21 and start container"
  ↓
Container runtime:
  - Pulls image
  - Creates container
  - Starts process
  ↓
Kubelet monitors container:
  - Runs health probes
  - Checks resource usage
  - Reports back to API Server

Kubelet Configuration

# View Kubelet status
systemctl status kubelet

# Kubelet configuration file (typical location)
/var/lib/kubelet/config.yaml

# Kubelet logs
journalctl -u kubelet -f

Kubelet Independence

The Kubelet can run Pods even if the Control Plane is unavailable (for Pods already scheduled). However, no new Pods can be scheduled without the Control Plane.

2. Container Runtime

The Container Runtime is the software responsible for actually running containers on the node.

Supported Runtimes

containerd: Industry standard, lightweight (recommended)
CRI-O: Lightweight alternative designed for Kubernetes
Docker: Popular but deprecated in favor of containerd

Container Runtime Interface (CRI)

Kubernetes uses the CRI to communicate with different container runtimes in a standardized way. This allows Kubernetes to work with any CRI-compatible runtime.

# Container runtime responsibilities:

1. Image Management:
   - Pull images from registries
   - Store images locally
   - Manage image cache

2. Container Execution:
   - Create containers from images
   - Start/stop containers
   - Manage container lifecycle

3. Resource Isolation:
   - Set up cgroups for resource limits
   - Configure namespaces for isolation
   - Enforce security policies

3. Kube-proxy

The kube-proxy is a network proxy that runs on each node and maintains network rules for Pod communication.

Kube-proxy Functions

Service abstraction: Implements Kubernetes Services
Load balancing: Distributes traffic across Pod replicas
Network rules: Configures iptables or IPVS rules
Service discovery: Routes traffic to correct Pods

# Example: How kube-proxy routes traffic

Service "webapp":
  - ClusterIP: 10.96.100.50
  - Pods: 10.244.1.5, 10.244.2.8, 10.244.3.12

When a request comes to 10.96.100.50:80:
  ↓
kube-proxy intercepts request
  ↓
Selects one of the backend Pods (load balancing)
  ↓
Rewrites packet destination to Pod IP
  ↓
Forwards to selected Pod

Kube-proxy Modes

iptables (default): Uses iptables rules for routing
IPVS: More efficient for large clusters
userspace: Legacy mode, not recommended

Additional Node Components

CNI (Container Network Interface) Plugin

Provides Pod networking capabilities:

Assigns IP addresses to Pods
Sets up network routes
Enables Pod-to-Pod communication
Examples: Calico, Flannel, Weave

CSI (Container Storage Interface) Plugin

Provides persistent storage:

Mounts volumes to Pods
Manages storage lifecycle
Examples: AWS EBS, GCE PD, NFS

Node Architecture Visualization

Worker Node Components

Kubelet

Manages Pod lifecycle, reports to API Server

Container Runtime (containerd/Docker)

Pulls images and runs containers

Kube-proxy

Manages network rules for Services

Pods (Your Applications)

Running containers with your code

Node Components Summary

Kubelet: Essential node agent, manages Pods
Container Runtime: Actually runs containers
Kube-proxy: Handles networking and Services
All three must be running for a node to function

Lesson 4 of 5

How Components Work Together

Complete Workflow: Creating a Deployment

Let's see how all components collaborate when you create a Deployment:

Step 1: User Action
Developer runs: kubectl create deployment nginx --image=nginx --replicas=3

↓

Step 2: API Server
• Authenticates and authorizes request
• Validates Deployment spec
• Writes Deployment object to etcd

↓

Step 3: Deployment Controller (in Controller Manager)
• Watches API Server, detects new Deployment
• Creates ReplicaSet for the Deployment
• Writes ReplicaSet to API Server → etcd

↓

Step 4: ReplicaSet Controller
• Detects new ReplicaSet
• Sees desired count: 3 replicas
• Creates 3 Pod objects
• Writes Pods to API Server → etcd

↓

Step 5: Scheduler
• Detects 3 unscheduled Pods
• Evaluates all nodes
• Assigns each Pod to a suitable node
• Updates Pod specs with node assignment

↓

Step 6: Kubelet (on each assigned node)
• Detects Pod assigned to its node
• Tells container runtime to pull nginx image
• Instructs runtime to start container
• Reports Pod status to API Server

↓

Step 7: Container Runtime
• Pulls nginx image from registry
• Creates container from image
• Starts container process
• Container now running!

↓

Step 8: Ongoing Monitoring
• Kubelet runs health probes
• Controllers monitor for drift
• System maintains desired state

Component Interactions

# All communication flows through the API Server:

kubectl → API Server
Controllers → API Server
Scheduler → API Server
Kubelet → API Server

API Server ↔ etcd (only component that talks to etcd)

# No component talks directly to each other!

Maintaining Desired State

Controllers continuously work to maintain the desired state:

# Scenario: A Pod crashes

Current State: 2 Pods running (1 crashed)
Desired State: 3 Pods running

ReplicaSet Controller:
  1. Detects discrepancy (2 vs 3)
  2. Creates replacement Pod
  3. Writes to API Server

Scheduler:
  1. Detects new unscheduled Pod
  2. Assigns to node
  3. Updates API Server

Kubelet:
  1. Detects new Pod assignment
  2. Starts container
  3. Reports status

Result: Back to 3 Pods (desired state achieved)

Watch Mechanism

Components use a "watch" mechanism to stay informed:

How Watch Works

Component opens a watch connection to API Server
API Server sends immediate notification when relevant resources change
Component reacts to changes in real-time
No polling needed - very efficient

# Example: Controller watching for Deployments

Controller → API Server: "Watch all Deployments"
API Server: "OK, watching..."

[Time passes...]

User creates new Deployment
  ↓
API Server writes to etcd
  ↓
API Server immediately notifies Controller: "New Deployment created!"
  ↓
Controller reacts instantly (creates ReplicaSet)

Failure Scenarios

Scenario 1: API Server Fails

Impact: Cluster Management Stops

Existing workloads: Continue running (Kubelet keeps them alive)
New operations: Impossible (can't create/update/delete resources)
Monitoring: No status updates
Self-healing: Stopped (controllers can't work)

Scenario 2: etcd Fails

Impact: Cluster Loses Memory

Existing workloads: Continue running
State loss: Cluster forgets all configuration
API Server: Can't serve requests (no data source)
Recovery: Must restore from backup

Scenario 3: Kubelet Fails on a Node

Impact: Node Becomes Unmanageable

Existing Pods: May continue running (depends on container runtime)
New Pods: Can't be started on that node
Health checks: Stop working
Status updates: Node marked as NotReady

High Availability Setup

Production clusters use HA configuration:

# High Availability Architecture

Control Plane (3 nodes):
  - 3 × API Server (behind load balancer)
  - 3 × etcd (clustered with Raft consensus)
  - 3 × Scheduler (one active, others standby)
  - 3 × Controller Manager (leader election)

Worker Nodes (many):
  - Each with Kubelet, container runtime, kube-proxy
  - Pods spread across nodes for redundancy

Benefits:
  - Control Plane can survive 1 node failure
  - etcd can survive 1 node failure (3-node cluster)
  - No single point of failure

Key Principles

All communication goes through API Server
Only API Server writes to etcd
Controllers use watch for real-time updates
System continuously reconciles actual vs desired state
HA setup prevents single points of failure

Lesson 5 of 5

Kubernetes in Practice: CI/CD & Helm

Kubernetes for Development

Kubernetes provides a convenient platform for both development and production deployments, with features that integrate well with modern CI/CD workflows.

Development Benefits

Environment parity: Dev/staging/prod all use Kubernetes
Easy testing: Quick to spin up isolated environments
Declarative config: Infrastructure as code
API-driven: Easy to automate

Automated Rollouts with CI/CD

CI/CD tools can monitor the API Server to track deployment status and automatically handle failures.

Typical CI/CD Workflow

1. Code Change
Developer pushes code to Git repository

↓

2. Build
CI system builds container image, pushes to registry

↓

3. Update Deployment
CI tool updates Deployment with new image tag

↓

4. Monitor Rollout
CI tool watches API Server for rollout status

↓

5. Verify Health
Check if new Pods are running and passing health checks

↓

6. Success or Rollback
If healthy: deployment complete
If unhealthy: automatic rollback

Automatic Rollbacks

CI/CD tools can monitor deployment health and automatically rollback on failure:

# Example: GitLab CI/CD monitoring deployment

deploy_job:
  script:
    # Update Deployment with new image
    - kubectl set image deployment/webapp webapp=myapp:v2.0

    # Monitor rollout status
    - kubectl rollout status deployment/webapp --timeout=5m

  # If rollout fails (new Pods won't start):
  on_failure:
    # Automatically rollback to previous version
    - kubectl rollout undo deployment/webapp

# This ensures fault tolerance for the project!

How CI/CD Monitors via API Server

# CI/CD tool workflow:

1. Update Deployment:
   kubectl apply -f deployment.yaml

2. Watch rollout status (queries API Server):
   kubectl rollout status deployment/webapp

   # Returns:
   # - Waiting for deployment to roll out
   # - Current: 2 old Pods, 1 new Pod
   # - Target: 3 new Pods

3. Check Pod health (queries API Server):
   kubectl get pods -l app=webapp

   # If new Pods fail to start or crash:
   # - Readiness probes fail
   # - CrashLoopBackOff status

4. Automatic decision:
   if all_pods_healthy():
       print("Deployment successful!")
   else:
       kubectl rollout undo deployment/webapp
       print("Rolled back to previous version")

Rollback Benefits

Prevents bad deployments from staying in production
Reduces downtime from failed deployments
Provides safety net for developers
Ensures project fault tolerance

Introduction to Helm

Helm is the package manager for Kubernetes. It simplifies deploying and managing complex applications.

What is Helm?

Helm packages Kubernetes resources into Charts - reusable, versioned bundles that can be easily shared and deployed.

Why Use Helm?

Templating: Parameterize YAML files for different environments
Package management: Install complex apps with one command
Versioning: Track and rollback releases
Sharing: Distribute applications via Helm repositories
Dependencies: Manage related applications together

Helm Concepts

# Helm Terminology:

Chart:
  - Package containing Kubernetes manifests
  - Similar to apt/yum package or npm module

Release:
  - Instance of a chart running in the cluster
  - Same chart can be installed multiple times

Values:
  - Configuration parameters for a chart
  - Customize deployment without changing chart

Repository:
  - Collection of charts
  - Like Docker Hub for Kubernetes apps

Helm Example

Without Helm

# Need multiple YAML files:
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f configmap.yaml
kubectl apply -f ingress.yaml

# Different values for dev, staging, prod
# Must maintain 3 sets of files or use complex scripting

With Helm

# Install application with one command:
helm install my-app ./my-chart

# Deploy to different environments with different values:
helm install my-app ./my-chart -f values-dev.yaml
helm install my-app ./my-chart -f values-prod.yaml

# Upgrade:
helm upgrade my-app ./my-chart

# Rollback:
helm rollback my-app 1

Creating a Custom Helm Chart

Basic chart structure:

# Chart directory structure:
my-chart/
  Chart.yaml          # Chart metadata
  values.yaml         # Default configuration values
  templates/          # Kubernetes manifest templates
    deployment.yaml
    service.yaml
    configmap.yaml
  charts/             # Dependent charts

# Chart.yaml example:
apiVersion: v2
name: my-app
version: 1.0.0
description: My application Helm chart

# values.yaml example:
replicaCount: 3
image:
  repository: myapp
  tag: "1.0.0"
service:
  port: 80

# templates/deployment.yaml (templated):
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        ports:
        - containerPort: {{ .Values.service.port }}

Helm Commands

# Install chart
helm install myapp ./my-chart

# List releases
helm list

# Get release status
helm status myapp

# Upgrade release
helm upgrade myapp ./my-chart --set replicaCount=5

# Rollback to previous version
helm rollback myapp

# Uninstall
helm uninstall myapp

# Search for charts
helm search repo nginx

Future Learning

The course will cover:

Detailed Helm explanation
Creating custom charts
Hands-on exercises deploying applications
Chart best practices
Managing dependencies

Production Best Practices

Kubernetes in Production

Use CI/CD: Automate deployments and rollbacks
Monitor rollouts: Watch API Server for deployment status
Implement health checks: Enable automatic detection of failures
Use Helm: Simplify complex deployments
Version everything: Container images, Helm charts, configs
Test rollbacks: Ensure you can recover from failures
HA Control Plane: Prevent single points of failure
Backup etcd: Regularly backup cluster state

Summary: Kubernetes Architecture

Complete Kubernetes Architecture

Control Plane

API Server - Central hub
etcd - Source of truth
Scheduler - Pod placement
Controller Manager - Maintain desired state

⬇ Communication ⬇

Worker Nodes

Kubelet - Node agent
Container Runtime - Run containers
Kube-proxy - Networking
Pods - Your applications

⬆ Status & Health ⬆

External Tools

CI/CD - Automated deployments
Helm - Package management
kubectl - Command-line interface