When Kubernetes needs to stop a container (a liveness probe failed, the pod was deleted, a rollout is happening), the kubelet sends a SIGTERM to the container's main process, the one running as PID 1. If that process has no handler for SIGTERM, it ignores it, so the kubelet waits for the grace period (30 seconds by default) and then sends a SIGKILL.

That's bad in two ways. First, every restart triggered by a probe is delayed by those 30 seconds. Second, a badly configured liveness probe makes it worse: if the probe fails while the application is still starting, the kubelet has already decided to kill it. Since the process ignores the SIGTERM, it keeps starting during the grace period and may even begin serving requests, but the SIGKILL comes anyway, because the kubelet doesn't check the container's health again. The result is an application that starts, serves for a few seconds, and gets killed in the middle of its work.

I ran into this in my lab while testing probes on a FastAPI app with 2 replicas on a kind cluster.

The liveness probe starts checking the moment the container starts, and one failure is enough to restart it. There's no startup probe to give the app time to boot.

This is already the right form (the exec form), so uvicorn is PID 1 and gets signals directly. But Python doesn't install a SIGTERM handler by default, and uvicorn only installs its own after it has loaded. Until then, PID 1 has no handler.

One of the two replicas:

The container restarts every ~32 seconds, and after each restart it's Ready (1/1) in about 4 seconds, serving traffic normally until the next kill. Each cycle looks like this:

Both replicas were created at the same time, so they died together, and my load generator saw about 2 seconds of failed requests in every cycle.

For comparison, when I deleted one of these pods after it had fully started, it ended as Completed (exit code 0): uvicorn's handler was already installed, so it shut down cleanly.

Every signal has a default action, and for SIGTERM it's "terminate". If a process doesn't install a handler, the kernel applies the default action and the process dies.

PID 1 is the exception. On Linux, PID 1 is the init process, and if it died from a stray signal the whole system would go down. So the kernel protects it: a signal that PID 1 has no handler for is simply dropped. Only SIGKILL and SIGSTOP can't be ignored, which is why the SIGKILL works after 30 seconds.

Each container has its own PID namespace, so its main process becomes the PID 1 of that namespace and inherits this protection, even though it was never written to be an init process. In my case, the SIGTERM arrived during boot, before uvicorn had installed its handler, and the kernel dropped it.

And the liveness probe is what started it all: it fired while the app was still booting, so every cycle repeats the same story.

There are two problems, so there are two fixes.

tini is a tiny init process made for containers. It runs as PID 1, starts your app as its child, forwards the signals it receives, and exits with the app's exit code.

Now uvicorn is a regular process, so the special rule no longer applies: a SIGTERM during boot kills it immediately (the default action), and after boot its own handler shuts it down cleanly. No more 30-second wait.

Lowering terminationGracePeriodSeconds is not a fix: it only shortens the wait, still ends in a SIGKILL, and takes time away from clean shutdowns.

While the startup probe is running, the liveness and readiness probes are disabled. Once it passes, the liveness probe takes over. This was the real cause of the loop: a liveness probe with no startup probe, checking from second zero and restarting on the first failure. It's a common mistake, and now it's easy to recognize: restarts at a fixed interval of about 30 seconds plus your boot time.

The same happens on Amazon EKS, since it's the same kubelet behavior, and on Amazon ECS, where the default stop timeout before the SIGKILL is also 30 seconds. On ECS you don't even need to change the image: setting initProcessEnabled: true in the task definition's linuxParameters runs an init process as PID 1 for you, just like tini.