<p>If your pods start fast, perhaps use <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment" rel="nofollow noreferrer">recreate strategy</a>, that will make sure to terminate &quot;old&quot; pods and &quot;recreate&quot; new ones.</p>
<blockquote>
<p>All existing Pods are killed before new ones are created when <code>.spec.strategy.type==Recreate</code>.</p>
</blockquote>

CC BY-SA 4.0
2022-05-13T07:05:34.153Z
You are right, I used to have recreate in place. Although, I didn't mention the fact that connecting all our clients at once is quite expensive as it produces a big load on the rest of the system.
thanosam
CC BY-SA 4.0
2022-05-12T19:26:27.233Z
2022-05-12T19:26:27.233Z
Kyslik
<h1>How to make a readiness probe fail when there is a newer version of the app available</h1>
<p>Stack: Node.js, GKE</p>
<h2>Context</h2>
<p>Clients are connected to pods via <strong>websockets</strong>. During a <strong>rolling update</strong>, clients that disconnect from the old pods can connect to either old pods or new pods. I want to minimize client disconnections and force them to <strong>connect only to the newest version of the pods</strong>. <strong>Making sure that ONLY one disconnection/connection takes place is crucial</strong>, I want to maximize the uptime of client connections, I cannot afford clients to connect/disconnect multiple times.</p>
<p>For this purpose I want to use the readinessProbe. I need to make it fail for old pods when a rolling update is taking place.</p>
<p>Recreate strategy cannot be used since the re-connection of all clients at once creates a big load on the system.</p>
<h2>Ideas</h2>
<h3>1. ConfigMap that holds the latest version of the app.</h3>
<ol>
<li>The current version of the app is passed as an env var and it is stored in memory.</li>
<li>The newest version of the app lives in a ConfigMap.</li>
<li>Health endpoint returns the <code>oldVersion</code> and <code>newVersion</code>.</li>
<li>Readiness probe GETs the /health and compares the two versions (<code>exec/curl</code>), <em>if not equal exit 1</em> and the probe fails.</li>
</ol>
<p>Drawbacks:</p>
<ul>
<li>Configmaps can take some minutes to sync which is a lot in my case. Is there a way to accelerate it?</li>
</ul>
<blockquote>
<p>the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/configuration/configmap/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/configuration/configmap/</a></p>
<p>What happens during a rollback?</p>
<ul>
<li>Logic to update the config map again and have the probes failing. Helm will not do the trick (<code>helm upgrade --install</code>)</li>
</ul>
<p>The purpose of this question is to find a way to do it in a timely manner. Do you have other ideas?</p>

<kubernetes><google-cloud-platform>
Make a readiness probe to fail when there is a newer version of the app being rolled out
thanosam
# Make a readiness probe to fail when there is a newer version of the app being rolled out

(Asked by: username_0 on 2022-05-11)

# How to make a readiness probe fail when there is a newer version of the app available

Stack: Node.js, GKE

## Context

Clients are connected to pods via **websockets**. During a **rolling update**, clients that disconnect from the old pods can connect to either old pods or new pods. I want to minimize client disconnections and force them to **connect only to the newest version of the pods**. **Making sure that ONLY one disconnection/connection takes place is crucial**, I want to maximize the uptime of client connections, I cannot afford clients to connect/disconnect multiple times.

For this purpose I want to use the readinessProbe. I need to make it fail for old pods when a rolling update is taking place.

Recreate strategy cannot be used since the re-connection of all clients at once creates a big load on the system.

## Ideas

### 1. ConfigMap that holds the latest version of the app.

1. The current version of the app is passed as an env var and it is stored in memory.
2. The newest version of the app lives in a ConfigMap.
3. Health endpoint returns the `oldVersion` and `newVersion`.
4. Readiness probe GETs the /health and compares the two versions (`exec/curl`), *if not equal exit 1* and the probe fails.

Drawbacks:

* Configmaps can take some minutes to sync which is a lot in my case. Is there a way to accelerate it?

> the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay

<https://kubernetes.io/docs/concepts/configuration/configmap/>

What happens during a rollback?

* Logic to update the config map again and have the probes failing. Helm will not do the trick (`helm upgrade --install`)

The purpose of this question is to find a way to do it in a timely manner. Do you have other ideas?

**Tags:** kubernetes, google-cloud-platform


---

## 1 answers

### Answer by username_1 on 2022-05-12. Score: 0

If your pods start fast, perhaps use [recreate strategy](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment), that will make sure to terminate "old" pods and "recreate" new ones.

> All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`.

> **Comments:**
> **username_0**: You are right, I used to have recreate in place. Although, I didn't mention the fact that connecting all our clients at once is quite expensive as it produces a big load on the rest of the system.  

---

