patternkubernetesMinor
Control order of container termination in a single pod in Kubernetes
Viewed 0 times
ordercontainercontrolkubernetessingleterminationpod
Problem
I have two containers inside one pod. One is my application container and the second is a CloudSQL proxy container. Basically my application container is dependent on this CloudSQL container.
The problem is that when a pod is terminated, the CloudSQL proxy container is terminated first and only after some seconds my application container is terminated.
So, before my container is terminated, it keeps sending requests to the CloudSQL container, resulting in errors:
That's why, I thought it would be a good idea to specify the order of termination, so that my application container is terminated first and only then the cloudsql one.
I was unable to find anything that could do this in the documentation. But maybe there is some way.
The problem is that when a pod is terminated, the CloudSQL proxy container is terminated first and only after some seconds my application container is terminated.
So, before my container is terminated, it keeps sending requests to the CloudSQL container, resulting in errors:
could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432That's why, I thought it would be a good idea to specify the order of termination, so that my application container is terminated first and only then the cloudsql one.
I was unable to find anything that could do this in the documentation. But maybe there is some way.
Solution
But maybe there is some way.
Order of termination (or start) as such is not something you can easily define, but you can try a workaround with Container Lifecycle Events.
General idea is that on a
Order of termination (or start) as such is not something you can easily define, but you can try a workaround with Container Lifecycle Events.
General idea is that on a
PreStop handler for proxy container you can check if app container finished working (say localhost:appport is not active or whatever api check you can muster to determine when app pod is down) and then continue with proxy pod shutdown normally.Context
StackExchange DevOps Q#4892, answer score: 2
Revisions (0)
No revisions yet.