SIGTERM, also known as Exit Code 143, is a signal that allows users to terminate a process gracefully within their Kubernetes environments. This signal has its origins in Linux, with its usefulness being one of the main reasons that it has been incorporated into Kubernetes. Often mistaken for SIGKILL, this signal is actually about shutting down processes gracefully.

Whenever a user needs to terminate a process but wants to ensure that the internal cleanup stages are carried out, they should use the SIGTERM signal. SIGTERM tells a process it must close, then gives it 30 seconds to gracefully terminate all processes. If the process does not stop within those 30 seconds, then a follow-up signal, SIGKILL, will be initiated. SIGTERM’s pair signal, SIGKILL, will automatically terminate a process, no matter what it was doing. In this article, we’ll explore the benefits of SIGTERM, exploring this useful signal and why it's so common within Kubernetes environments. 

How To Use SIGTERM In Kubernetes

If you’re looking to gracefully terminate a process in Kubernetes, then you’ll want to use SIGTERM. When you terminate a pod, SIGTERM is automatically sent by Kubernetes, allowing you to select which pods you’d like to terminate and know that they’ll be closed properly and safely. 

There are two cases through which pods can be terminated: 

• Automatically - Many times, if a pod is deployed or needs to be scaled, it will automatically be terminated by Kubernetes. In these cases, Kubernetes will automatically send SIGTERM to ensure the pod is terminated properly.

• Manually - If you need to terminate a specific pod, then you can select it within your environment and then terminate it manually. Doing so will launch SIGTERM, giving the pod 30 seconds to shut down. To terminate a pod, simply send ‘kubectl delete’ or use API calls.  

In both of these cases, SIGTERM will then initiate. The grace period that you give to your pods will vary, and can be changed within your configurations. That said, it’s generally a good idea to leave the 30-second countdown, as this is enough time for almost any pod to gracefully close without causing any data rupture or corruption.

How Does SIGTERM Work in Kubernetes?

Due to the nature of Kubernetes environments to continually shift and change, many pods will routinely go through the process of terminating. With this considered, the pathway of termination is one that you can readily track through the pods. 

When a pod is automatically terminated, the process of closing a pod is split into three main movements: 

• Termination Preparation - Whether a pod needs to shut down because it has insufficient resources, or maybe because you’re scaling the environment, Kubernetes always starts the termination process by ensuring that the pod doesn’t receive any new traffic.

• SIGTERM Signal - Kubernetes will then send the SIGTERM signal to the pod, which will initiate the 30-second process of shutting down the pod, saving all data while it does. 

• SIGKILL - After the grace period has elapsed, Kubernetes will then initiate the SIGKILL signal, which will completely terminate the pod, no matter what it is doing.  

With these three steps, a Kubernetes pod or process will have been completely terminated. 

Why Use SIGTERM Instead of SIGKILL in Kubernetes?

When comparing these two exit signals, many assume that simply because both have the same final impact, they are totally interchangeable. While it’s true that your pod will terminate when launching these signals, they have different outcomes in terms of the integrity of your Kubernetes environment. 

There are three main reasons to use SIGTERM instead of SIGKILL: 

• SIGTERM ensures that processes have time to clean up their data before shutting down.

• SIGTERM is safer in terms of making sure none of your environment is corrupted.

• SIGTERM naturally launches SIGKILL afterward if the pod isn’t responding, meaning it will then only use drastic measures where they are needed.  

The final point, especially, demonstrates exactly why you should always use SIGTERM before SIGKILL. As one follows the other, it’s always a good idea to start with SIGTERM and then let SIGKILL take its course if needed.

How Do I Know If a Pod Shut Down Within the Grace Period?

Considering SIGTERM actively moves into SIGKILL after the grace period, many developers that are new to the Kubernetes environment wonder how they can tell which of the two signals actually terminated the process. This factor is important to know as when it comes to data integrity, SIGTERM ensures that all data remains incorrupt, while SIGKILL could signify a level of data loss. 

There is a very easy method of checking how exactly a pod terminated. Foremost, users should send ‘kubectl describe pod’ on the specific pod that they want information on. With this, you’ll receive the exit code that is associated with that pod.  

• SIGTERM - If your pod closed gracefully during the period of time you gave it, then you’ll receive exit code 143.

• SIGKILL - If your pod didn’t manage to close within the period of time outlined in your grace period of SIGTERM, then it will return exit code 137. This exit code is associated with SIGKILL, so you could then conduct a quick check on whether the pod closed before it managed to clean up its processes.  

With these exit codes, you’ll know exactly how your pod terminated.

Final Thoughts

Stemming from Linux, SIGTERM, and it’s partner signal, SIGKILL, are two useful commands to be familiar with in Kubernetes. SIGTERM is one of the easiest ways of terminating a process while still ensuring that all the data associated with that pod remains intact. Considering the connection between SIGTERM and SIGKILL, with one naturally flowing into the other, initiating the first will ensure that the pod is terminated - one way or another. 

If you’re looking to prevent data corruption, SIGTERM is the leading method of terminating a pod that you want closed. With this, you’ll be well on your way to managing a healthy Kubernetes environment. 

More Information

Sigterm

Related Articles

 What Is the Shift-Left Approach in DevOps?

Insights Into Successful Software Delivery

New DevOps Credentials From IBM On Coursera

The DevOps Master Class - Go Behind The Concept

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info