How does Kubernetes terminate an instance after helm upgrade

Question

I have a node.js application that is running on a Kubernetes cluster, I am using helm to manage it currently. I have ran into a bit of an issue, when the application starts it connects to a service discovery tool, when it is to shut down it should disconnect from said tool. If I do it locally then it works fine, however when I do a helm upgrade it goes sideways and doesn't disconnect which then results in the api gateway having a fit.

Is there something different than a basic helm template and using upgrade? The application supports what I need just a matter of having Kubernetes do it too.

Here is the express server and consul code, it goes at the bottom of my app.js file.

const port = 8081;
app.listen(port, () => {
    const CONSUL_ID = require('uuid').v4();
    const ip = require('ip');
    const my_IP = ip.address();
    let options = {
      name: 'auth',
      address: `${my_IP}`,
      port: port,
      id: CONSUL_ID,
      check: {
        ttl: '10s',
        deregister_critical_service_after: '1m'
      }
    };
    consul.agent.service.register(options, function(err) {
      if (err) throw err;
      console.log(`Registered service with ID of ${CONSUL_ID}`);
    });
    
    setInterval(() => {
      consul.agent.check.pass({id:`service:${CONSUL_ID}`}, err => {
        if (err) throw new Error(err);
      });
    }, 5 * 1000);
    
    process.on('SIGINT', () => {
      console.log(`SIGINT. De-Registering service with ID of ${CONSUL_ID}`);
      consul.agent.service.deregister(CONSUL_ID, (err) => {
        if(err) console.log(`Error de-registering service from consul, with error of : ${err}`);
        if(!err) console.log(`De-registered service with ID of ${CONSUL_ID}`);
        process.exit();
      });
    });
    console.log(`Auth server running express started on port ${port}.`);
});

Answer 1

Suppposing that you are using typical Deployments, a new replicasets is created and the old one shrunk.

Looking at the docs for 1.16, it seems that TERM is sent, and then finally KILL.

When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.

https://v1-16.docs.kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

Therefore, you'll want to accept TERM signals, not just KILL. Also, you'll need to ensure the signal is properly transmitted from the surrounding docker container into your server process.