Kubernetes — Deep Dive Vocabulary

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)

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

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

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

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

Modes: enforce (reject violating Pods), audit (log violations), warn (warn but allow)

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

This scenario tests practical response in a real-time communication context. Scaling without investigation can mask underlying problems and potentially waste resources. It's crucial to understand the cause of high CPU usage before scaling, as simply adding more capacity won't fix inefficient code or resource leaks. The correct answer prioritizes a systematic approach.

This focuses on a common deployment scenario. While NodePorts *can* provide external access, they are generally considered less secure than LoadBalancers and expose your application directly to all nodes in the cluster. Using a NodePort for production is often discouraged due to potential security vulnerabilities and limited control over routing.

This explores the role of readiness probes. The 'readinessProbe' is critical for determining pod health; if it fails, the pod isn't considered ready to receive traffic. Kubernetes uses this information along with other factors (like the `rollingUpdate` strategy) to manage deployments and rollbacks effectively.

This focuses on a key scaling mechanism. The HorizontalPodAutoscaler (HPA) relies on metrics (like CPU or memory) to determine when to scale up or down. The 'metrics server' is the component that provides this information to the HPA, enabling dynamic resource adjustments for optimal performance and cost efficiency.

'imagePullBackOff' signifies that Kubernetes attempted to pull an image but failed. This most commonly happens when there's no network connection between the node and the registry or if the specified tag doesn't exist. Options B and C describe potential issues within the image itself; option D relates to resource constraints, not the pull process directly.

'FailedScheduling' errors arise when Kubernetes cannot find a suitable node to run the Pod based on its resource requests. This happens if the combined CPU and memory requests exceed what any node can offer. While CPU limitations can cause problems, it's the exceeding of *total* requested resources that triggers this specific error message.

The primary advantage of a LoadBalancer Service is its ability to seamlessly expose an application externally. This is achieved through integration with cloud providers that automatically manage routing and IP address assignment – eliminating the need for manual port mapping or configuring external IPs. Options A, C, and D describe features of other service types.

Running a Pod as 'root' means it has elevated privileges and can potentially damage the host node or compromise other applications. This significantly increases the attack surface because if one component is compromised, an attacker gains access to root-level control on the node. Best practice dictates running pods with minimal privileges – the principle of least privilege.

The PVC/PV bind model provides the most flexible and Kubernetes-native approach to persistent storage. A PVC represents the *request* for storage, while a PV is the actual storage resource (e.g., an EBS volume). This allows you to abstract away the underlying storage implementation details, making it easier to manage and scale your applications.