5 exercises — Pod lifecycle phases, Service types (ClusterIP/NodePort/LoadBalancer), RBAC (Role/ClusterRole/ServiceAccount), PV/PVC/StorageClass storage model, and Pod Security Standards.
0 / 5 completed
1 / 5
A runbook entry says: "Pod stuck in Pending state — likely a scheduling constraint or resource quota issue." What is the Kubernetes Pod lifecycle, and what does each state mean?
Kubernetes Pod lifecycle vocabulary:
Pod phases: • Pending — Pod accepted by the API server but not yet on a Node. Causes: insufficient CPU/memory on all nodes, image pull in progress, node selector / affinity rules not satisfied, PVC not bound • Running — Pod bound to a Node; at least one container is running (or starting/restarting) • Succeeded — all containers completed successfully (exit code 0); terminal state; used for Jobs • Failed — all containers have stopped; at least one exited with non-zero code or was killed; terminal state • Unknown — Pod state could not be determined; usually means the Node is unreachable
Container states within a Pod: • Waiting — not yet running (pulling image, waiting for dependencies) • Running — executing • Terminated — finished; exit code recorded
Diagnosing a stuck Pending Pod: kubectl describe pod <name> → look at the Events section for scheduler messages Common messages: "0/3 nodes are available: 3 Insufficient memory", "did not match Pod's node affinity/selector"
Advanced Pod vocabulary: • init container — runs to completion before app containers start; used for setup tasks (DB schema check, secret download) • sidecar container — runs alongside the main container in the same Pod (log shipper, proxy, secrets injector) • ephemeral container — injected into a running Pod for debugging (no restart, no probes) • restart policy — Always (default), OnFailure, Never • Pod Disruption Budget (PDB) — minimum available replicas during voluntary disruptions (node drains)
2 / 5
An architecture review asks: "Should this service use a ClusterIP, NodePort, or LoadBalancer Service?" What is the difference?
Kubernetes Service types vocabulary:
ClusterIP (default) Creates a stable virtual IP accessible only within the cluster. Used for service-to-service communication. • DNS: my-service.my-namespace.svc.cluster.local • Not reachable from outside the cluster
NodePort Extends ClusterIP by also opening a port (30000-32767) on every Node. External traffic can reach the service at <NodeIP>:<NodePort>. • Used for development/testing or on-prem without a cloud load balancer • Not production-ready for internet-facing services (exposes all nodes, requires firewall rules)
LoadBalancer Extends NodePort by also provisioning a cloud provider Load Balancer (AWS ALB/NLB, GCP Forwarding Rule, Azure Load Balancer). Gets an external IP from the cloud. • Standard for production internet-facing services • Each LoadBalancer service creates one cloud LB (can be expensive; Ingress is often preferred)
ExternalName Maps a service to a DNS name (e.g., an external database). No proxying — pure DNS CNAME.
Headless Service clusterIP: None — does not create a virtual IP. DNS returns the IPs of individual Pod endpoints. Used for stateful workloads (StatefulSet) and service discovery.
Ingress An API object that manages external HTTP/HTTPS access to services, with path-based and host-based routing, TLS termination. Requires an Ingress Controller (nginx, Traefik, AWS ALB Ingress Controller).
Vocabulary: • kube-proxy — maintains iptables rules for Service VIP routing on each Node • Endpoints / EndpointSlice — the actual Pod IPs backing a Service • NodePort range — 30000-32767 (configurable) • port / targetPort / nodePort — three port fields in a Service spec
3 / 5
A security review comments: "The application Pod should use a ServiceAccount with the minimum RBAC permissions — not the default ServiceAccount." What is RBAC in Kubernetes and why does this matter?
Kubernetes RBAC vocabulary:
RBAC controls who can do what to which resources in Kubernetes.
Core RBAC objects:
Role — grants permissions within a single namespace kind: Role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
ClusterRole — grants permissions cluster-wide (or for non-namespaced resources like Nodes)
RoleBinding — attaches a Role to a subject (User, Group, or ServiceAccount) within a namespace ClusterRoleBinding — attaches a ClusterRole cluster-wide
ServiceAccount — an identity for Pods. Every Pod runs as a ServiceAccount. Tokens are mounted automatically into the Pod filesystem at /var/run/secrets/kubernetes.io/serviceaccount/.
Subjects: • User — a human user (managed externally to Kubernetes — via certificates, OIDC) • Group — a set of users • ServiceAccount — an in-cluster identity for Pods
Principle of least privilege: Create dedicated ServiceAccounts for each application with only the permissions they need. Never use the default ServiceAccount for production workloads or bind ClusterAdmin to application ServiceAccounts.
Diagnostics: kubectl auth can-i list pods --as=system:serviceaccount:my-ns:my-sa — check what a ServiceAccount can do
Vocabulary: • verbs — allowed API actions: get, list, watch, create, update, patch, delete • resources — Kubernetes objects: pods, services, deployments, secrets, configmaps… • apiGroups — "" = core API; "apps" = Deployments; "batch" = Jobs • impersonation — acting as another user/ServiceAccount for debugging
4 / 5
A developer asks: "Why do I need a PersistentVolumeClaim if the PersistentVolume already exists?" What is the PV/PVC bind model and what does StorageClass add?
Kubernetes storage vocabulary:
PersistentVolume (PV) A cluster-level representation of physical storage. Provisioned by an admin (or dynamically by a StorageClass). Has a lifecycle independent of any Pod. Properties: capacity, access mode, reclaim policy, storage class.
PersistentVolumeClaim (PVC) A user's request for storage — specifies the size and access mode required. Kubernetes finds (or creates) a matching PV and binds the PVC to it. The Pod then mounts the PVC as a volume.
Access modes: • ReadWriteOnce (RWO) — mounted read-write by a single Node • ReadOnlyMany (ROX) — mounted read-only by multiple Nodes • ReadWriteMany (RWX) — mounted read-write by multiple Nodes (requires NFS or similar) • ReadWriteOncePod (RWOP) — mounted read-write by a single Pod (Kubernetes 1.22+)
StorageClass Defines the type of storage and enables dynamic provisioning. When a PVC references a StorageClass, the CSI (Container Storage Interface) driver creates a PV automatically.
Common StorageClasses: gp2 / gp3 (AWS EBS), standard (GCP), managed-premium (Azure)
Reclaim policy: • Retain — PV keeps data after PVC deletion; requires manual cleanup • Delete — PV and underlying storage deleted when PVC is deleted (default for dynamic provisioning) • Recycle — deprecated
StatefulSet + PVC: StatefulSets use volumeClaimTemplates to create a dedicated PVC per replica — each Pod gets its own persistent storage.
Vocabulary: • bound — PVC successfully matched to a PV • CSI driver — Container Storage Interface plugin (AWS EBS CSI, Ceph CSI, etc.) • volume snapshot — point-in-time copy of a PVC • emptyDir — temporary ephemeral storage shared between containers in a Pod; deleted when Pod terminates
5 / 5
A security audit requires: "All Pods must run as non-root and with a read-only root filesystem." The team implements a Pod Security Standard. What are the three PSS levels and what does "Restricted" enforce?
Pod Security Standards (PSS) vocabulary:
PSS replaced PodSecurityPolicy (PSP, deprecated in 1.21, removed in 1.25). Applied at the namespace level via labels — every Pod in that namespace is evaluated.
Three levels:
Privileged No restrictions. Intended for trusted system-level workloads (kernel modules, monitoring agents that need host access).
Baseline Prevents known privilege escalation techniques while remaining broadly compatible with existing workloads: • No privileged containers • No host network/PID/IPC namespaces • No hostPath volumes • Allowlisted capabilities (no AppArmor/Seccomp overrides)
Restricted Maximally hardened, following current Pod security best practices: • All Baseline restrictions + • runAsNonRoot: true — container must not run as root (UID 0) • readOnlyRootFilesystem: true — no writes to container filesystem • allowPrivilegeEscalation: false • Drop all Linux capabilities; only add specific ones if needed • Seccomp profile required (RuntimeDefault or Localhost) • runAsUser must be a high UID (not 0)
How to apply (namespace label): kubectl label namespace my-app \ pod-security.kubernetes.io/enforce=restricted \ pod-security.kubernetes.io/enforce-version=latest
Vocabulary: • runAsNonRoot — Pod security context field — container cannot run as UID 0 • readOnlyRootFilesystem — no writes to the container's root filesystem (write to tmpfs or volumes instead) • allowPrivilegeEscalation — whether a process can gain more privileges than its parent (setuid programs) • seccomp — Linux kernel syscall filter; RuntimeDefault blocks unusual syscalls • capabilities — fine-grained Linux permissions; ALL drops all; add back only what is needed