Hi,
When the TLS is changed/refreshed (the content is changed, the cert is mounted through secret), would the operator restart itself and reconcile the cluster due to using the new cert?
When the certificate or key is changed the operator should automatically pickup the new content the next time it tries to communicate with the FDB cluster or one of the sidecars. For the sidecars the certificate is always loaded: fdb-kubernetes-operator/pod_client.go at main · FoundationDB/fdb-kubernetes-operator · GitHub and the fdbclient should also refresh the certificate and key if it is changed.
Another question, we mount TLS cert in both operator and fdb itself. So, it is required for operation purpose like starting and stopping the operand? Why does it need the cert between the operator and operand as the operand only need the cert for communicate to outside. Wouldn’t it should be ok if only RBAC is there for communication and control?
What exactly do you mean with the operand? The operator needs the TLS setup to communicate with the FoundationDB cluster (if enabled) and the sidecars (if enabled).
Wouldn’t it should be ok if only RBAC is there for communication and control?
If you mean Kubernetes RBAC, this is only used for access control for Kubernetes resources not for the sidecar or the FoundationDB cluster. Adopting RBAC would be more challenging and probably requires some additional tooling.
So, the operator needs the TLS to function (like start/stop fdb pods) since it needs to communicate with them.
The issue I am facing is that, we are creating a second namespace and put the fdb operator in there and reassign the old pods to this new operator. The cert is not there at the start and it was apply to the setup with a new cert. At this moment, the operator can no longer talk to the pods since the cert is different and it stuck. Restarting the operator created a new set of fdb pods with the new cert but the old set of pods remains.
So, is there a way to get around it?