<blockquote>
  <p>But maybe there is some way.</p>
</blockquote>

<p>Order of termination (or start) as such is not something you can easily define, but you can try a workaround with <a href="https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/" rel="nofollow noreferrer">Container Lifecycle Events</a>.</p>

<p>General idea is that on a <code>PreStop</code> 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.</p>

CC BY-SA 4.0
2019-12-04T16:02:38.730Z
Thanks for this suggestion.  I'm having the same problem as the OP, and I like your idea as a workaround... However, I'm not sure how to have the lifecycle event defined in the CloudSQL Proxy container check for the state of the application container, which what would be needed for this to work (I think). Any experience with cross-container lifecycle checks? :)
JJC
CC BY-SA 4.0
2018-09-06T07:38:34.267Z
2018-09-06T07:38:34.267Z
Const
<p>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. </p>

<p>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.</p>

<p>So, before my container is terminated, it keeps sending requests to the CloudSQL container, resulting in errors:</p>

<pre><code>could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432
</code></pre>

<p>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.</p>

<p>I was unable to find anything that could do this in the documentation. But maybe there is some way.</p>

<kubernetes>
Control order of container termination in a single pod in Kubernetes
Jahongir Rahmonov
# Control order of container termination in a single pod in Kubernetes

(Asked by: username_0 on 2018-09-03)

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:
could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432

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.

**Tags:** kubernetes


---

## 1 answers

### Answer by username_1 on 2018-09-06. Score: 2

> 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](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).

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.

> **Comments:**
> **username_2**: Thanks for this suggestion.  I'm having the same problem as the OP, and I like your idea as a workaround... However, I'm not sure how to have the lifecycle event defined in the CloudSQL Proxy container check for the state of the application container, which what would be needed for this to work (I think). Any experience with cross-container lifecycle checks? :)  

---

