K8S — Interview Questions I

series on common K8s questions

Part I | Part II

In a cluster with two nodes, one with pods and the other without, which node will a new pod be scheduled to?

A new pod will likely be scheduled to the node without pods, assuming both nodes have sufficient resources (CPU, memory, etc.) and no taints, tolerations, or affinity rules are in place. The Kubernetes scheduler prioritizes spreading pods across nodes for high availability and resource balancing. If the empty node is tainted or lacks resources, the pod may be scheduled on the node with existing pods or remain unscheduled.

Factors affecting pod placement on Node:

• Hardware capabilities
• Available resources (PodFitsResources, PodFitsHost, PodFitsHostPorts, PodSelectorMatches, NoDiskConflict)
• Quality of service (BestEffort, Burstable, Guaranteed)
• Node Selectors
• Node Affinity and Anti-Affinity
• Pod Affinity and Anti-Affinity
• Taint Toleration
• Resource Quotas

If an application running in a container encounters an OOM (Out-of-Memory) error, will the container restart, or will the entire Pod be recreated?

If a container encounters an Out-of-Memory (OOM) error, Kubernetes will terminate the container and restart it within the same pod, provided the pod’s restartPolicy is set to Always or OnFailure (default is Always). The entire pod is not recreated unless the pod itself is deleted or evicted. The container’s state is reset, but other containers in the same pod (if any) are unaffected.

Can application configurations such as environment variables or ConfigMap updates be applied dynamically without recreating the Pod?

Environment variables defined in a pod’s spec cannot be updated dynamically without recreating the pod. However, if the variables are sourced from a ConfigMap or Secret, updating the ConfigMap/Secret will reflect changes in the pod only if the application is designed to reload configurations dynamically or the pod is restarted. For volume-mounted ConfigMaps/Secrets, changes propagate to the pod without recreation, but the application must handle reloading the updated files.

Note there are custom solutions like reloader that does this.

Is a Pod stable once created, even if the user takes no further action?

A pod is stable once created, provided no external actions (e.g., user deletion, node failure, or eviction) or internal issues (e.g., container crashes, OOM errors) occur. Pods are ephemeral by design, so while stable under normal conditions, they can be terminated by cluster events like node draining, resource pressure, or scaling operations.

Can a Service of type ClusterIP ensure load balancing for TCP traffic?

Yes, a Service of type ClusterIP ensures load balancing for TCP traffic across pods matching the service’s selector. The kube-proxy component handles this by distributing traffic (using round-robin by default) to the backend pods via iptables or IPVS, ensuring even distribution for TCP-based applications.

How should application logs be collected, and is there a risk of losing logs?

Application logs should be collected using a logging agent like Fluentd, Fluent Bit, or Filebeat, deployed as a DaemonSet to run on every node. These agents forward logs from pod containers (via stdout/stderr or log files) to a centralized system like Elasticsearch, Loki, or a cloud-based logging service. Risk of log loss: Logs can be lost if the container crashes before logs are collected, the node fails, or the logging pipeline is disrupted. To mitigate, use sidecar containers for log streaming or configure persistent storage for logs.

If an HTTP Server Pod’s livenessProbe is functioning correctly, does it mean the application is problem-free?

A functioning livenessProbe indicates that the pod’s container is running and responding to the probe (e.g., HTTP endpoint returns 200). However, it does not guarantee the application is problem-free. The probe only checks the defined health check (e.g., an HTTP endpoint), not the application’s internal logic, database connectivity, or performance issues. Additional monitoring (e.g., metrics, logs) is needed to ensure overall health.

How can an application scale to handle traffic fluctuations?

To handle traffic fluctuations, use:

• Horizontal Pod Autoscaler (HPA): Automatically scales the number of pods based on metrics like CPU/memory usage or custom metrics (e.g., requests per second).
• Vertical Pod Autoscaler (VPA): Adjusts pod resource requests/limits dynamically (best for non-disruptive scaling).
• Cluster Autoscaler: Adds/removes nodes based on resource demands.
• LoadBalancer/ClusterIP Services: Distribute traffic across scaled pods.
  Configure appropriate resource limits and use metrics from Prometheus or similar to drive scaling decisions.
• KEDA extends Kubernetes autoscaling by enabling event-driven scaling for workloads that react to external events, such as 1. Queue-based systems 2. External metrics 3. Custom event sources 4. Scaling based on triggers like cron schedules, or Prometheus metrics.

When you execute kubectl exec -it <pod> — bash, are you logging into the pod?

You are not logging into the pod itself but into a specific container within the pod. A pod is a logical grouping of one or more containers, and kubectl exec runs a command (e.g., bash) inside the default or specified container. If the pod has multiple containers, you must specify the container using -c <container-name>.

How would you troubleshoot if a container in a Pod repeatedly exits and restarts?

To troubleshoot a container that repeatedly exits and restarts:

• Check pod status: Use kubectl describe pod <pod> to see events, exit codes, and reasons (e.g., CrashLoopBackOff).
• Inspect logs: Run kubectl logs <pod> [-c <container>] to view application or error logs.
• Verify exit code: Exit codes (e.g., 137 for OOM, 1 for app error) indicate the issue. Use kubectl describe pod to find the code.
• Check resource limits: Ensure CPU/memory limits are sufficient; OOM errors occur if limits are too low.
• Validate container image: Confirm the image tag, command, and entrypoint are correct. Pull errors or misconfigured commands can cause exits.
• Inspect configs: Verify environment variables, ConfigMaps, or Secrets are correctly set.
• Debug interactively: If possible, use kubectl exec to run a shell and investigate inside the container.
• Review application code: Look for crashes due to unhandled exceptions or misconfigurations.
• Enable probes: Add or adjust livenessProbe/readinessProbe to detect and recover from issues.
• Monitor metrics: Use tools like Prometheus to check for resource exhaustion or abnormal behavior.