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!

Ingress manages external HTTP/HTTPS access to services in the cluster. It provides URL-based routing, SSL/TLS termination, and virtual hosting. Unlike NodePort/LoadBalancer (L4), Ingress operates at Layer 7.

Key components:
• Ingress Controller: The actual proxy (NGINX, Traefik, HAProxy) — must be installed separately
• Ingress Resource: Rules that define routing — which host/path maps to which service
• IngressClass: Selects which controller handles the resource

Gateway API is the newer replacement for Ingress — more expressive, supports TCP/UDP, and separates concerns between infra and app teams via GatewayClass → Gateway → HTTPRoute.

# Path-based routing with TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx         # which controller to use
  tls:
  - hosts:
    - myapp.example.com
    secretName: tls-secret        # kubectl create secret tls ...
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix          # Prefix | Exact | ImplementationSpecific
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

---
# Gateway API — HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: my-app
spec:
  parentRefs:
  - name: my-gateway              # references a Gateway object
  hostnames:
  - "myapp.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80

NetworkPolicy controls traffic flow at the pod level — like a firewall for pods. By default, all pods can talk to all pods (allow-all). Once you apply a NetworkPolicy selecting a pod, only explicitly allowed traffic is permitted (default-deny for selected pods).

Key concepts:
• Ingress rules: Who can send traffic TO the pod
• Egress rules: Where the pod can send traffic TO
• Selectors: podSelector, namespaceSelector, ipBlock
• Requires a CNI that supports NetworkPolicy (Calico, Cilium, Weave — NOT Flannel)

# 1. Default deny ALL ingress in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: my-app
spec:
  podSelector: {}            # empty = selects ALL pods in namespace
  policyTypes:
  - Ingress                  # no ingress rules = deny all incoming

---
# 2. Allow traffic from specific pods + namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: api-server         # apply to api-server pods
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:            # from pods with role=frontend
        matchLabels:
          role: frontend
    - namespaceSelector:      # OR from monitoring namespace
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to:                       # allow DNS
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53

CoreDNS is the cluster DNS server in Kubernetes. It provides service discovery — every Service gets a DNS name automatically.

DNS record formats:
• Service: svc-name.namespace.svc.cluster.local
• Pod: pod-ip-dashed.namespace.pod.cluster.local
• Headless: pod-name.svc-name.namespace.svc.cluster.local

CoreDNS runs as a Deployment in kube-system namespace. Config stored in a ConfigMap called coredns.

# CoreDNS Corefile (in ConfigMap coredns)
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health { laxy_start_seconds 5 }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf    # upstream DNS
        cache 30
        loop
        reload
        loadbalance
    }

---
# DNS Debug Pod
apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
spec:
  containers:
  - name: dnsutils
    image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
    command: ["sleep", "infinity"]
  restartPolicy: Always

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

RBAC controls who can do what in the cluster. It uses 4 objects:

• Role: Permissions within a namespace (verbs + resources)
• ClusterRole: Permissions cluster-wide (nodes, PVs, non-namespaced resources)
• RoleBinding: Binds a Role/ClusterRole to a user/group/SA in a namespace
• ClusterRoleBinding: Binds a ClusterRole to a user/group/SA cluster-wide

ServiceAccount: Identity for pods. Every pod runs as a ServiceAccount (default: default SA). Used to grant pods API access.

# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: my-app

---
# Role (namespace-scoped)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: my-app
rules:
- apiGroups: [""]             # core API group
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]

---
# RoleBinding — binds Role to ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: my-app
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: my-app
# - kind: User               # for user binding
#   name: jane
#   apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                  # Role or ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---
# ClusterRole (cluster-wide)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch"]

---
# ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-nodes-binding
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

---
# Pod using ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  namespace: my-app
spec:
  serviceAccountName: app-sa  # use custom SA
  containers:
  - name: app
    image: myapp:1.0

kubeadm is the official tool to bootstrap Kubernetes clusters. It handles: certificate generation, etcd setup, control plane components, kubelet configuration, and node joining.

Workflow:
1. kubeadm init on master → initializes control plane
2. Copy /etc/kubernetes/admin.conf to ~/.kube/config
3. Install CNI network plugin (Calico, Flannel, etc.)
4. kubeadm join on worker nodes with token

Cluster lifecycle management covers upgrades, etcd backup/restore, and node maintenance:

• Upgrade strategy: Upgrade control plane first, then workers one at a time. Max skew: kubelet can be 1 minor version behind API server
• etcd backup: etcd stores ALL cluster state. Take regular snapshots with etcdctl snapshot save. Critical for disaster recovery
• Node drain: Safely evict pods before maintenance. cordon = mark unschedulable, drain = cordon + evict pods

HA control plane means multiple master nodes for fault tolerance. Two topologies:

• Stacked etcd: etcd runs on each control plane node. Simpler setup, fewer servers. But if a node fails, both a control plane member and an etcd member are lost
• External etcd: etcd runs on separate dedicated hosts. Better resilience — etcd and control plane failures are independent. Needs more infrastructure

Both require a load balancer in front of API servers (HAProxy, nginx, cloud LB). Minimum 3 control plane nodes for etcd quorum (odd number required).

Helm is the package manager for Kubernetes. A Chart is a package of K8s manifests with templating. A Release is a deployed instance of a chart.

Kustomize is a template-free way to customize K8s manifests using overlays. Built into kubectl (kubectl apply -k). It patches base manifests without modifying them — great for per-environment config (dev/staging/prod).

Kubernetes uses plugin interfaces to keep the core modular:

• CNI (Container Network Interface): Network plugin that assigns IPs to pods and enables pod-to-pod communication across nodes. Examples: Calico, Flannel, Cilium, Weave
• CSI (Container Storage Interface): Storage plugin for dynamic volume provisioning. Examples: AWS EBS CSI, GCE PD CSI, NFS CSI
• CRI (Container Runtime Interface): Runtime plugin. K8s talks to CRI, which talks to the container runtime. Examples: containerd, CRI-O (Docker removed since K8s 1.24)

CNI plugins live in /opt/cni/bin/. CNI config in /etc/cni/net.d/.

CRD (Custom Resource Definition) lets you extend the K8s API with your own resource types. After creating a CRD, you can create instances (Custom Resources) just like pods or services.

Operator = CRD + custom controller. The controller watches for changes to Custom Resources and takes action (create pods, configure databases, etc.). Think of it as encoding operational knowledge into software. Examples: Prometheus Operator, cert-manager, MySQL Operator.

# Custom Resource Definition
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              schedule:
                type: string
              database:
                type: string
  scope: Namespaced
  names:
    plural: backups
    singular: backup
    kind: Backup
    shortNames:
    - bk

---
# Custom Resource (instance of the CRD)
apiVersion: stable.example.com/v1
kind: Backup
metadata:
  name: daily-db-backup
  namespace: my-app
spec:
  schedule: "0 2 * * *"
  database: "production-db"

StorageClass enables dynamic volume provisioning — PVs are created automatically when a PVC is submitted, no manual PV creation needed.

• provisioner: The CSI driver that creates the volume (e.g., kubernetes.io/aws-ebs, pd.csi.storage.gke.io)
• reclaimPolicy: Delete (default) or Retain
• volumeBindingMode: Immediate (bind PV right away) or WaitForFirstConsumer (wait until a pod uses the PVC — better for topology-aware scheduling)
• allowVolumeExpansion: Allow PVC resize

# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: pd.csi.storage.gke.io    # cloud-specific provisioner
parameters:
  type: pd-ssd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# PVC using dynamic provisioning (no manual PV needed!)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: my-app
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd       # references StorageClass
  resources:
    requests:
      storage: 20Gi

Cluster troubleshooting covers node issues, control plane components, and resource monitoring:

• Node NotReady: Check kubelet status, container runtime, network
• Control plane issues: Static pods in /etc/kubernetes/manifests/ — API server, scheduler, controller-manager, etcd
• Monitoring: kubectl top (requires metrics-server), events, component logs
• Container logs: kubectl logs, --previous for crashed containers, crictl logs for runtime-level logs

Common pod failure states:

• CrashLoopBackOff: Container starts, crashes, restarts repeatedly. Check logs: kubectl logs pod --previous
• ImagePullBackOff: Can't pull image. Wrong image name, tag, or registry auth issue
• Pending: No node can schedule the pod. Insufficient resources, no matching nodeSelector/affinity, taints blocking
• CreateContainerConfigError: Missing ConfigMap, Secret, or volume reference
• OOMKilled: Container exceeded memory limit. Increase limits or fix memory leak

Network troubleshooting covers service connectivity, DNS, and pod networking:

• Service not reachable: Check selector labels match pod labels. Check endpoints exist (kubectl get endpoints). Verify target port matches container port
• DNS issues: Check CoreDNS pods are running. Test with nslookup from a debug pod. Check /etc/resolv.conf
• Pod-to-pod issues: Check CNI plugin is installed and running. Check NetworkPolicies aren't blocking traffic
• Ingress issues: Check Ingress controller pods, IngressClass, annotations, backend service