A Namespace is a virtual cluster inside a physical Kubernetes cluster. It provides logical isolation — you can have the same resource names in different namespaces without conflict. Think of it like folders on a computer. By default K8s has: default, kube-system, kube-public, kube-node-lease.

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
  labels:
    env: production
    team: backend

A ConfigMap stores non-sensitive configuration data as key-value pairs. It decouples environment-specific configuration from container images, so the same image works in dev/staging/prod by just swapping the ConfigMap. Pods consume ConfigMaps as env vars, command-line args, or mounted files.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: my-app
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  DB_HOST: "postgres-service"
  config.yaml: |            # file-style key
    server:
      port: 8080
      timeout: 30s

---
# Pod consuming ConfigMap in all 3 ways
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  namespace: my-app
spec:
  containers:
  - name: app
    image: myapp:1.0
    # Pattern 1: Load ALL keys as env vars
    envFrom:
    - configMapRef:
        name: app-config
    # Pattern 2: Load specific key as env var
    env:
    - name: DATABASE_HOST
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: DB_HOST
    # Pattern 3: Mount as file in container
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

A Secret stores sensitive data like passwords, tokens, SSH keys. Values are base64 encoded (NOT encrypted by default — just encoded). For real security, use encryption at rest (EncryptionConfiguration) + RBAC. Secret types: Opaque (generic), kubernetes.io/tls, kubernetes.io/dockerconfigjson, kubernetes.io/service-account-token.

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
  namespace: my-app
type: Opaque
# Option A: base64 encoded values
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=   # echo -n "password123" | base64
  API_KEY: c2VjcmV0a2V5

# Option B: plain text (K8s encodes automatically)
stringData:
  DB_PASSWORD: "password123"
  API_KEY: "secretkey"

---
# Consuming in Pod
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    envFrom:
    - secretRef:
        name: app-secret
    env:
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: app-secret
          key: DB_PASSWORD
    volumeMounts:
    - name: secret-vol
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-vol
    secret:
      secretName: app-secret

PV = actual storage provisioned by admin (NFS, EBS, HostPath). It's cluster-scoped.

PVC = user's request for storage. Pod uses PVC, not PV directly. K8s matches PVC to PV via accessModes + capacity.

Access Modes: ReadWriteOnce (RWO — 1 node), ReadOnlyMany (ROX — many nodes read), ReadWriteMany (RWX — many nodes write).
Reclaim Policy: Retain (keep data), Delete (delete on PVC delete), Recycle (deprecated).

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce          # RWO
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual   # must match PVC
  hostPath:                  # for local/dev (use NFS/EBS in prod)
    path: /mnt/data

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: my-app
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi           # request <= PV capacity
  storageClassName: manual   # must match PV

---
apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
  namespace: my-app
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: storage
      mountPath: /data
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: my-pvc      # reference PVC, not PV

A Pod is the smallest deployable unit in K8s. It wraps one or more containers that share the same network namespace and storage. Containers in a Pod communicate via localhost. Pods are ephemeral — when they die, they're gone. That's why you use Deployments/StatefulSets to manage them. Key concepts: init containers (run before app), sidecar containers (run alongside app), resource requests/limits.

apiVersion: v1
kind: Pod
metadata:
  name: full-app-pod
  namespace: my-app
  labels:
    app: myapp
    version: "1.0"
spec:
  # Init container runs first, completes, then app starts
  initContainers:
  - name: init-db-check
    image: busybox
    command: ['sh', '-c', 'until nc -z postgres-service 5432; do sleep 2; done']

  containers:
  - name: app
    image: myapp:1.0
    ports:
    - containerPort: 8080
    # Resources
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    # Env from ConfigMap + Secret
    envFrom:
    - configMapRef:
        name: app-config
    - secretRef:
        name: app-secret
    # Liveness + Readiness probes
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    volumeMounts:
    - name: storage
      mountPath: /data
    - name: config-volume
      mountPath: /etc/config

  # Sidecar container
  - name: log-shipper
    image: fluentd:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log

  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: my-pvc
  - name: config-volume
    configMap:
      name: app-config
  - name: shared-logs
    emptyDir: {}

  restartPolicy: Always   # Always | OnFailure | Never

A ReplicaSet ensures a specified number of Pod replicas are running at all times. If a pod dies, RS creates a new one. Uses a label selector to track pods.

⚠️ In practice — don't use RS directly! Use Deployment instead which manages RS and adds rolling updates + rollback capabilities. RS is the underlying mechanism Deployment uses.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: app-rs
  namespace: my-app
spec:
  replicas: 3
  selector:            # RS uses this to find/track pods
    matchLabels:
      app: myapp       # MUST match pod template labels
  template:
    metadata:
      labels:
        app: myapp     # MUST match selector
    spec:
      containers:
      - name: app
        image: myapp:1.0
        ports:
        - containerPort: 8080

A Deployment manages ReplicaSets and adds declarative updates. It's the most common workload for stateless apps. Key features: rolling updates (zero downtime), rollback, scaling, pause/resume.

Strategy types:
• RollingUpdate: gradual replacement (default) — configurable via maxSurge / maxUnavailable
• Recreate: kill all pods then create new (causes downtime)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
  namespace: my-app
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # max extra pods during update
      maxUnavailable: 0    # no downtime (0 = zero-downtime)
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: myapp:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

A StatefulSet manages stateful applications that need stable identity and persistent storage. Unlike Deployment, each pod gets:
• Sticky identity: pod-0, pod-1, pod-2 (not random names)
• Stable DNS: pod-0.service.ns.svc.cluster.local
• Per-pod PVC: via volumeClaimTemplates

Use for: databases (MySQL, PostgreSQL, MongoDB), Kafka, Zookeeper, Elasticsearch. Requires a Headless Service.

apiVersion: v1
kind: Service
metadata:
  name: mysql-headless         # Headless service for DNS
  namespace: my-app
spec:
  clusterIP: None              # Makes it headless!
  selector:
    app: mysql
  ports:
  - port: 3306

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: my-app
spec:
  serviceName: mysql-headless  # MUST reference headless service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  # Each pod gets its own PVC!
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

A DaemonSet ensures one pod runs on every node (or a subset via node selectors). When nodes are added to cluster, pods are added automatically. When nodes are removed, pods are garbage collected.

Use cases: log collectors (Fluentd, Filebeat), monitoring agents (Prometheus node-exporter, Datadog), network plugins (CNI like Calico, Weave), storage daemons.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      tolerations:             # Run on master/control-plane too
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluentd:latest
        resources:
          limits:
            memory: "200Mi"
            cpu: "100m"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

A Job runs pods to completion (not indefinitely like Deployment). It guarantees that a specified number of pods successfully terminate. Key params:
• completions: how many successful pod completions needed
• parallelism: how many pods run simultaneously
• backoffLimit: retry limit before marking job failed
• activeDeadlineSeconds: max job duration
Use restartPolicy: OnFailure or Never (not Always).

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
  namespace: my-app
spec:
  completions: 10          # total successful completions needed
  parallelism: 3           # 3 pods at a time
  backoffLimit: 4          # retry 4 times before fail
  activeDeadlineSeconds: 300  # fail if not done in 5min
  template:
    spec:
      restartPolicy: OnFailure  # OnFailure or Never (NOT Always!)
      containers:
      - name: processor
        image: python:3.9
        command: ["python", "-c", "print('Processing batch job')"]
        resources:
          requests:
            cpu: "100m"
            memory: "64Mi"

A CronJob creates Jobs on a schedule (like Linux cron). Uses standard cron syntax: * * * * * (minute hour day month weekday). Key params:
• successfulJobsHistoryLimit: keep N successful jobs (default 3)
• failedJobsHistoryLimit: keep N failed jobs (default 1)
• concurrencyPolicy: Allow | Forbid | Replace
• startingDeadlineSeconds: deadline to start if missed window

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
  namespace: my-app
spec:
  schedule: "0 2 * * *"        # Every day at 2 AM
  # schedule: "*/5 * * * *"   # Every 5 minutes
  concurrencyPolicy: Forbid    # Don't run if previous still running
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  startingDeadlineSeconds: 60  # Start within 60s of schedule or skip
  jobTemplate:                 # Job spec goes here
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: backup-tool:latest
            command: ["/bin/sh", "-c", "pg_dump -h postgres > /backup/dump.sql"]
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: backup-pvc

A Service exposes pods via a stable network endpoint. Pods come and go but Service IP stays. Uses label selectors to find target pods and kube-proxy to route traffic.

# 1. ClusterIP (default - internal only)
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  namespace: my-app
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80         # service port
    targetPort: 8080 # container port
    protocol: TCP

---
# 2. NodePort (external via node IP)
apiVersion: v1
kind: Service
metadata:
  name: app-nodeport
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080   # optional, auto-assigned if omitted (30000-32767)

---
# 3. LoadBalancer (cloud provider LB)
apiVersion: v1
kind: Service
metadata:
  name: app-lb
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

---
# 4. Headless (StatefulSet / direct pod access)
apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
spec:
  clusterIP: None   # This makes it headless!
  selector:
    app: mysql
  ports:
  - port: 3306

---
# 5. ExternalName (alias to external DNS)
apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  type: ExternalName
  externalName: my-database.rds.amazonaws.com  # no selector!

HPA automatically scales pod count based on observed metrics. Runs as a control loop (every 15s by default).

CPU-based HPA: Built-in. Uses Metrics Server. Scales when average CPU across pods crosses target %.

KEDA (Kubernetes Event Driven Autoscaler): External operator. Scales based on event sources — queue length (RabbitMQ, SQS, Kafka), cron, Prometheus metrics, etc. Can scale to 0 (saves cost). CPU HPA cannot scale to 0.

# CPU-based HPA (requires metrics-server installed)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
  namespace: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70    # scale up if CPU > 70%
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

---
# KEDA ScaledObject (scale based on queue length)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: app-keda-scaler
  namespace: my-app
spec:
  scaleTargetRef:
    name: app-deployment
  minReplicaCount: 0            # KEDA can scale to ZERO!
  maxReplicaCount: 20
  triggers:
  - type: rabbitmq
    metadata:
      host: amqp://rabbitmq:5672
      queueName: tasks
      queueLength: "5"          # 1 pod per 5 messages in queue

VPA automatically adjusts CPU and memory requests/limits for containers (vertical scaling = more resources, not more pods). It has 3 modes:
• Off: Only recommend, no auto-apply
• Initial: Apply only at pod creation
• Auto: Apply and restart pods when needed

⚠️ VPA + HPA conflict! Don't use both on same target for CPU/Memory. Use VPA for vertical, HPA for horizontal, or use HPA with custom metrics + VPA on non-conflicting resources.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
  namespace: my-app
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-deployment
  updatePolicy:
    updateMode: "Auto"    # "Off" | "Initial" | "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"   # apply to all containers
      minAllowed:
        cpu: 100m
        memory: 50Mi
      maxAllowed:
        cpu: "2"
        memory: 2Gi
      controlledResources: ["cpu", "memory"]

Taints are applied to Nodes — they repel pods that can't tolerate them.
Tolerations are applied to Pods — they allow pods to schedule on tainted nodes.

Taint effects:
• NoSchedule: New pods won't schedule. Existing pods stay.
• PreferNoSchedule: Try not to schedule (soft).
• NoExecute: Evict existing pods too (hard). Pod needs toleration or gets kicked.

⚠️ Taints/Tolerations only say "this pod CAN go to tainted node" — it doesn't FORCE it there. Use NodeAffinity for forcing.

# Taints are applied with kubectl (node level)
# kubectl taint nodes node1 gpu=true:NoSchedule
# kubectl taint nodes node1 gpu=true:NoSchedule-  (remove taint with -)

# Pod with Toleration
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"     # Equal | Exists
    value: "true"
    effect: "NoSchedule"  # NoSchedule | NoExecute | PreferNoSchedule
  # - key: "gpu"
  #   operator: "Exists"  # tolerates any value with key "gpu"
  containers:
  - name: ml-app
    image: tensorflow/tensorflow:latest-gpu

Node Affinity: PULL pods TOWARD specific nodes (based on node labels). Advanced version of nodeSelector.
• requiredDuringSchedulingIgnoredDuringExecution: Hard rule (MUST match)
• preferredDuringSchedulingIgnoredDuringExecution: Soft rule (try to match)

Pod Affinity / Anti-Affinity: Schedule pods RELATIVE to other pods.
• Affinity: "Schedule near pods with label X" (co-location)
• Anti-Affinity: "Don't schedule near pods with label X" (spread out, HA)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ha-deployment
  namespace: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      affinity:
        # NODE AFFINITY — schedule only on SSD nodes
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disk-type
                operator: In           # In | NotIn | Exists | DoesNotExist | Gt | Lt
                values:
                - ssd
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: region
                operator: In
                values: [us-east-1]

        # POD ANTI-AFFINITY — spread replicas across zones (HA!)
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: myapp             # don't schedule with other myapp pods
            topologyKey: topology.kubernetes.io/zone  # one per zone

        # POD AFFINITY — schedule near cache pods (co-location)
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: redis-cache
              topologyKey: kubernetes.io/hostname  # same node as redis

      containers:
      - name: app
        image: myapp:1.0