Your machine: ✅ App runs perfectly
Colleague's machine: ❌ App crashes with dependency errors
Production server: ❌ App won't even start

# On production server:
1. Install Node.js 18.15.0 manually
2. Install PostgreSQL 14 manually
3. Configure environment variables
4. Clone your code from Git
5. Install dependencies: npm install
6. Start the app: npm start
7. Hope nothing breaks 🤞

Problems:
- Takes 2-3 hours to setup
- Different versions = different bugs
- New server = redo all steps
- Server updates might break your app

# Dockerfile (defines your container)
FROM node:18.15.0                    # Start with Node.js 18.15.0
WORKDIR /app                          # Working directory
COPY package*.json ./                 # Copy dependency files
RUN npm install                       # Install dependencies
COPY . .                              # Copy app code
EXPOSE 3000                           # App runs on port 3000
CMD ["npm", "start"]                  # Start the app

# On any server with Docker:
docker build -t myblog:1.0 .          # Build container (1 minute)
docker run -p 3000:3000 myblog:1.0    # Run container (5 seconds)

Benefits:
- Works identically everywhere
- Takes seconds to start
- Isolated from other apps
- Easy to update (new container = new version)

VIRTUAL MACHINES (Heavy):
┌─────────────────────────────────┐
│  Physical Server                 │
│  ├── Hardware (CPU, RAM, Disk)   │
│  ├── Host OS (Windows/Linux)     │
│  ├── Hypervisor (VMware/Hyper-V) │
│  └── Virtual Machines:           │
│      ├── VM 1:                   │
│      │   ├── Guest OS (2 GB)     │ ← Full operating system
│      │   └── App A                │
│      ├── VM 2:                   │
│      │   ├── Guest OS (2 GB)     │ ← Another full OS
│      │   └── App B                │
│      └── VM 3:                   │
│          ├── Guest OS (2 GB)     │ ← Yet another full OS
│          └── App C                │
└─────────────────────────────────┘
Total: 6 GB just for operating systems!

CONTAINERS (Lightweight):
┌─────────────────────────────────┐
│  Physical Server                 │
│  ├── Hardware (CPU, RAM, Disk)   │
│  ├── Host OS (Linux)              │
│  ├── Docker Engine                │
│  └── Containers:                 │
│      ├── Container 1 (App A)     │ ← Shares host OS
│      ├── Container 2 (App B)     │ ← Shares host OS
│      └── Container 3 (App C)     │ ← Shares host OS
└─────────────────────────────────┘
Total: ~100 MB for all containers!

Developer laptop: ✅ Works
Colleague's laptop: ✅ Works (same container)
Testing server: ✅ Works (same container)
Production server: ✅ Works (same container)

VM startup: 2 minutes
Container startup: 2 seconds ← 60x faster!

Physical Server (64 GB RAM):
├── VMs: Can run ~10 VMs (each uses 2+ GB OS)
└── Containers: Can run ~100 containers (share host OS)

Build once → Run anywhere:
- Your laptop (Windows)
- Colleague's laptop (Mac)
- Azure datacenter (Linux)
- AWS datacenter (Linux)
- Google Cloud (Linux)

Container A crashes → Containers B, C, D unaffected
Container B has security bug → Containers A, C, D unaffected

Production Server 1:
- Install Node.js 18
- Install nginx web server
- Install MongoDB 6
- Install Redis 7
- Deploy web app code
- Configure everything manually

Problem: Takes 3-4 hours, prone to human error

New developer joins:
- Spend 2 days setting up local environment
- "It doesn't work on my machine!" ← Wastes days debugging

docker-compose.yml (defines all containers):

version: '3'
services:
  web:                           # Web application
    image: mycompany/webapp:2.1
    ports: ["80:3000"]

  database:                      # MongoDB database
    image: mongo:6.0
    volumes: ["db-data:/data/db"]

  cache:                         # Redis cache
    image: redis:7.0

# On ANY server (dev, staging, production):
docker-compose up -d

# Result:
- Starts 3 containers in 10 seconds
- Works identically everywhere
- New developer: 5 minutes to run entire stack locally

You own 20 shipping containers (your app containers)
You have 5 trucks (your servers)

Every day you manually:
- Decide which containers go on which trucks
- Check if containers fell off trucks (crashed)
- Put fallen containers back on trucks (restart)
- Tell customers which truck has their container
- Swap trucks when they're full

Result: Full-time job, errors, slow

Kubernetes = Smart logistics system

You tell Kubernetes:
- "I need 20 containers of my app running"
- "Each container needs 500 MB RAM"
- "Don't run more than 5 on one truck (server)"

Kubernetes automatically:
✅ Places containers on trucks (servers) optimally
✅ Monitors all containers
✅ Restarts crashed containers instantly
✅ Gives customers one address (myblog.com)
✅ Routes customers to healthy containers
✅ Replaces containers during updates (zero downtime)
✅ Adds/removes containers based on traffic

Result: You focus on your app, Kubernetes handles operations

Your App = Passengers that need to travel

Container = Car (carries your app)

Kubernetes = Smart Transportation System:
- Monitors all cars (containers)
- Dispatches new cars when needed
- Removes cars when traffic is light
- Redirects passengers if a car breaks down
- Shows passengers one address (the airport) instead of 20 car locations
- Replaces old cars with new models (updates) while passengers keep arriving

5:00 AM: Normal traffic (5 containers)
8:00 AM: Traffic increases (need 20 containers)

Your manual actions:
1. Notice website is slow (user complaints pour in)
2. Log into Azure portal
3. Manually create 15 new VMs (20 minutes)
4. Manually start 15 containers
5. Manually update load balancer configuration
6. Total time: 45 minutes of website slowness

4:00 PM: Traffic decreases (back to 5 containers needed)
7. Manually stop 15 containers
8. Manually delete 15 VMs (to save money)
9. Total time: 30 minutes of manual work

Result: Lost sales, frustrated customers, exhausted you

5:00 AM: Normal traffic (5 containers)
8:00 AM: Traffic increases

Kubernetes automatically:
1. Detects high CPU usage (70%+)
2. Creates 15 new containers in 2 minutes
3. Distributes traffic across all 20 containers
4. Total time: 2 minutes, zero human intervention ✅

4:00 PM: Traffic decreases

Kubernetes automatically:
1. Detects low CPU usage (<30%)
2. Gracefully stops 15 containers (waits for requests to finish)
3. Scales back to 5 containers
4. Total time: 5 minutes, zero human intervention ✅

Result: Happy customers, maximized sales, you sleep peacefully

Your responsibilities:
- Install Kubernetes on VMs (complex, 50+ steps)
- Configure networking, storage, security
- Upgrade Kubernetes versions manually
- Monitor control plane (master nodes)
- Pay for control plane VMs
- Fix control plane issues (3am outages)

Time investment: 40-80 hours/month

Your responsibilities:
- Click "Create AKS Cluster" in Azure portal
- Deploy your containers

Azure's responsibilities:
✅ Installs and configures Kubernetes
✅ Manages control plane (free!)
✅ Auto-upgrades Kubernetes
✅ Monitors control plane health 24/7
✅ Fixes control plane issues
✅ Provides enterprise features (security, compliance)

Time investment: 4-8 hours/month
Cost: Control plane is FREE, you only pay for worker nodes (VMs that run your containers)

System Node Pool (always on):
- 2-3 nodes, Standard_D2s_v3 (2 vCPU, 8 GB)
- Runs CoreDNS, metrics-server, kube-system pods
- Cost: ~$145/month for 2 nodes

User Node Pool (your workloads):
- Autoscaling: 2-10 nodes, Standard_D4s_v3
- Runs your application pods
- Cost: $290-$1,430/month depending on scale

Spot Node Pool (batch jobs, non-critical):
- Standard_D4s_v3 Spot VMs (up to 90% discount)
- For CI/CD runners, batch processing, dev environments
- Cost: ~$29/month per node (vs $143 on-demand)

20 VMs × $50/month = $1,000/month
+ Slow to scale (5-10 minutes to provision new VM)
+ Manual management required

3 Control Plane VMs × $50 = $150/month  ← You pay for this
5 Worker VMs × $80 = $400/month         ← You pay for this
Total: $550/month
+ You manage control plane (time cost)
+ Complex setup and maintenance

Control Plane: $0/month                 ← Azure manages free!
5 Worker VMs × $80 = $400/month         ← You only pay this
Total: $400/month
+ Azure manages control plane
+ Enterprise-grade security and updates
+ Scales in seconds
+ Integrates with Azure services

# Create AKS cluster
az aks create \
  --name aks-prod \
  --resource-group rg-prod \
  --node-count 3 \
  --node-vm-size Standard_D4s_v3 \
  --zones 1 2 3 \
  --enable-managed-identity \
  --network-plugin azure \
  --enable-addons monitoring \
  --generate-ssh-keys

# Get credentials
az aks get-credentials \
  --name aks-prod \
  --resource-group rg-prod

# Verify
kubectl get nodes

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: myregistry.azurecr.io/web:v1
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi
        ports:
        - containerPort: 80

---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: web

---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - myapp.example.com
    secretName: tls-secret
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml

Helm Chart (Package)
├── Chart.yaml          # Metadata (name, version)
├── values.yaml         # Default configuration
├── templates/          # Kubernetes manifests with templating
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
└── charts/             # Dependencies (sub-charts)

# Create new chart
helm create myapp

# Chart structure created:
myapp/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl

apiVersion: v2
name: myapp
description: A Helm chart for my application
type: application
version: 1.0.0        # Chart version
appVersion: "2.5.1"   # Application version

replicaCount: 3

image:
  repository: myregistry.azurecr.io/myapp
  tag: "2.5.1"
  pullPolicy: IfNotPresent

service:
  type: LoadBalancer
  port: 80

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: myapp.example.com
      paths:
        - path: /
          pathType: Prefix

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
  labels:
    {{- include "myapp.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "myapp.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "myapp.selectorLabels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - name: http
          containerPort: 80
          protocol: TCP
        resources:
          {{- toYaml .Values.resources | nindent 12 }}

# Install chart
helm install myapp ./myapp

# Install with custom values
helm install myapp ./myapp \
  --set replicaCount=5 \
  --set image.tag=3.0.0

# Install with values file
helm install myapp ./myapp \
  -f values-production.yaml

# Upgrade deployment
helm upgrade myapp ./myapp \
  --set image.tag=3.1.0

# Rollback to previous version
helm rollback myapp 1

# Uninstall
helm uninstall myapp

# Add official Helm repo
helm repo add stable https://charts.helm.sh/stable

# Add Bitnami repo (popular charts)
helm repo add bitnami https://charts.bitnami.com/bitnami

# Search for charts
helm search repo nginx

# Install from repository
helm install my-nginx bitnami/nginx

# Update repo index
helm repo update

replicaCount: 1
image:
  tag: "latest"
ingress:
  hosts:
    - host: myapp-dev.example.com

replicaCount: 5
image:
  tag: "2.5.1"
ingress:
  hosts:
    - host: myapp.example.com
resources:
  limits:
    cpu: 1000m
    memory: 1Gi

# Deploy to dev
helm install myapp ./myapp -f values-dev.yaml

# Deploy to prod
helm install myapp ./myapp -f values-prod.yaml

Git Repository (Source of Truth)
    ↓
ArgoCD (Continuous Sync)
    ↓
Kubernetes Cluster (Desired State)

# Create namespace
kubectl create namespace argocd

# Install ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Expose ArgoCD UI (LoadBalancer)
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

# Get admin password
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

# Get external IP
kubectl get svc argocd-server -n argocd

my-app-gitops/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── dev/
│   │   └── kustomization.yaml
│   └── prod/
│       └── kustomization.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/my-app-gitops
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # Delete resources not in Git
      selfHeal: true   # Auto-sync if cluster drifts
    syncOptions:
      - CreateNamespace=true

# Apply ArgoCD application
kubectl apply -f argocd-app.yaml

# Or use ArgoCD CLI
argocd app create myapp-prod \
  --repo https://github.com/myorg/my-app-gitops \
  --path overlays/prod \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --sync-policy automated

Developer commits code
    ↓
CI builds Docker image (tag: v1.2.3)
    ↓
CI updates Git repo (image: myapp:v1.2.3)
    ↓
ArgoCD detects change
    ↓
ArgoCD syncs to cluster
    ↓
Deployment updated automatically

Application Pod
├── App Container (your code)
└── Envoy Sidecar (injected by Istio)
    ↓
All traffic flows through Envoy
    ↓
Istio Control Plane (manages Envoy configs)

# Download Istio
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.0

# Install Istio
istioctl install --set profile=demo -y

# Enable sidecar injection for namespace
kubectl label namespace default istio-injection=enabled

# Verify
kubectl get pods -n istio-system

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
    - myapp.example.com
  http:
    - match:
        - headers:
            user-type:
              exact: beta-tester
      route:
        - destination:
            host: myapp
            subset: v2
    - route:
        - destination:
            host: myapp
            subset: v1
          weight: 90
        - destination:
            host: myapp
            subset: v2
          weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

# Enforce restricted policy on namespace
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: true

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-web
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 8080

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

# Install CSI driver
helm repo add csi-secrets-store-provider-azure \
  https://azure.github.io/secrets-store-csi-driver-provider-azure/charts

helm install csi csi-secrets-store-provider-azure/csi-secrets-store-provider-azure

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-sync
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: "your-identity-client-id"
    keyvaultName: "mykeyvault"
    objects: |
      array:
        - |
          objectName: database-password
          objectType: secret
    tenantId: "your-tenant-id"

apiVersion: v1
kind: Pod
metadata:
  name: app-with-secrets
spec:
  containers:
  - name: app
    image: myapp:1.0
    volumeMounts:
    - name: secrets-store
      mountPath: "/mnt/secrets"
      readOnly: true
  volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: "azure-kv-sync"

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None  # Headless service
  selector:
    app: mysql
  ports:
  - port: 3306
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: managed-premium
      resources:
        requests:
          storage: 100Gi

# Direct access to specific pod
mysql-0.mysql.default.svc.cluster.local
mysql-1.mysql.default.svc.cluster.local
mysql-2.mysql.default.svc.cluster.local

# Install KEDA
helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --namespace keda --create-namespace

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
spec:
  scaleTargetRef:
    name: order-processor  # Deployment to scale
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders
      namespace: mynamespace
      messageCount: "10"  # Scale up when >10 messages
      connectionFromEnv: SERVICEBUS_CONNECTION

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-processor
spec:
  replicas: 1  # KEDA will override this
  selector:
    matchLabels:
      app: order-processor
  template:
    metadata:
      labels:
        app: order-processor
    spec:
      containers:
      - name: processor
        image: myapp/order-processor:1.0
        env:
        - name: SERVICEBUS_CONNECTION
          valueFrom:
            secretKeyRef:
              name: servicebus-secret
              key: connection-string