Kubernetes for Beginners - Complete Guide

📦 Pod

Pod is the smallest unit in Kubernetes. It's a group of one or more Docker containers that share storage and network. In 99% of cases: 1 Pod = 1 container.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

🚀 Deployment

Deployment manages Pods. You define how many replicas you want, and Kubernetes automatically creates and maintains the appropriate number of Pods. Handles rolling updates, rollback, and self-healing.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # 3 copies of the application
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

🌐 Service

Service is a stable endpoint for Pods. Pods have dynamic IPs that change with every restart. Service provides a stable DNS name and load balancing.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer  # Public IP
  selector:
    app: my-app  # Routes traffic to Pods with this label
  ports:
  - port: 80        # External port
    targetPort: 8080  # Port in container

⚙️ ConfigMap & Secret

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  API_URL: "https://api.example.com"
  LOG_LEVEL: "info"

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64
  API_KEY: c2VjcmV0a2V5NDU2=

Basic commands

Deployment & Configuration

Updates & Rollbacks

Debugging & Troubleshooting

Cleanup

Rolling Update (default)

Gradual replacement of Pods from old version to new. Kubernetes removes old Pods and creates new ones in batches, maintaining minimum running replicas.

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # Max 1 Pod offline
      maxSurge: 2        # Max 2 extra Pods during update

Blue/Green Deployment

Two identical environments: Blue (current production) and Green (new version). Deploy to Green, test, switch traffic from Blue to Green (instant switch).

Canary Deployment

New version first goes to a small group of users (e.g., 5%). If everything is OK, gradually increase percentage (10%, 25%, 50%, 100%).

Horizontal Pod Autoscaler (HPA)

Automatically scales the number of Pods based on CPU, memory, or custom metrics. Example: 10% CPU → 2 Pods, 80% CPU → 10 Pods.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # Scale if CPU > 70%

Vertical Pod Autoscaler (VPA)

Automatically adjusts CPU/RAM requests and limits. Useful when you don't know optimal resource allocation.

Cluster Autoscaler (Node-level)

Adds/removes worker nodes when Pods can't be scheduled due to lack of resources. Example: 10 Pods need 20GB RAM, cluster has 16GB → Cluster Autoscaler adds new node.

Kubernetes networking basics

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

CNI (Container Network Interface)

CNI plugin implements the Kubernetes networking model. CNI choice affects performance and features.

Network Policies (firewall rules)

Network Policies are firewalls for Pods. By default all Pods can communicate with all. Network Policy restricts communication.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend  # Only frontend can connect to backend

Option 1: Local Development (minikube)

Best for learning and local testing. Single-node cluster on your laptop.

# Install minikube (macOS)
brew install minikube

# Start cluster
minikube start --driver=docker

# Verify
kubectl cluster-info
kubectl get nodes

Option 2: Azure AKS (Production-ready)

Managed Kubernetes from Azure. Free Control Plane, pay only for nodes.

# Create resource group
az group create --name my-k8s-rg --location westeurope

# Create AKS cluster (2 nodes, Standard_D2s_v3)
az aks create \
  --resource-group my-k8s-rg \
  --name my-aks-cluster \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 5 \
  --generate-ssh-keys

# Get credentials
az aks get-credentials --resource-group my-k8s-rg --name my-aks-cluster

# Verify
kubectl get nodes

Option 3: AWS EKS

Managed Kubernetes from AWS. $73/month for Control Plane + node costs.

# Install eksctl
brew install eksctl

# Create cluster (2 t3.medium nodes)
eksctl create cluster \
  --name my-eks-cluster \
  --region us-east-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 2 \
  --nodes-max 5 \
  --managed

# Verify
kubectl get nodes

Step 1: Prepare Docker Image

First, containerize your Node.js app and push to container registry (Docker Hub, Azure ACR, AWS ECR).

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Step 2: Kubernetes Deployment

Create Deployment with 3 replicas, resource limits, health checks.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nodejs-api
  template:
    metadata:
      labels:
        app: nodejs-api
    spec:
      containers:
      - name: api
        image: myregistry.azurecr.io/nodejs-api:v1.0
        ports:
        - containerPort: 3000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url
        - name: NODE_ENV
          value: "production"
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5

Step 3: Service & Ingress

Expose API via LoadBalancer Service and configure Ingress for HTTPS.

apiVersion: v1
kind: Service
metadata:
  name: nodejs-api-service
spec:
  type: LoadBalancer
  selector:
    app: nodejs-api
  ports:
  - port: 80
    targetPort: 3000

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nodejs-api-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls-cert
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nodejs-api-service
            port:
              number: 80

Step 4: Auto-scaling Configuration

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nodejs-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nodejs-api
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Step 5: Deploy to Kubernetes

# Create namespace
kubectl create namespace production

# Create secret for database
kubectl create secret generic db-secret \
  --from-literal=url="postgresql://user:pass@db.example.com/mydb" \
  -n production

# Apply all manifests
kubectl apply -f deployment.yaml -n production
kubectl apply -f service.yaml -n production
kubectl apply -f ingress.yaml -n production
kubectl apply -f hpa.yaml -n production

# Watch deployment
kubectl get pods -n production -w

# Get LoadBalancer IP
kubectl get service nodejs-api-service -n production

Security

• •
  Never run containers as root: Use runAsNonRoot: true in Pod spec
• •
  Use Network Policies: Restrict Pod-to-Pod communication to necessary services only
• •
  Secrets management: Use Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault instead of K8s Secrets
• •
  Image scanning: Scan container images for vulnerabilities (Trivy, Snyk, Azure Defender)
• •
  RBAC: Use Role-Based Access Control – developers shouldn't have cluster-admin rights

Resource Management

• •
  Always set requests & limits: CPU/RAM requests for scheduling, limits to prevent resource hogging
• •
  Use QoS classes wisely: Guaranteed (requests = limits) for critical apps, Burstable for most workloads
• •
  ResourceQuotas per namespace: Prevent one team from consuming all cluster resources
• •
  Monitor resource usage: Use Prometheus + Grafana or cloud-native monitoring

Reliability

• •
  Health checks are mandatory: Both liveness (restart unhealthy Pods) and readiness (don't send traffic to starting Pods)
• •
  PodDisruptionBudget: Ensure minimum number of Pods during voluntary disruptions (node upgrades)
• •
  Multi-zone deployment: Spread Pods across availability zones for fault tolerance
• •
  Graceful shutdown: Handle SIGTERM properly, finish in-flight requests before exit

Deployment Strategy

• •
  Use GitOps: ArgoCD or Flux for declarative deployments from Git repo
• •
  Rolling updates: Default strategy, gradual Pod replacement without downtime
• •
  Canary deployments: Deploy new version to 10% traffic, verify, then 100%
• •
  Rollback plan: Always test rollback before production deployment

Cost Optimization

• •
  Right-size nodes: Use node pools with different VM sizes for different workloads
• •
  Spot/Preemptible instances: Save 60-80% for fault-tolerant workloads
• •
  Cluster Autoscaler: Scale down nodes during low traffic (nights, weekends)
• •
  Monitor costs: Use Kubecost or cloud-native cost management tools

1. No resource requests/limits

Problem: Pods can consume all node resources, causing OOM kills and cluster instability.

Solution: Always set resources.requests and resources.limits for every container.

2. Ignoring health checks

Problem: Kubernetes sends traffic to unhealthy Pods, causing 5xx errors.

Solution: Implement livenessProbe and readinessProbe for every Pod.

3. Running as root

Problem: Security risk – if container is compromised, attacker has root access.

Solution: Set securityContext.runAsNonRoot: true and use non-root user in Dockerfile.

4. Single replica for critical services

Problem: If the only Pod crashes or node dies, service is down.

Solution: Use replicas: 3 minimum for production services.

5. Storing secrets in Git

Problem: Secrets in manifests are visible in Git history – security breach.

Solution: Use external secret managers (Azure Key Vault, AWS Secrets Manager) or Sealed Secrets.

6. No monitoring & logging

Problem: When something breaks, you're blind – no idea what went wrong.

Solution: Use Prometheus + Grafana for metrics, ELK/Loki for logs, Jaeger for tracing.