Explain how the kubelet decides that a Kubernetes node is under resource pressure: which node conditions it sets, and the difference between its hard and soft eviction thresholds.

## The problem the kubelet is solving A node is a real machine with finite memory, disk, and process IDs. Containers can use more than they asked for. If the machine actually runs out, the Linux kernel's out-of-memory killer or a full filesystem takes down whatever it likes — possibly the container runtime or the kubelet itself, turning one bad pod into a dead node. The kubelet therefore polices the node's resources itself and reclaims them *before* the kernel has to, by killing pods. This is **node-pressure eviction**. ## Eviction signals The kubelet computes a small set of signals from cgroup and filesystem statistics: | Signal | Meaning | |---|---| | `memory.available` | Node memory available for new work (derived from the root cgroup: capacity minus working set) | | `nodefs.available` / `nodefs.inodesFree` | Free space/inodes on the filesystem holding the kubelet root — pod logs and `emptyDir` volumes | | `imagefs.available` / `imagefs.inodesFree` | Free space/inodes on the filesystem holding container images and writable layers, when the runtime uses a separate one | | `pid.available` | Free process IDs on the node | Each signal has a threshold expressed absolutely (`memory.available<500Mi`) or as a percentage of capacity (`nodefs.available<10%`). ## Hard versus soft thresholds **Hard eviction thresholds** are the emergency line. The moment an observed signal is below the threshold, the kubelet begins evicting. There is **no grace period at all**: victim pods are terminated with grace period zero, so applications do not get to flush state or drain connections. The kubelet's built-in defaults are roughly `memory.available<100Mi`, `nodefs.available<10%`, `imagefs.available<15%`, `nodefs.inodesFree<5%`. **Soft eviction thresholds** are the early-warning line, and they are opt-in. A soft threshold has three parts: 1. the threshold itself (`--eviction-soft=memory.available<1Gi`), 2. a **grace period** the breach must persist for before anything happens (`--eviction-soft-grace-period=memory.available=1m30s`), 3. an optional cap on how long victims may take to exit (`--eviction-max-pod-grace-period`). So a soft threshold gives the node a chance to recover on its own (a batch job finishes, a cache shrinks) and, if it does not, evicts pods *gracefully* — preStop hooks and SIGTERM handling run, bounded by the max grace period. A well-tuned node sets soft thresholds meaningfully above the hard ones so most reclaim is graceful and the hard line is rarely reached. ## Node conditions When a memory signal is breached the kubelet reports node condition `MemoryPressure=True`; disk and inode signals report `DiskPressure=True`; PID exhaustion reports `PIDPressure=True`. `Ready` is a separate condition about kubelet health, not pressure. These conditions feed back into scheduling. The kubelet applies matching taints — `node.kubernetes.io/memory-pressure` and `node.kubernetes.io/disk-pressure` (both `NoSchedule`) — so the scheduler stops sending new work. Memory pressure only repels **BestEffort** pods (there is a default toleration for the others), whereas disk pressure repels everything, because any new pod needs image and log space. ## Anti-flapping controls Two settings stop the node from thrashing: - **`--eviction-minimum-reclaim`** — after evicting, keep going until the signal is above the threshold *plus* this margin (e.g. `memory.available=500Mi`). Without it, a node hovering exactly at the threshold evicts one pod, dips again, evicts another, forever. - **`--eviction-pressure-transition-period`** (default 5 minutes) — the kubelet will not clear a pressure condition until the signal has been healthy for this long, which stops the taint and condition from oscillating and the scheduler from repeatedly refilling a sick node. ## Reclaim before eviction For disk signals the kubelet first tries to reclaim without touching workloads: it garbage-collects dead containers and then unused images. Only if that is not enough does it start evicting pods. For memory there is nothing to garbage collect, so eviction begins right away. ## What to say in an interview Name at least two signals, state the hard-versus-soft distinction in terms of *grace period* (0 vs configured) and *dwell time* (immediate vs must persist), name the resulting node conditions and their taints, and mention minimum-reclaim/transition-period as the reason a healthy node does not flap. That is a complete answer.