How to use SIGKILL to rapidly terminate containers in Kubernetes

Originating from Linux, which uses a Unix operating system, SIGKILL is a common command that developers use to terminate absolutely any process. Most commonly, if anything needs to be shut down immediately as it's causing damage to the system itself, then SIGKILL is the go-to signal to use.

Alongside Linux, SIGKILL has also found itself into any developer platform that manages container systems, with the most popular example of this being Kubernetes. As one of the most drastic signals that you can execute, SIGKILL will instantly terminate a process, without giving the system the opportunity to block or ignore the signal. With this, absolutely any processes that are connected to the process you’ve killed will also terminate.

In the rare case that SIGKILL doesn’t totally terminate a process, your console will return a whole operating system error, which could reveal you have a much more difficult problem on your hands to solve.

While this is a useful signal to know and use on occasion, it doesn't give processes any time to clean up their operations, which can result in the loss of data, corruption, or major errors within your system. With this in mind, Kubernetes has created another signal, known as SIGTERM, which gives any containers that you want to terminate the opportunity to close down efficiently, helping to preserve data and prevent corruption.

How Does SIGKILL Work in Kubernetes?

When you need to shut down an application, Kubernetes has a range of processes in place that will help you do so efficiently, without completely messing up your internal environment. This is known as a 'Graceful Shutdown', and uses the two-step punch of SIGTERM and SIGKILL.

There are typically three steps to shutting down your Kubernetes pod with these commands:

1. Use SIGTERM -- The first step when shutting your pod should always be to give it a chance to shut down properly. SIGTERM initiates this process within each container, giving pods 30 seconds of time to then shut down gracefully, saving all of their data and ensuring everything is in order. Depending on your specific application and its purpose, you could change SIGTERM to give pods more or less time, depending on how much data they each handle, or how urgent the shutdown is.
2. SIGTERM Terminate -- Once a container receives the executed SIGTERM signal, it will begin to shut down. Once all the data is saved, it will then shut down by itself. For many pods and clusters, this will be the final step, having successfully closed.
3. Unresponsive and SIGKILL -- If the container doesn’t shut down within the 30-second period that SIGTERM supplies it with, your Kubernetes ecosystem will then automatically send the SIGKILL signal. This signal will instantly close the container, shutting all of its connected processes. This will, for 99 percent of the time, close anything that you need within your ecosystem. That said, it’s incredibly violent and can cause any number of corruption issues.

When Should I Not SIGKILL in Kubernetes?

SIGKILL, while incredibly effective at terminating processes, is one of the most brutal things you can do within the Kubernetes environment. Instantly closing a process means that you won’t know exactly what the process was doing, how far along it was, or any other information about the data it was handling.

Most of the time, if a container is having trouble shutting, it is because it’s currently under a lot of strain, juggling many processes at once. With this considered, using SIGKILL may damage your ecosystem to quite a large extent, instantly impacting your future productivity.

Due to this, we always recommend that you use SIGTERM within Kubernetes before SIGKILL. As a much less extreme way of terminating containers, which still may result in the container closing, this will ensure you don’t accidentally damage any of your systems.

SIGTERM will automatically gravitate into SIGKILL, meaning that as long as you can wait 30 seconds, then you’re still going to be able to terminate the container, no matter what. SIGTERM gives your platform a bit of leeway, allowing it to close once it has saved all necessary data.

When Should I Use SIGKILL In Kubernetes?

Due to how extreme the use of the SIGKILL signal is within Kubernetes, and its original Linux for that matter, developers should only use it when they absolutely need to shut a container down. This doesn’t mean they simply want to close a process, but actually refers to when a container could be damaging the system by continuing to run.

There are two main examples of when it’s a great idea to use SIGKILL instead of SIGTERM, bypassing the soft-closure and instantly putting a stop to a process. These use cases are:

• Bug -- If a process is continually cleaning up for an extended period of time, there may be a bug that is preventing it from finishing this process. If you use SIGKILL, you’ll then be able to see exactly why the process was continually cleaning, and put a stop to it for next time.
• Malicious activity -- From time to time, developers will come into contact with malicious activity within their environment. If you’re worried about a process and think that it could be damaging, then launching SIGKILL and then running a diagnosis is a great preventative measure.

If you encounter these two situations, then it’s always a good idea to launch the SIGKILL signal to instantly put a stop to a process.

Wrap Up

SIGKILL, although very drastic, is very much needed in the world of development. While most containers within Kubernetes can be closed simply by using SIGTERM and allowing them all the time they need to close, some are much more stubborn.

Especially in the case of a bug or the injection of malicious processes into your system, relying on SIGKILL can be an effective way of protecting your system. That said, only use SIGKILL in extreme circumstances, with the much softer SIGTERM being your go-to method of rapidly closing containers and their connected processes in Kubernetes.

Image credit: postmodernstudio/depositphotos.com

Peter Davidson works as a senior business associate helping brands and start ups to make efficient business decisions and plan proper business strategies. He is a big gadget freak who loves to share his views on latest technologies and applications.