Switching DB from one operator namespace to another and also using a new tls secret

Using FoundationDB Kubernetes Operator
1

Hi,
We are running FDB 6.2 in an operand namespace and the fdb operator in another operator namespace. Now, we would like to update our operator to a newer version by installing the new operator in another namespace and switch the operand from the old operator to the new one. But we are creating a new cert in both new operator namespace and operand namespace and as soon as we updated the CR, the operator created multiple additional pods and loss contact with the old pods and get stuck in a loop. Is there a proper way to do this?

2

Hi,
We are running FDB 6.2 in an operand namespace and the fdb operator in another operator namespace. Now, we would like to update our operator to a newer version by installing the new operator in another namespace and switch the operand from the old operator to the new one.

This should be fairly straightforward. I would perform the following steps:

  • Remove the old operator deployment in the old namespace (or scale it down to 0)
  • Create the new operator deployment in the new namespace

That will make sure that there is no conflict between two operator instances running in parallel.

But we are creating a new cert in both new operator namespace and operand namespace and as soon as we updated the CR, the operator created multiple additional pods and loss contact with the old pods and get stuck in a loop. Is there a proper way to do this?

For the certificate, I need some more information, e.g. is this still the same root CA? If you’re using peer verification rules (https://github.com/FoundationDB/fdb-kubernetes-operator/blob/main/docs/manual/tls.md#peer-verification-rules) make sure they include the newly generated certificate.

What do you mean by as we updated the CR? Can you share some more details about what versions you are updating to? How does a FoundationDBCluster configuration looks like? Without this information it will be hard to help you.

3

it has the same root but newly generated tls.ca and tls.key. So, the cert is different. Also volumeMount name for the cert is changed and the secret name is changed as well. This seems to trigger a creation of duplicate of pods.

4

it has the same root but newly generated tls.ca and tls.key. So, the cert is different. Also volumeMount name for the cert is changed and the secret name is changed as well. This seems to trigger a creation of duplicate of pods.

Maybe I misunderstood your post. I thought you only want to move the FoundationDB operator to another namespace? How is this affecting the FDB cluster deployment?

5

With the new cert (change of cert name and content and volumeMount name), it seems it will create some duplicate pods for log and controller, storage pods remain the same count. Although once the operator connect to the FDB cluster, the duplicated pods will be terminated and the FDB cluster will be back to normal counts, the starting of new pods might be a resource issues due it will take up resources first before they got terminated.