liveBook · Manning

SIGTERM

As explained in Kubernetes in Action, Second Edition

SIGTERM is an operating-system termination signal that requests a process to shut down gracefully.

SIGTERM is a signal asking a process to shut down. When Kubernetes needs to stop or restart a container, it normally sends SIGTERM to the container’s main process. The application can use that request to finish work and close cleanly instead of being stopped by force. section 6.3.2

If the container has a pre-stop hook, Kubernetes runs it before sending SIGTERM. The shutdown timer starts when the hook begins, or when SIGTERM is sent if there is no hook. The default termination grace period is 30 seconds. If the process is still running when that period expires, Kubernetes uses the KILL signal to stop it. section 6.3.2 section 6.4.2

Give Nginx time to finish requests

Nginx closes open connections immediately when it receives SIGTERM, potentially interrupting requests. A pre-stop hook can instead run `nginx -s quit`: Nginx stops accepting new connections, finishes in-flight requests, and then exits. section 6.3.2

Listing 6.5 Defining a pre-stop hook for Nginx
    lifecycle:       #1
      preStop:      #1
        exec:               #2
          command:          #2
          - nginx      #3
          - -s         #3
          - quit       #3

This Pod manifest fragment runs `nginx -s quit` through a container’s `lifecycle.preStop.exec.command`. section 6.3.2

An application can also handle SIGTERM itself. For example, a Node.js handler can log the signal, close its server, and exit when closing completes. If a pod takes roughly the full grace period to delete, check whether one of its processes responds to SIGTERM before shortening the deadline. section 6.4.3 section 6.5

Listing 6.7 Handling the SIGTERM signal in the kiada application
process.on('SIGTERM', function () {
  console.log("Received SIGTERM. Server shutting down...");
  server.close(function () {
    process.exit(0);
  });
});

The handler uses `process.on('SIGTERM', ...)` and exits after `server.close` calls back. section 6.4.3

When a pod is deleted, its regular containers shut down in parallel; each gets its own pre-stop hook and signal sequence. The pod’s deletion grace period controls how long they have to stop. It normally takes its value from `terminationGracePeriodSeconds`, but `kubectl delete` can override it. Kubernetes can also be configured to send a different stop signal with `lifecycle.stopSignal`. section 6.4.3 section 6.4.2

How Kubernetes in Action, Second Edition covers it

How deep it goes
Traces pre-stop hooks, signal delivery, grace-period timing, and forced termination, then shows application-side handling.
Examples
Uses an Nginx pre-stop command, a Node.js signal handler, and a slow pod deletion to make shutdown behavior concrete.
What it assumes
Uses Pod manifests and kubectl commands while defining the signal and walking through the shutdown sequence.
What you can do after
Diagnose/debug slow pod deletion and implement graceful shutdown with a SIGTERM handler or pre-stop hook.
How it connects
Connects SIGTERM to pre-stop hooks, termination grace periods, liveness probes, restart policies, and pod deletion.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.