Kubernetes for Beginners: Complete Guide for Cloud Engineers (2026)

Kubernetes (K8s) went from Google's internal infrastructure tool to the standard way the world runs containerized workloads. If you're building a cloud engineering career in 2026, Kubernetes isn't optional — it's expected.

The CKA (Certified Kubernetes Administrator) is now one of the most sought-after cloud certifications. Every cloud job posting at senior levels mentions K8s. AWS EKS, Google GKE, and Azure AKS have made managed Kubernetes available to every team.

This guide gets you from zero Kubernetes knowledge to understanding real production clusters — no fluff, just the concepts and commands you'll actually use.

What Is Kubernetes and Why Does It Exist?

Kubernetes is an orchestration platform for containers. Once you understand Docker (containers), Kubernetes answers the next question: *how do I run thousands of containers across hundreds of servers, reliably, with auto-scaling, self-healing, and zero-downtime deployments?*

Docker runs containers on one machine. Kubernetes runs containers across a cluster of machines — and manages everything:

• Scheduling: Which server should run this container?
• Self-healing: If a container crashes, restart it automatically
• Scaling: Traffic spike? Add more replicas in seconds
• Networking: How do containers talk to each other and the outside world?
• Configuration: Inject secrets and config without rebuilding images
• Rolling updates: Deploy new versions with zero downtime

Why cloud engineers use Kubernetes:

Most production workloads at mid-to-large companies run on Kubernetes. AWS EKS (Elastic Kubernetes Service) is the dominant deployment target. Even if you're not managing the cluster yourself, you'll write Kubernetes manifests, debug pods, and understand how workloads are scheduled.

Kubernetes Architecture: The Big Picture

Before writing any YAML, understand the two layers of every Kubernetes cluster.

The Control Plane (brain of the cluster)

The control plane makes decisions about the cluster — scheduling pods, maintaining desired state, and responding to changes.

Key components:

• API Server: The front door — every kubectl command hits the API server
• etcd: A distributed key-value store holding the entire cluster state
• Scheduler: Assigns pods to nodes based on resource requirements
• Controller Manager: Runs control loops that watch cluster state and make changes

On EKS, AWS manages the control plane for you. You pay per cluster per hour and never worry about etcd backups or API server availability.

Worker Nodes (where your apps run)

Worker nodes are the VMs that actually run your containers.

Key components on each node:

• kubelet: The agent on every node, reports to the control plane and manages pods
• kube-proxy: Handles networking rules for pod-to-pod and pod-to-service communication
• Container runtime: Usually containerd (Docker is deprecated as a runtime)

Core Kubernetes Concepts

Pods — the smallest deployable unit

A Pod is one or more containers that share a network namespace and storage. In practice, most Pods run a single container.

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
  - name: my-app
    image: nginx:1.27
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Important: You almost never create Pods directly. You use Deployments that manage Pods for you.

Deployments — managing replica sets

A Deployment manages a set of identical Pods (replicas), ensures the desired number is always running, and handles rolling updates.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3                    # 3 identical pods
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.2.3
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "production"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 5
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # 1 extra pod during update
      maxUnavailable: 0   # Never kill old pods before new ones are ready

This deployment creates 3 replicas of your app, rolling out new versions without downtime.

Services — stable networking for pods

Pods are ephemeral — they get killed and replaced constantly, changing IP addresses. A Service provides a stable DNS name and IP that routes traffic to healthy pods.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app          # Routes to any pod with this label
  ports:
  - port: 80             # Service listens on port 80
    targetPort: 3000     # Forwards to container port 3000
  type: ClusterIP        # Only accessible within the cluster

Service types:

• ClusterIP — internal only, for pod-to-pod communication
• NodePort — exposes on each node's IP (not for production)
• LoadBalancer — creates an AWS ALB/NLB (the usual production choice)

Ingress — routing external traffic

For HTTP traffic, use an Ingress controller (like AWS Load Balancer Controller or nginx-ingress) to route traffic to services based on hostnames and paths.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: api.myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

ConfigMaps and Secrets

Never hardcode configuration. Use ConfigMaps for non-sensitive config and Secrets for passwords, API keys, and certificates.

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  REGION: "us-east-1"

---
# Secret (base64-encoded values)
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database-url: cG9zdGdyZXM6Ly91c2VyOnBhc3NAaG9zdC9kYg==
  api-key: c3VwZXJzZWNyZXRrZXk=

In production, use AWS Secrets Manager with the Secrets Store CSI driver instead of K8s Secrets (which are only base64-encoded, not encrypted).

Namespaces — logical cluster partitioning

Namespaces divide a cluster into isolated virtual clusters. Common patterns:

# List namespaces
kubectl get namespaces

# Typical setup:
# default     — general workloads
# kube-system — cluster components (DNS, metrics, etc.)
# monitoring  — Prometheus, Grafana
# staging     — staging environment
# production  — production workloads

Essential kubectl Commands

# Cluster info
kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide  # more details including IPs

# Working with resources
kubectl get pods                          # all pods in default namespace
kubectl get pods -n production            # pods in production namespace
kubectl get pods -A                       # all pods in all namespaces
kubectl get pods -w                       # watch mode — live updates
kubectl describe pod my-pod               # detailed info + events

# Deployments
kubectl get deployments
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app
kubectl rollout undo deployment/my-app    # rollback!

# Scaling
kubectl scale deployment my-app --replicas=5
kubectl autoscale deployment my-app --min=2 --max=10 --cpu-percent=70

# Debugging
kubectl logs my-pod                       # logs from pod
kubectl logs my-pod -f                    # follow logs
kubectl logs my-pod --previous            # logs from crashed container
kubectl exec -it my-pod -- /bin/sh        # shell into running container
kubectl port-forward pod/my-pod 8080:3000 # forward local port

# Apply manifests
kubectl apply -f deployment.yaml
kubectl apply -f ./manifests/             # apply entire directory
kubectl delete -f deployment.yaml

# Get YAML of existing resource
kubectl get deployment my-app -o yaml

Horizontal Pod Autoscaler (HPA)

HPA automatically scales your deployment based on CPU/memory usage.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60    # scale up when CPU > 60%
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 400Mi

With proper resource requests set, HPA will scale your app automatically during traffic spikes.

Running Kubernetes on AWS: EKS

AWS EKS (Elastic Kubernetes Service) is the production standard for Kubernetes on AWS. The control plane is fully managed — you just create worker node groups.

Create an EKS Cluster with eksctl

# Install eksctl
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

# Create a production-ready cluster
eksctl create cluster \
  --name production-cluster \
  --region us-east-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 10 \
  --managed \
  --with-oidc \
  --amd64

# Configure kubectl to talk to your cluster
aws eks update-kubeconfig \
  --region us-east-1 \
  --name production-cluster

kubectl get nodes  # verify connection

EKS with Terraform (production pattern)

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "production"
  cluster_version = "1.30"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  cluster_endpoint_public_access = true

  eks_managed_node_groups = {
    general = {
      min_size       = 2
      max_size       = 10
      desired_size   = 3
      instance_types = ["t3.medium"]
      
      labels = {
        role = "general"
      }
    }
    
    spot = {
      min_size       = 0
      max_size       = 20
      desired_size   = 0
      instance_types = ["t3.large", "t3a.large", "m5.large"]
      capacity_type  = "SPOT"
      
      labels = {
        role = "spot"
      }
    }
  }

  tags = {
    Environment = "production"
    Team        = "platform"
  }
}

Helm: The Kubernetes Package Manager

Writing Kubernetes YAML for every deployment gets repetitive. Helm is the package manager for Kubernetes — it lets you template, version, and share K8s manifests.

# Install Helm
brew install helm

# Add common chart repositories
helm repo add stable https://charts.helm.sh/stable
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install nginx ingress controller
helm install nginx-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.service.type=LoadBalancer

# Install cert-manager (automatic TLS certificates)
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true

# Install your own app with Helm
helm install my-app ./charts/my-app \
  --namespace production \
  --values ./values/production.yaml

# Upgrade (rolling update)
helm upgrade my-app ./charts/my-app \
  --namespace production \
  --values ./values/production.yaml

# Rollback
helm rollback my-app 1  # rollback to revision 1

Creating a Basic Helm Chart

helm create my-app
# Creates:
# my-app/
#   Chart.yaml          — chart metadata
#   values.yaml         — default values
#   templates/          — K8s manifest templates
#     deployment.yaml
#     service.yaml
#     ingress.yaml
#     hpa.yaml
#     _helpers.tpl

Real-World Production Patterns

1. Health Checks (Liveness + Readiness Probes)

livenessProbe:
  httpGet:
    path: /health/live
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3       # restart after 3 consecutive failures

readinessProbe:
  httpGet:
    path: /health/ready
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3       # remove from load balancer after 3 failures

• Liveness probe: Is the app alive? Failed = restart the container
• Readiness probe: Is the app ready to serve traffic? Failed = remove from service endpoints

2. Pod Disruption Budgets

Ensure you always have a minimum number of healthy pods during rolling updates or node drains.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2     # always keep 2 pods running
  selector:
    matchLabels:
      app: my-app

3. Resource Requests and Limits

Always set these — otherwise the scheduler can't make good decisions, and a runaway container can kill a node.

resources:
  requests:              # guaranteed resources (used for scheduling)
    memory: "256Mi"
    cpu: "100m"          # 100 millicores = 0.1 CPU
  limits:                # maximum allowed (container killed if exceeded)
    memory: "512Mi"
    cpu: "500m"

4. Multi-Container Pods (Sidecar Pattern)

spec:
  containers:
  - name: my-app
    image: my-app:latest
  - name: log-shipper          # sidecar: ships logs to CloudWatch
    image: fluent/fluent-bit
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

Kubernetes vs ECS: When to Use What

A common question for AWS engineers:

Use ECS Fargate when: you're on AWS-only, want simplicity, and are running fewer than ~100 services.

Use EKS when: you need portability, have a large engineering team, require advanced K8s features (service meshes, custom operators), or are targeting the CKA certification.

Getting the CKA Certification

The Certified Kubernetes Administrator (CKA) is the industry's top K8s certification. It's a hands-on exam — you get a live cluster and 2 hours to complete tasks.

Study path:

1. Complete the official Kubernetes docs (kubernetes.io)
2. Practice with killer.sh (the exam simulator)
3. Build real clusters on EKS or minikube
4. Practice the 25 most common kubectl commands until they're muscle memory

CKA holders earn $140K–$200K+ at US companies in 2026. It's one of the highest-ROI certifications in cloud engineering.

Start Practicing Today

The fastest way to learn Kubernetes is hands-on:

# Option 1: Local with minikube
brew install minikube
minikube start
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
kubectl get pods -w

# Option 2: Local with kind (Kubernetes in Docker)
brew install kind
kind create cluster --name learning
kubectl cluster-info --context kind-learning

# Option 3: Free EKS tier (AWS Free Tier doesn't cover EKS — $0.10/hr for control plane)
eksctl create cluster --name learning --fargate

CloudPath Academy's Kubernetes Path

CloudPath Academy's Phase 3 (DevOps Engineer) covers Kubernetes in depth:

• Container fundamentals with Docker
• Kubernetes architecture and core objects
• EKS cluster setup with Terraform
• Helm chart development
• Production patterns: HPA, PDB, probes, resource management
• GitOps with ArgoCD
• Service meshes with AWS App Mesh
• Kubernetes security (RBAC, network policies, secrets management)

Students who complete Phase 3 and earn the DevOps Engineer certificate have built and deployed real Kubernetes workloads — not just read about them.

*Ready to go from K8s beginner to cloud engineer? CloudPath Academy's hands-on curriculum takes you from cloud fundamentals to production Kubernetes in 12 weeks.*