DevOps

Kubernetes Study Portal

Container orchestration, deployments, services, networking
Flash Cards Practice
DevOps / Kubernetes / Core Concepts / Quick recall Q&A

Core Concepts · Quick recall Q&A

4 min read
Foundational6 min read
Rapid overview

Quick recall Q&A

Q: What is a Pod and why is it the smallest deployable unit in Kubernetes? A: A Pod is a group of one or more containers that share the same network namespace (localhost), storage volumes, and lifecycle. It is the smallest deployable unit because Kubernetes schedules and manages at the Pod level, not the individual container level. Pods are ephemeral by design -- they are meant to be replaced, not repaired.
Q: What are the common multi-container Pod patterns? A: The three main patterns are: sidecar (adds functionality like log shipping or proxying alongside the main container), ambassador (proxies network connections on behalf of the main container, e.g., to a database), and adapter (transforms the main container's output into a standardized format, e.g., for monitoring). Init containers also run before app containers to perform setup tasks.
Q: How does a Deployment manage rolling updates? A: A Deployment creates a new ReplicaSet with the updated Pod template and gradually scales it up while scaling down the old ReplicaSet. The maxSurge parameter controls how many extra Pods can exist above the desired count, and maxUnavailable controls how many Pods can be unavailable during the update. You can roll back with kubectl rollout undo if something goes wrong.
Q: What are the four Kubernetes Service types and when would you use each? A: ClusterIP (default) exposes the service on an internal cluster IP for inter-service communication. NodePort exposes the service on a static port on each node's IP, useful for development. LoadBalancer provisions an external cloud load balancer for production external access. ExternalName maps the service to an external DNS name for integrating with services outside the cluster.
Q: How do ConfigMaps and Secrets differ, and what are the best practices for each? A: ConfigMaps store non-sensitive configuration data as key-value pairs, while Secrets store sensitive data (passwords, tokens, keys) with base64 encoding. Both can be consumed as environment variables or mounted as files. Best practices: use Secrets for anything sensitive, integrate external secrets managers (Vault, AWS Secrets Manager) for production, use RBAC to restrict Secret access, and prefer volume mounts over environment variables since env vars can leak into logs and child processes.
Q: What are liveness, readiness, and startup probes, and when should you use each? A: Liveness probes detect if a container is stuck or deadlocked -- kubelet restarts the container if the probe fails. Readiness probes determine if a container is ready to accept traffic -- failing containers are removed from Service endpoints. Startup probes run once during container startup for slow-starting apps, disabling liveness/readiness checks until the app is initialized. Use liveness for crash recovery, readiness for load balancing, and startup for applications with long initialization times.
Q: What are Kubernetes namespaces and how do they help manage a cluster? A: Namespaces provide logical isolation within a cluster, allowing you to partition resources by team, environment (dev/staging/prod), or application. They scope resource names (avoiding collisions), enable per-namespace ResourceQuotas and LimitRanges to control resource consumption, and support RBAC policies for access control. Default namespaces include default, kube-system, kube-public, and kube-node-lease.
Q: What happens when a node fails in a Kubernetes cluster? A: The controller manager detects the failure via kubelet heartbeat timeout (default 40s). After the pod-eviction-timeout (default 5 minutes), pods on the failed node are marked as Terminating. The ReplicaSet controller detects the desired replica count is not met and creates replacement pods. The scheduler places those new pods on healthy nodes based on resource availability and constraints.
Q: How does Kubernetes service discovery work? A: Kubernetes provides DNS-based service discovery through CoreDNS. Every Service gets a DNS entry in the format <service-name>.<namespace>.svc.cluster.local that resolves to the Service's ClusterIP. Pods can also discover services via environment variables injected at startup (legacy approach). Headless services (ClusterIP: None) return individual Pod IPs instead, useful for StatefulSets.
Q: Explain the difference between a Deployment and a StatefulSet. A: Deployments manage stateless applications where pods are interchangeable, can scale in parallel, and use random names (e.g., nginx-abc123). StatefulSets manage stateful applications requiring stable, unique network identifiers (pod-0, pod-1, pod-2), persistent storage tied to each pod, and ordered graceful deployment, scaling, and rolling updates. Use Deployments for web servers and APIs; use StatefulSets for databases and distributed systems like Kafka or Elasticsearch.

See also