Kubernetes and Container Orchestration Flashcards

What is the purpose of a Kubernetes 'liveness probe,' and how does it differ from a 'readiness probe'?

Answer: A liveness probe restarts a container that has deadlocked; a readiness probe removes a container from load balancer rotation when it cannot serve traffic

Liveness probes detect deadlocked or corrupted container states and trigger a restart. Readiness probes detect temporary unavailability (e.g., loading config) and temporarily remove the pod from service endpoints without restarting it.

A Kubernetes Deployment has 3 replicas. During a rolling update, what is the effect of setting maxSurge=1 and maxUnavailable=0?

Answer: At most 4 pods run simultaneously during the update (3 original + 1 new), and no pods are terminated until a new one is healthy — ensuring continuous availability

maxSurge=1 allows 1 extra pod above the desired count (4 total), maxUnavailable=0 ensures no reduction in available pods. New pods must become ready before old ones are terminated, guaranteeing zero downtime during the rollout.

What is a Kubernetes PodDisruptionBudget (PDB) and when is it essential?

Answer: A PDB specifies the minimum number or percentage of pods that must remain available during voluntary disruptions like node drains, cluster upgrades, or maintenance

A PodDisruptionBudget ensures that voluntary disruptions (like kubectl drain during a node upgrade) do not bring down too many pods simultaneously, preventing inadvertent downtime during maintenance operations.

In Kubernetes, what is the difference between a ConfigMap and a Secret, and what are the security implications?

Answer: ConfigMaps store non-sensitive configuration data as plain text; Secrets store sensitive data base64-encoded (not encrypted by default), and should be protected with RBAC, encryption at rest, and preferably external secret managers

ConfigMaps are for non-sensitive configuration; Secrets are for sensitive data but are only base64-encoded (not encrypted) by default in etcd. Proper secret security requires encryption at rest, RBAC restrictions, and ideally external secret management systems.

What does Kubernetes horizontal pod autoscaling (HPA) do, and what metric is it MOST commonly configured to use?

Answer: HPA automatically adjusts the number of pod replicas based on observed metrics (most commonly CPU utilization), scaling out when demand increases and in when it decreases

HPA watches metrics (default: CPU utilization as a percentage of the CPU request) and scales the number of replicas up or down to maintain the target metric value. It is the primary autoscaling mechanism for request-driven workloads.

A microservice running in Kubernetes is experiencing intermittent OOMKilled events. What is the MOST appropriate first response?

Answer: Analyze memory usage patterns using profiling tools to identify memory leaks or excessive allocation, then set appropriate memory limits and requests based on observed usage

OOMKilled events indicate the container exceeded its memory limit. The correct approach is to investigate whether the limit is too low for legitimate usage or whether there is a memory leak, then set limits based on profiled actual usage.