Consider a Deployment instead of a StatefulSet

[ahus1]

Change Keycloak Operator for multi-site / clusterless to use a deployment as there without JGroups and the clustered caches there is no need for a StatefulSet any more.

This would simplify the deployment, and would allow for faster rolling updates.

Original discussion: keycloak/keycloak#11763 (reply in thread)

[ahus1]

FYI: @shawkins / @mhajas / @ryanemerson / @kami619 / @pruivo

[pruivo]

It crossed my mind last week. There is no restriction from the Infinispan side but I'm not sure how database migration is handled if multiple Keycloak nodes start concurrently (patch upgrade).

Also, the Keycloak operator would have to be modified to check the features enabled and decide to create a stateful set or a deployment. It will make the logic more complex.

[ahus1]

On database migration, the is a locking mechanism based on the database, so Keycloak is fine if multiple Pods with a new version start up concurrently. They will wait until the first has finished the migration.

And yes, the Operator would need to know about this. And it would need to do something safe (enough) to switch between the two.

[ryanemerson]

And yes, the Operator would need to know about this. And it would need to do something safe (enough) to switch between the two.

In the case of moving away from a cluster with either the MULTI_SITE or CLUSTERLESS feature, all pods would need to be recreated anyway, so I don't think the switching logic would be too complex as we just have to gracefully scaledown the Deployment, remove it and then create a new Statefulset.

The changes being explored to improve the rolling configuration update experience could be useful here, as we could potentially state a feature's requirements (i.e. compatible with StatefulSet and/or Deployment) as part of the upgrade metadata.