Kubernetes Masterclass

Kubernetes Core Components & Architecture Guide

Everything you need to build, run, and scale modern applications in Kubernetes. Architectural concepts, YAML manifests, and command cheat sheets.

Clouddevophub DevOps & Kubernetes 15 Min Comprehensive Guide

Executive Architecture Overview

Kubernetes (K8s) automates deployment, scaling, and management of containerized applications. It abstracts physical infrastructure into an intelligent, self-healing compute engine. The platform is composed of 10 core workload & configuration components governed by a Control Plane & Worker Node architecture.

Page 1: Kubernetes Core Components Map (Replace with Page 1 Screenshot in Graphy)

🖼️ Page 1: Kubernetes Core Components Map (Replace Image in Graphy Page Builder)

1. Pods — Smallest Deployable Units

A Pod is the foundational execution unit in Kubernetes. It represents a single instance of a running process in your cluster and wraps one or more containers that share network, storage, and lifecycle specifications.

Page 2: Kubernetes Pods Architecture & Lifecycle (Replace with Page 2 Screenshot in Graphy)

🖼️ Page 2: Pod Architecture, Shared IP/Storage & Lifecycle (Replace Image in Graphy)

Key Characteristics

  • Shared Network & IP: Containers in a Pod share the same network namespace and IP address.
  • Shared Storage Volumes: Containers can mount the same storage volumes for easy file sharing.
  • Ephemeral Nature: Pods are disposable; they are created, scaled, destroyed, and replaced dynamically.
  • Controller Managed: Managed by higher-level primitives like Deployments, StatefulSets, and Jobs.

Pod Lifecycle Phases

Pending: Accepted by cluster, awaiting scheduling
Scheduled: Assigned to a target Worker Node
Running: Containers created and running
Succeeded / Failed: Completed execution or errored
Terminated: Shut down and removed

2. Nodes — The Workhorses of Kubernetes

A Node is a worker machine (virtual machine or physical bare-metal server) where containerized Pod workloads are scheduled and run.

Page 3: Kubernetes Node Components (Replace with Page 3 Screenshot in Graphy)

🖼️ Page 3: Node Architecture (Control Plane vs Worker Nodes) (Replace Image in Graphy)

Control Plane Node

Runs master management components (API Server, etcd, Scheduler, Controller Manager). Makes global cluster decisions and handles events.

Worker Node

Executes actual application Pods. Managed directly by the Control Plane and contains essential node agents (kubelet, kube-proxy, runtime).

Essential Node Components:

  • kubelet — Primary node agent that communicates with API Server and enforces container state inside Pods.
  • kube-proxy — Network proxy maintaining network rules on nodes and enabling Service connectivity across the cluster.
  • Container Runtime — Underlying software that executes containers (e.g. containerd, CRI-O, Docker).

3. Deployments — Declarative Application Scaling

A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment YAML, and the Deployment Controller transitions the actual state to the desired state at a controlled rate.

Page 4: Deployments & Rolling Updates (Replace with Page 4 Screenshot in Graphy)

🖼️ Page 4: Deployments, ReplicaSets & Rolling Update Flow (Replace Image in Graphy)

How Deployments Work (Rolling Update Flow):

1. Define Desired State 2. Create ReplicaSet 3. Pods Created 4. Self-Healing 5. Rolling Update & Rollback
deployment-example.yaml
YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

4. Services — Stable Networking for Pods

Pods are ephemeral and get dynamic IP addresses assigned upon restart. A Service is an abstraction that defines a logical set of Pods and a policy to access them, providing a persistent Virtual IP (VIP) and DNS name.

Page 5: Services Architecture (Replace with Page 5 Screenshot in Graphy)

🖼️ Page 5: Service Types (ClusterIP, NodePort, LoadBalancer) (Replace Image in Graphy)

ClusterIP (Default)

Exposes Service on an internal cluster-only IP. Reachable only within the cluster.

NodePort

Exposes Service on each Node's IP at a static port (in range 30000–32767).

LoadBalancer

Exposes Service externally using a cloud provider's external load balancer.

ExternalName

Maps Service to external DNS name (returns CNAME record without proxying).

5. Ingress — Smart HTTP/HTTPS Routing

Ingress manages external HTTP and HTTPS access to services within a cluster. It supports path-based and host-based routing, SSL/TLS termination, and centralized load balancing under a single IP address.

Page 6: Ingress Routing (Replace with Page 6 Screenshot in Graphy)

🖼️ Page 6: Ingress Controller Host & Path-Based Routing (Replace Image in Graphy)

ingress-example.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: service-b
            port:
              number: 80

6. ConfigMaps & Secrets — Configuration Management

Decoupling configuration artifacts from application code makes containerized workloads portable across environments (Dev, Staging, Prod).

Page 7: ConfigMaps (Replace with Page 7 Screenshot in Graphy)

🖼️ Page 7: ConfigMaps Non-Sensitive Data Storage (Replace Image in Graphy)

Page 8: Secrets (Replace with Page 8 Screenshot in Graphy)

🖼️ Page 8: Secrets Encrypted Sensitive Data Storage (Replace Image in Graphy)

ConfigMaps

Stores non-sensitive configuration data in key-value pairs (e.g. database hostnames, feature flags, log levels).

  • Mounted as files inside volume directories
  • Injected as environment variables

Secrets

Stores sensitive data (passwords, OAuth tokens, SSH keys, TLS certificates). Encrypted at rest in etcd and Base64 encoded.

  • RBAC access controlled
  • Mounted into RAM-backed tmpfs volumes

7. Storage — Persistent Storage for Stateful Workloads

Kubernetes separates storage requests from storage implementation using three abstractions:

  • PersistentVolume (PV): A cluster-wide storage resource provisioned by admins or dynamically created by StorageClass.
  • PersistentVolumeClaim (PVC): A request for storage by a user/Pod (specifying size and access mode).
  • StorageClass (SC): Defines dynamic provisioners (AWS EBS, GCP PD, NFS) and storage parameters.
Page 9: Storage PV, PVC & StorageClass (Replace with Page 9 Screenshot in Graphy)

🖼️ Page 9: Persistent Storage Architecture (PV, PVC, StorageClass) (Replace Image in Graphy)

8. Networking Architecture (CNI, Kube-Proxy & CoreDNS)

Kubernetes networking enforces the fundamental rule: Every Pod receives its own unique IP address and can communicate with all other Pods without NAT.

Page 10: Networking CNI, Kube-Proxy & CoreDNS (Replace with Page 10 Screenshot in Graphy)

🖼️ Page 10: CNI Networking, Kube-Proxy Routing & CoreDNS Flow (Replace Image in Graphy)

CNI Plugins

Responsible for setting up network interfaces and routing across nodes (Calico, Flannel, Cilium, Weave).

kube-proxy

Manages iptables or IPVS routing rules on nodes to forward Service traffic to backend Pods.

CoreDNS

Internal cluster DNS server that automatically resolves Service names to ClusterIPs and Pod IPs.

9. Pod Scheduling, Taints & Affinity

The kube-scheduler assigns unscheduled Pods to optimal Worker Nodes based on resource requests, constraints, and affinity rules.

Page 11: Pod Scheduling & Affinity (Replace with Page 11 Screenshot in Graphy)

🖼️ Page 11: Scheduler Flow, Taints, Tolerations & Affinity (Replace Image in Graphy)

Placement Control Mechanisms:

  • Taints & Tolerations: Taints are set on Nodes to repel Pods. Pods with matching Tolerations can be scheduled on tainted Nodes.
  • Node Affinity: Constrains Pod placement based on Node labels (Hard: requiredDuringScheduling... vs Soft: preferredDuringScheduling...).
  • Pod Affinity / Anti-Affinity: Schedules Pods close together (Affinity) or apart on separate nodes/zones (Anti-Affinity) for high availability.

10. Kubernetes Architecture & CLI Command Cheat Sheet

Page 12: Architecture & Cheat Sheet (Replace with Page 12 Screenshot in Graphy)

🖼️ Page 12: Kubernetes Master Architecture & CLI Cheat Sheet (Replace Image in Graphy)

Category Command Description
Pods kubectl get pods -o wide List all pods with IP address and Node details
Pods kubectl describe pod <pod-name> Show detailed state, events, and diagnostics for a pod
Pods kubectl logs <pod-name> --previous Print logs from previously crashed container instance
Deployments kubectl create deploy <name> --image=<image> Create a new deployment imperatively
Deployments kubectl scale deploy <name> --replicas=5 Scale deployment replica count up or down
Deployments kubectl rollout status deploy/<name> Watch rollout progress of a deployment update
Services kubectl get svc List all services in current namespace
Services kubectl get endpoints <svc-name> View active backend Pod IPs linked to a service
Cluster & Nodes kubectl get nodes -o wide List cluster worker nodes and OS/Kernel versions
Cluster & Nodes kubectl top nodes / kubectl top pods Display real-time CPU and Memory metrics usage

Summary Takeaway

Understanding Kubernetes core components—from Pod lifecycles to Service networking and Controller rollouts—empowers DevOps engineers to design resilient, production-ready microservice architectures.