<p>I'd like to add a seamless upgrade capability to a Kubernetes operator which manages a distributed database. Is there some good practices to do that?</p>
<p>Particularly, on the configuration side, here is my CR.yaml:</p>
<pre><code>apiVersion: qserv.lsst.org/v1alpha1
kind: Qserv
metadata:
  name: qserv
spec:
  czar:
    image: qserv/qserv:v1.0.0
    replicas: 1
  storage: 1Gi
  storageClassName: standard
  worker:
    image: qserv/qserv:v1.0.0
    replicas: 2
</code></pre>
<p>Shall I perform database schema upgrade it when the container image tag changes in my <code>CR.yaml</code> file?
Shall I add a &quot;performDatabaseUpgrade=true&quot; field in my <code>CR.yaml</code>?
Or is there other techniques, like creating an additional CRD?</p>
<p>In addition, is there a recommended way to implement this inside the <code>operator-sdk</code> framework?</p>

Fabrice Jammes
<p>I prefer the first approach you mention, changing the container image when the tag changes in the CR.yaml.</p>
<p>About how to implement this, I prefer to perform a check, create, validate and update cycle inside the reconcile loop for each operand following this steps:</p>
<ol>
<li><code>check</code>: if the operand exists and that the owner reference matches the custom resource.</li>
<li><code>create</code>: if the operand doesn't exists create a new one.</li>
<li><code>validate</code> the operand configuration matches the custom resource. (For example, compare the Docker image of a pod with the custom resource.)</li>
<li><code>update</code> if you detect any difference in the <code>validate</code> step.</li>
</ol>
