0

I am in the process of migrating an application from Windows server to Kubernetes running on cloud.I was able to launch the application successfully in Kubernetes. Next is restoration and there is a script provided to restore the data to the new instance, but that should be run when the instance of application is shutdown. There is a script called stop.sh to shutdown the instance of that application. Both restore and shutdown script should be run inside the POD. I got into the POD using "Kubectl exec" , and then i tried to shutdown the instance using stop.sh. Then the instance will shutdown, but the POD will also exit along with it and i am not able run the restore.sh script inside the POD. So is there a way where i can keep the POD alive even after my application instance is shutdown to run the restore script.

Regards, John

John
  • 1
  • 1
  • 1
    checkout this post: https://stackoverflow.com/questions/31870222/how-can-i-keep-a-container-running-on-kubernetes – Ken Chen Jun 02 '20 at 07:53
  • Can you have the container run its own shutdown sequence? What do you expect to happen if the main container process crashes, or if Kubernetes needs to kill the pod because its node is being shut down? How would you support multiple copies of the pod running from a Deployment? (I would avoid `kubectl exec` for routine operations.) – David Maze Jun 02 '20 at 10:25

1 Answers1

1

A POD is meant to stay alive while the main process is running, when the main process shutdown, the pod will be terminated.

What you want is not how to keep the POD alive, but how to refactor your application to work with Kubernetes properly.

The restore phase you previously had in a script, will likely run as an init container. Init containers are specialized containers that run before other containers in a Pod, so you could run your restore logic before the main application start.

The next phase is starting the application, the application should start by itself inside the container when the container is created, so the init container shouldn't affect it's lifecycle. The application will assume the init container has done it's work and the environment is setup properly.

The next phase is termination, when a container is started or stopped, Kubernetes will trigger container hooks for PostStart and PreStop. You likely need to use the PreStop hook to execute the custom script.

The scenario above, assumes minimal changes to the application, if you are willing to refactor the application to deploy it to Kubernetes, there are other ways it can be achieved, like using persistent volumes to store the data and re-use it when the container start, so you won't need to do the backup and restore all the time.

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36