Kubernetes Glossary – In-Depth Explanations for CKAD & CKA¶

1. Pod¶

What:
A pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share: - Network (same IP) - Storage (volumes) - Lifecycle

You don’t run containers directly in Kubernetes — you run pods.

Why:
- Every workload runs in a pod. - Even a single-container app must be in a pod. - Critical for understanding how deployments, jobs, and services work.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: web
    image: nginx

Gotchas:
- Pods are ephemeral. If a pod dies, it's gone unless managed by a controller. - Logs and filesystem are gone unless externalized (volumes or log collection).

2. ReplicaSet¶

What:
ReplicaSet ensures that N number of identical pods are running at all times. It will add or remove pods to match the desired count.

Why:
- Ensures high availability and auto-recovery. - Underpins Deployments. - CKA exam expects you to understand its role, even if you rarely define one directly.

Gotchas:
- Don't use it directly; use Deployments. - Selector mismatch = ReplicaSet won’t manage pods → no scaling.

3. Deployment¶

What:
A controller that manages ReplicaSets. Provides features like: - Rolling updates - Rollbacks - Declarative updates of app versions

Why:
- Primary way to deploy applications in Kubernetes. - Simplifies version control, scaling, and upgrades.

Gotchas:
- kubectl rollout undo reverts changes. - Don't confuse Deployment strategy (rollingUpdate or recreate) with Pod restarts.

4. StatefulSet¶

What:
A controller for stateful applications. Unlike Deployments: - Each pod gets a persistent identity (name, volume, network) - Pods are created in order, terminated in reverse

Why:
- Needed for databases, queues, apps that can't be scaled blindly. - Real-world apps like PostgreSQL, Kafka, Zookeeper rely on it.

Gotchas:
- Needs a Headless Service (clusterIP: None) - Slower to scale; pods must start one-by-one

5. DaemonSet¶

What:
Ensures that one pod runs on every (or selected) node. Useful for background agents like: - Log collectors (e.g., Fluentd) - Monitoring tools (e.g., Node Exporter)

Why:
- Critical for cluster-wide side tools. - CKAD/CKA will test it in system-level scenarios.

Gotchas:
- Doesn’t respect pod anti-affinity; you must configure it yourself. - Deleting a node = pod disappears too.

6. Job¶

What:
Runs a pod to completion (e.g., for batch jobs, scripts, one-off tasks). It will re-run the pod if it fails until it completes successfully (or reaches a failure threshold).

Why:
- Required for database migrations, cleanup tasks, report generation. - CKA often includes this in troubleshooting questions.

Gotchas:
- Will not restart if the container exits 0 unless it hasn’t reached completions.

7. CronJob¶

What:
A Job scheduled at regular intervals using cron syntax.

Why:
- Replaces external crontabs with native K8s job scheduling. - Supports history, retries, concurrency policy.

Gotchas:
- Check concurrencyPolicy: Forbid/Allow/Replace if overlapping jobs matter. - Pods may remain if history is not cleaned (successfulJobsHistoryLimit).

8. Namespace¶

What:
Virtual cluster partitioning inside a real cluster. Isolates workloads by: - Resource quota - Access permissions - Network policies (sometimes)

Why:
- Needed for multi-team environments. - Every resource (except nodes/persistent volumes) is namespaced.

Gotchas:
- Namespace deletion is slow if it contains finalizers. - Don’t assume network isolation unless policies exist.

9. Node¶

What:
A worker machine (VM or physical) in the cluster. It runs: - kubelet - container runtime (e.g., containerd) - kube-proxy

Why:
- Fundamental for understanding scheduling, affinity, failure domains.

Gotchas:
- Taints on nodes prevent pods from scheduling. - Master nodes are schedulable only if NoSchedule taint is removed.

10. Service¶

What:
A stable endpoint that abstracts access to a set of pods. It: - Load-balances traffic to healthy pods - Gets a virtual IP (ClusterIP) - Can be exposed via NodePort, LoadBalancer, or ExternalName

Why:
- The only sane way to access pods (whose IPs change). - Required for communication between apps.

Gotchas:
- No built-in health checks — relies on endpoints. - Only forwards to ready pods.

11. ConfigMap¶

What:
Used to inject non-sensitive configuration data into pods.

Why:
- Keeps code and config separate - Lets you update config without rebuilding containers

Gotchas:
- Changing a ConfigMap won’t update the pod unless it’s reloaded/restarted. - Use volume mount for live reloading only if the app supports it.

12. Secret¶

What:
Stores sensitive data like passwords and tokens in base64 format.

Why:
- Prevents secrets from being hardcoded. - Can be mounted as volumes or environment variables.

Gotchas:
- Base64 ≠ secure encryption. Use encryption at rest and limit RBAC access.

13. Init Container¶

What:
A special type of container that runs before the main application containers in a pod. It completes its task and exits before the main containers start.

Why:
- Used for initialization logic (e.g., downloading files, waiting for service readiness) - Allows separation of setup logic from app logic

Gotchas:
- If an init container fails, the pod stays in the Init phase. - Does not share process namespace with main containers.

14. Sidecar Container¶

What:
A container in the same pod as the main app, providing supporting functionality like logging, proxying, or syncing data.

Why:
- Useful for separating concerns - Common in service meshes (e.g., Envoy in Istio)

Gotchas:
- Poor coordination between sidecar and main container can cause lifecycle issues. - They share the pod’s resources and lifecycle.

15. ServiceAccount¶

What:
An identity for processes running in a pod to interact with the Kubernetes API.

Why:
- Used by pods, controllers, and tools to authenticate securely to the cluster.

Gotchas:
- Every pod gets the default service account unless you specify another. - Unused tokens may be mounted unless explicitly disabled.

16. Role / ClusterRole¶

What:
Defines a set of permissions (verbs on resources).
- Role applies to a namespace.
- ClusterRole applies cluster-wide or can be bound to namespaces.

Why:
- Core of RBAC (Role-Based Access Control)

Gotchas:
- Must match with appropriate RoleBinding or ClusterRoleBinding.

17. RoleBinding / ClusterRoleBinding¶

What:
Assigns a Role or ClusterRole to a user/group/service account.

Why:
- Grants actual permission to use a role. - Required for access control and secure multi-tenant setups.

Gotchas:
- Binding a ClusterRole to a namespace still scopes access to that namespace.

18. SecurityContext¶

What:
Defines privilege and access control settings for containers, including: - User IDs - Capabilities - Filesystem permissions

Why:
- Critical for security posture (least privilege, rootless containers)

Gotchas:
- Some settings only work if supported by the container runtime and image.

19. Liveness Probe¶

What:
Checks if the app is still running. If it fails, Kubernetes restarts the container.

Why:
- Prevents deadlocks, stuck apps from hanging indefinitely.

Gotchas:
- If misconfigured, it can cause endless restarts.

20. Readiness Probe¶

What:
Checks if the app is ready to serve traffic. If it fails, the pod is removed from Service endpoints, but not restarted.

Why:
- Prevents traffic from hitting an unready app.

Gotchas:
- Unlike liveness, it won’t restart the pod — just removes it from load balancing.

21. Startup Probe¶

What:
Used to delay the liveness and readiness probes until the app is fully started. Avoids false failures for slow-starting apps.

Why:
- Helps prevent premature restarts of large or complex apps.

Gotchas:
- Only one-time use at pod startup; not repeated like the other probes.

22. Taints and Tolerations¶

What:
- Taint on a node says “don’t schedule pods here unless they tolerate it.” - Toleration on a pod says “I can go on tainted nodes.”

Why:
- Used for dedicating nodes to certain workloads (e.g., GPU, high-memory)

Gotchas:
- No toleration = pod won't be scheduled on tainted node.

23. Affinity / Anti-Affinity¶

What:
- Controls where pods are scheduled relative to other pods. - Affinity: “prefer pods with X label” - Anti-affinity: “don’t schedule near pods with X label”

Why:
- Used for spreading or grouping apps across zones/nodes for HA or compliance.

Gotchas:
- Must be carefully defined, otherwise pods might not get scheduled at all.

24. HorizontalPodAutoscaler (HPA)¶

What:
Automatically adjusts the number of pod replicas based on CPU/memory usage or custom metrics.

Why:
- Saves resources, improves resilience under load.

Gotchas:
- Needs metrics-server to function. - Doesn’t scale to 0 — use Knative or KEDA for that.

25. Volume / PersistentVolume / PVC¶

What:
- Volume: Temporary storage for containers. - PersistentVolume (PV): A piece of persistent storage provisioned in the cluster. - PersistentVolumeClaim (PVC): A request for storage by a pod.

Why:
- Needed for data persistence across restarts.

Gotchas:
- PVC and Pod must be in the same namespace. - Reclaim policy of PV determines what happens when PVC is deleted.

26. ClusterIP / NodePort / LoadBalancer / ExternalName¶

ClusterIP (default):
Creates a virtual IP accessible only inside the cluster. Used for internal service communication.

NodePort:
Exposes the service on each Node’s IP at a specific port. Allows access from outside the cluster via NodeIP:NodePort.

LoadBalancer:
Provisions an external load balancer via cloud provider. Best for public-facing apps.

ExternalName:
Maps a service to an external DNS name. No proxying, just DNS aliasing.

Why:
- These are the core Service types. - Critical for application connectivity and external exposure.

Gotchas:
- NodePort uses a static port (30000–32767); avoid hardcoding. - LoadBalancer won’t work without cloud integration.

27. NetworkPolicy¶

What:
Defines ingress and egress rules for pod traffic. Acts like a firewall at the pod level.

Why:
- Enforces zero-trust networking in the cluster. - Required in production-grade secure environments.

Gotchas:
- No default deny unless you explicitly define it. - Depends on CNI plugin support (e.g., Calico supports it, Flannel does not).

28. CNI (Container Network Interface)¶

What:
Plugin system that Kubernetes uses to provide networking capabilities.

Why:
- Defines how pods get IPs, how routing works - Enables features like NetworkPolicy, multi-networking

Gotchas:
- K8s doesn't do networking itself—it delegates to CNI. - Not all CNIs support advanced features like NetworkPolicy or IP masquerading.

29. Ingress / Ingress Controller¶

Ingress:
Defines rules for routing external HTTP/HTTPS traffic to services in the cluster.

Ingress Controller:
Implements the ingress rules. Common options: NGINX, Traefik, Istio.

Why:
- Offers path-based and host-based routing. - Enables TLS termination, authentication, rewrites, rate limits.

Gotchas:
- Ingress rules do nothing unless an Ingress Controller is installed. - Each controller has its own annotations and behaviors.

30. DNS Resolution¶

What:
Pods and Services automatically get internal DNS records via CoreDNS.

Why:
- Enables service discovery inside the cluster. - Pods can refer to services by name like myservice.namespace.svc.cluster.local.

Gotchas:
- DNS cache can cause delays in detecting service updates. - Long hostnames can be truncated/misinterpreted in older clients.

31. StorageClass¶

What:
Defines the type of storage (e.g., SSD, HDD, NFS) and its provisioning method (manual, dynamic).

Why:
- Allows dynamic provisioning of PersistentVolumes when PVC is created.

Gotchas:
- Only one default StorageClass allowed per cluster unless explicitly defined. - ReclaimPolicy affects how volumes are handled after PVC deletion.

32. VolumeMount¶

What:
Mounts a Kubernetes Volume into a specific path in a container.

Why:
- Required for sharing config files, data, or logs with the app.

Gotchas:
- If the mount path exists, it will overwrite any existing files.

33. ReadWriteOnce / ReadWriteMany / ReadOnlyMany¶

What:
Defines volume access modes: - RWO: Mounted by one node for read/write - RWX: Mounted by multiple nodes (e.g., NFS) - ROX: Mounted read-only by many nodes

Why:
- Defines how multiple pods share data safely.

Gotchas:
- Not all volume plugins support RWX (e.g., AWS EBS doesn’t).

34. Termination Grace Period¶

What:
How long Kubernetes waits before forcefully killing a pod during shutdown.

Why:
- Gives the app time to shut down cleanly (close DB connections, flush logs)

Gotchas:
- If PreStop hook or SIGTERM handling is slow, pod can be force-killed.

35. Lifecycle Hooks¶

What:
Run specific commands at certain points in a container’s lifecycle: - PostStart: after container starts - PreStop: before container stops

Why:
- Used for setup, cleanup, draining connections

Gotchas:
- Must be quick — long-running PreStop can delay pod deletion.

36. Controller Manager¶

What:
Component that runs all built-in controllers (Deployment, Node, Job, etc.)

Why:
- Keeps the actual vs desired state in sync

Gotchas:
- If it goes down, nothing is enforced (but existing apps still run).

37. Scheduler¶

What:
Assigns pods to nodes based on resource availability, affinity rules, taints/tolerations.

Why:
- Ensures optimal use of cluster resources

Gotchas:
- If scheduling fails (e.g., no memory, taint mismatch), pods stay pending.

38. kubelet¶

What:
Agent that runs on each node and ensures the containers are running as expected.

Why:
- Core component for node management

Gotchas:
- Doesn’t communicate directly with etcd, only with kube-apiserver.

39. kube-proxy¶

What:
Maintains network rules on nodes to allow communication to/from services.

Why:
- Enables service IP routing via iptables/ipvs

Gotchas:
- Only manages Service networking — not full pod-to-pod mesh.

40. etcd¶

What:
The key-value store backing Kubernetes state (like a database for the cluster).

Why:
- Stores all objects, configurations, secrets, status, etc.

Gotchas:
- If etcd is lost and not backed up, your cluster is gone. - Should be backed up regularly and secured.

41. Admission Controllers¶

What:
Plugins that intercept requests to the Kubernetes API after authentication/authorization, and either mutate or validate them.

Why:
- Add extra enforcement or transformation - Used for security, policy, and defaults

Gotchas:
- Some are enabled by default (e.g., NamespaceLifecycle, LimitRanger) - Others like OPA Gatekeeper or PodSecurityPolicy must be explicitly configured

42. PodSecurityPolicy (Deprecated)¶

What:
Legacy method to enforce pod-level security controls (e.g., no root, restricted volumes).

Why:
- Deprecated in Kubernetes 1.21+ in favor of PodSecurity Admission

Gotchas:
- Deprecated and removed in 1.25 — don’t use for new deployments.

43. PodSecurity Admission¶

What:
Replacement for PodSecurityPolicy. Applies security profiles (restricted, baseline, privileged) using labels.

Why:
- Much easier to use than PSP - Enforces consistent security policies

Gotchas:
- Must label namespaces for it to take effect. - Does not mutate pods — only validates.

44. Audit Logs¶

What:
Records of who did what in the Kubernetes API server.

Why:
- Essential for compliance, forensics, and debugging

Gotchas:
- Needs to be explicitly configured via audit policy file - Logs can be large — offload to log aggregator

45. Metrics Server¶

What:
Collects resource usage metrics like CPU and memory from kubelets.

Why:
- Required for HPA (HorizontalPodAutoscaler) - Enables real-time monitoring of pod and node resource usage

Gotchas:
- Not installed by default - Doesn’t persist metrics (for that, use Prometheus)

46. Debug (Ephemeral Containers)¶

What:
Temporary container injected into a running pod for debugging (without restarting it).

Why:
- Lets you debug broken containers that don’t have a shell or CLI tools

Gotchas:
- Must enable the EphemeralContainers feature gate in older clusters - Doesn’t support networking outside the pod

47. exec¶

What:
Runs a command inside a running container.

Why:
- Crucial for debugging, health checks, quick fixes

Gotchas:
- Needs shell access in the container - Doesn’t persist; only for interactive use

48. Port-forward¶

What:
Forwards a port from your local machine to a pod in the cluster.

Why:
- Lets you access services/pods without exposing them publicly

Gotchas:
- Only lasts while the command is active - Useful for debugging, not production use

49. Describe¶

What:
Displays detailed state of a Kubernetes resource, including status, events, configuration.

Why:
- Primary tool for debugging stuck, crashing, or pending pods

Gotchas:
- Verbose output — search with grep or less

50. Logs¶

What:
Shows stdout/stderr logs of a container in a pod.

Why:
- First place to look when troubleshooting a crashing or misbehaving container

Gotchas:
- Only works for currently or recently running containers - Doesn’t capture app-level logging unless redirected to stdout

51. Recreate Strategy¶

What:
Deployment strategy that kills all old pods before starting new ones.

Why:
- Use when old and new versions can't coexist (e.g., DB schema changes)

Gotchas:
- Downtime during rollout

52. RollingUpdate Strategy¶

What:
Default strategy that updates pods gradually to avoid downtime.

Why:
- Smooth deployments without service interruption

Gotchas:
- Misconfigured probes can delay rollout

53. VerticalPodAutoscaler (VPA)¶

What:
Adjusts resource requests (CPU/mem) for pods automatically based on usage.

Why:
- Avoids over/under-provisioning - Complements or replaces manual tuning

Gotchas:
- Doesn’t work with HPA on same deployment - Restarts pods when applying changes

54. Deployment Revision History¶

What:
Tracks version history of deployment changes for rollback.

Why:
- Enables kubectl rollout undo

Gotchas:
- Limited by revisionHistoryLimit

55. Canary Deployment¶

What:
Releases a new version to a subset of users or pods for testing.

Why:
- Safer releases, early detection of bugs

Gotchas:
- Needs proper monitoring and rollback plan

56. Blue-Green Deployment¶

What:
Runs two parallel environments (blue = old, green = new). Switch traffic only when ready.

Why:
- Instant switch between versions - Easy rollback

Gotchas:
- Expensive (double resources) - More complex to orchestrate in Kubernetes without tooling

57. Helm¶

What:
Kubernetes package manager. Uses charts (templated YAML files) to deploy and manage apps.

Why:
- Simplifies deployment of complex apps - Supports versioning, upgrades, config overrides

Gotchas:
- Requires understanding templating and values.yaml - Can abstract too much, hiding important details

58. kubeadm¶

What:
Tool to bootstrap Kubernetes clusters. Handles control plane init, node join, certificates.

Why:
- Fastest way to set up a K8s cluster manually

Gotchas:
- Doesn’t install CNI plugin - Requires extra setup for production hardening

59. Custom Resource Definitions (CRD)¶

What:
Extends the Kubernetes API to allow custom resources like KafkaCluster, RedisOperator, etc.

Why:
- Powers tools like Prometheus, Cert-Manager, ArgoCD

Gotchas:
- Must define schema properly - Not validated unless OpenAPI schema is included

60. Operator¶

What:
Custom controller that manages an app using CRDs. Encodes operational knowledge (like backup, failover).

Why:
- Automates management of complex, stateful apps

Gotchas:
- Writing your own is complex - Existing operators can be buggy if not well maintained

78. Resource Requests vs Limits (continued)¶

What:
- Request: minimum guaranteed resources for scheduling - Limit: maximum resources a container can use

Why:
- Ensures fair sharing and prevents resource exhaustion

Gotchas:
- Over-requesting wastes resources, under-requesting causes evictions

79. Eviction¶

What:
When the kubelet removes a pod from a node due to resource pressure (CPU, memory, disk).

Why:
- Protects node stability

Gotchas:
- Not the same as graceful deletion — can be sudden and disrupt services

80. Event¶

What:
System-generated record for state changes (e.g., pod created, image pull failed).

Why:
- Critical for debugging and visibility

Gotchas:
- Events are ephemeral; use log collectors to persist

81. Label¶

What:
Key-value pair attached to objects for identification.

Why:
- Enables selectors, groupings, filters

Gotchas:
- Labels must be unique per key; overuse can make selection inefficient

82. Annotation¶

What:
Key-value metadata for attaching non-identifying information to resources.

Why:
- Used for tooling, debugging, versioning, etc.

Gotchas:
- Not used in selectors — for humans and systems, not filters

83. Selector¶

What:
Mechanism for targeting Kubernetes resources via label match.

Why:
- Used by ReplicaSets, Services, NetworkPolicies, etc.

Gotchas:
- MatchLabels and MatchExpressions must match actual pod labels

84. Field Selector¶

What:
Targets resources based on resource field values (e.g., metadata.name).

Why:
- Enables precise filtering for imperative commands

Gotchas:
- Limited to built-in fields

85. taint-based Eviction¶

What:
Evicts pods from nodes when taints are dynamically applied due to resource pressure.

Why:
- Used in node lifecycle and autoscaling

Gotchas:
- Needs tolerations to avoid unwanted eviction

86. Static Pod¶

What:
Pod defined directly in kubelet via a manifest file on the node.

Why:
- Used for core components (e.g., etcd, kube-apiserver)

Gotchas:
- Not managed by Kubernetes API — shows up as mirror pod

87. Mirror Pod¶

What:
Read-only representation in API server of a static pod on a node.

Why:
- Provides visibility into static pod state

Gotchas:
- Cannot be deleted from API — delete the static pod file

88. Job BackoffLimit¶

What:
Maximum number of retries for failed Jobs before being marked failed.

Why:
- Controls job failure policy

Gotchas:
- Set too low = premature failure, too high = retry loops

89. CronJob ConcurrencyPolicy¶

What:
Specifies how to handle multiple CronJob runs: - Allow: run in parallel - Forbid: skip if previous is running - Replace: stop previous, run new

Why:
- Prevents overlapping jobs where unsafe

Gotchas:
- Default is Allow — can cause conflict

90. Terminating Pod¶

What:
A pod in the process of shutting down (due to delete or node eviction).

Why:
- Allows graceful cleanup, PreStop hooks, draining

Gotchas:
- Stuck in Terminating often means volume or finalizer issues

91. CrashLoopBackOff¶

What:
State when a container fails and Kubernetes waits exponentially longer to restart it.

Why:
- Indicates app bug, misconfig, or readiness probe failure

Gotchas:
- Often confused with LivenessProbe killing the pod — check logs

92. InitContainers Completed / Pending¶

What:
Pods don’t run main containers until all initContainers finish.

Why:
- Useful for dependency checks (e.g., DB readiness)

Gotchas:
- If one fails, pod will hang forever in Init state