<p>I am using a POD directly to manage our C* cluster in a K8s cluster, not using any high-level controller. When I want to upgrade C*, I want to do an image update. Is this a good pattern to update image for an upgrade? </p>

<p>I saw the high-level deployment controller support image update too, but that causes the POD to delete and recreate, which in turn causes the IP to change. I don't want to change the IP and I found if I directly update the POD image, it can cause a restart and also keep the IP. This is the exact behavior I want, is this pattern right?</p>

<p>Is it safe to use in production? </p>

Xiaolong Jiang
<p>I believe you can follow the K8s <a href="https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets" rel="nofollow noreferrer">documentation</a> for a more 'production ready' upgrade strategy. Basically, use the <code>updateStrategy=RollingUpdate</code>:</p>

<pre><code>$ kubectl patch statefulset cassandra -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}
</code></pre>

<p>and then update the image:</p>

<pre><code>$ kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"cassandra:next-version"}]'
</code></pre>

<p>and watch your updates:</p>

<pre><code>$ kubectl get pod -l app=cassandra -w
</code></pre>

<p>There's also <a href="https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#staging-an-update" rel="nofollow noreferrer">Staging the Update</a> in case you'd like to update each C* node individually, for example, why if the new version turns out to be incompatible, then you can revert that C* back to the original version.</p>

<p>Also, familiarize with all the Cassandra release notes before doing the upgrade.</p>
