You delete a running Pod with kubectl delete pod and an equivalent Pod appears seconds later. Explain the mechanism that recreated it, and why Kubernetes controllers are described as level-triggered rather than edge-triggered.

## What actually recreated the pod A Deployment does not manage pods directly. It manages ReplicaSets; a ReplicaSet declares "there should be N pods matching this label selector". The ReplicaSet controller runs a loop: list the pods matching the selector, compare the count with spec.replicas, and create or delete the difference. Your `kubectl delete pod` simply removed one object; the very next pass observed 2 where 3 were wanted and created a replacement. The new pod is not the old one restored — it is a fresh pod with a new name, new IP, and empty ephemeral storage. The same mechanism explains node failure recovery: when a node goes away, its pods eventually leave the observed set, the count drops, and replacements are created elsewhere. Nothing special-cased "node failure"; the count was simply wrong. ## Edge-triggered versus level-triggered The terms come from hardware interrupts. **Edge-triggered** means acting on transitions. The logic is "when X happens, do Y." It is efficient, but it is only correct if you observe every transition. Miss one — a dropped message, a process restart, a watch that expired — and the system is permanently wrong, because nothing will tell you again. It also forces you to keep internal state to interpret each edge. **Level-triggered** means acting on the current value. The logic is "whatever happened, here is what I want and here is what exists; close the gap." Duplicate signals are harmless (the second pass finds no gap), missed signals only delay convergence, and a controller that restarts with zero memory behaves correctly immediately because it re-reads the world. ## How Kubernetes combines both A well-written controller is triggered by edges but reasons on levels. Watch events (and periodic resyncs) merely enqueue a key — usually just "namespace/name", with the event payload discarded. The reconcile function then fetches the current object and the current related objects, computes the delta, and acts. This gives the responsiveness of events with the robustness of polling. Several important properties follow: - **Idempotency is required.** Reconcile may run many times for one change — duplicate events, resyncs, retries after error. Running it twice must be the same as running it once. - **Reconcile must not assume it knows why it was called.** It gets a key, not a story. Any logic of the form "this must be a delete because…" is a bug. - **Convergence is eventual, not instantaneous.** Between the delete and the replacement there is a real gap where capacity is reduced. Level-triggering guarantees you get there, not that you were never wrong. - **Errors are handled by requeueing**, typically with rate-limited exponential backoff, rather than by aborting. ## Where self-healing stops Self-healing only covers objects a controller owns. A bare Pod created directly, with no ReplicaSet, Job, or StatefulSet above it, has no controller watching its count — delete it and it stays gone. Likewise, if you edit a managed pod's image in place, the ReplicaSet does not correct it, because its selector-and-count contract is satisfied; only pod-template changes at the Deployment level roll pods. Understanding what each controller actually compares tells you exactly what it will and will not fix.