Kubernetes Deep Dive: QoS, Eviction, HPA, Probes, and Sidecars

FAUN.dev() is where engineers from GitHub, Netflix, and Shopify go to stay ahead — fast.

An effortless, straightforward way to keep up with technologies...so you can keep your tabs closed and your mind open!

70,000+ developers already joined our ecosystem ⭐⭐⭐⭐⭐
Trusted by engineers at:

Google • Microsoft • AWS • Netflix

Take the quiz

Your score will show up right here.

Kubernetes Deep Dive: QoS, Eviction, HPA, Probes, and Sidecars

An advanced 10-question quiz on Kubernetes internals and runtime behavior, aimed at practitioners who run clusters in production. It targets the subtle traps: QoS assignment rules, OOM-kill vs eviction, whether node-pressure eviction honors PodDisruptionBudgets, the exact HPA scaling formula and what utilization is measured against, native sidecars vs init containers, startup/liveness/readiness probe interaction, and StatefulSet ordering guarantees.

Which condition causes Kubernetes to assign a Pod the Guaranteed QoS class?

At least one container in the Pod sets a memory limit equal to its memory request.
Every container in the Pod sets both CPU and memory requests and limits, and for each resource the request equals the limit.
The Pod sets a high-value priorityClassName, which the scheduler maps to Guaranteed.

A container in a Guaranteed Pod exceeds its memory limit. What happens?

The kernel OOM-kills the container (exit code 137) and it restarts per the Pod's restartPolicy; Guaranteed QoS does not protect against this.
Nothing immediate, since Guaranteed Pods are evicted last, so it keeps running until the node reclaims memory.
The container is CPU-throttled until its memory usage drops back below the limit.

During node-pressure eviction, how does the kubelet treat PodDisruptionBudgets (PDBs)?

It always honors them, delaying eviction until doing so would not violate any PDB.
It honors them only for Pods in the Guaranteed QoS class.
It ignores them entirely; PDBs are respected only by API-initiated (voluntary) eviction, such as kubectl drain.

A Deployment has 3 replicas averaging 90% CPU utilization against an HPA target of 50%. Using the standard HPA algorithm, what is the desired replica count?

When an HPA uses a CPU utilization target, what is that percentage measured against?

The container's CPU request.
The container's CPU limit.
The node's total allocatable CPU.

How is a native sidecar container (as opposed to a plain sidecar) defined in a Pod spec?

As a regular entry under spec.containers that sets the field sidecar: true.
As an entry under initContainers with restartPolicy: OnFailure.
As an entry under initContainers with restartPolicy: Always, enabled by default since v1.29; unlike ordinary init containers it supports probes and runs for the Pod's whole lifetime.

While a container's startup probe is configured but has not yet succeeded, what does the kubelet do with that container's liveness and readiness probes?

It runs all three probes concurrently from the moment the container starts.
It does not run the liveness or readiness probes at all until the startup probe first succeeds.
It runs the readiness probe but suspends only the liveness probe.

A running container's readiness probe begins failing while its liveness probe keeps passing. What is the effect?

The Pod is removed from its Service's endpoints so it stops receiving traffic, but the container is not restarted.
The container is killed and restarted, since a failing probe always triggers a restart.
The entire Pod is evicted from the node and rescheduled elsewhere.

Which statement about regular init containers (not sidecar containers) is correct?

They run in parallel with one another to speed up Pod startup.
They keep running alongside the main container for the Pod's whole lifetime.
They cannot define liveness, readiness, or startup probes; the API server rejects such a spec during validation.

For a StatefulSet with 3 replicas using the default settings, which behavior is guaranteed?

Pods are created in parallel, exactly as a Deployment creates its replicas.
Pods are created one at a time in order (ordinal 0, then 1, then 2), each becoming Running and Ready before the next is started, and a headless Service is required to give them stable network identities.
Pods receive randomized names and IP addresses that are reassigned on every restart.