Repository navigation
Replies: 2 comments 1 reply
|
See #49469 and new stateless feature https://www.keycloak.org/2026/07/multi-cluster-v2-and-stateless-mode As this moves toward fully supported, new issues are probably needed to cover the docs and operator usage of deployments. |
|
We are on the day to make this supported in 26.8, see #50642 Changing the deployment type in the Operator is out-of-scope for that, and might be a follow-up. I've added it as an optional task. |
The authenticationSessions, actionTokens, loginFailures have a number of owners of 2. When shutting down one node, you need to ensure that you are not shutting down another node while the rebalancing is still in progress, you you might lose data - as you described above. While a deployment can be used as you describe, it gets IMHO problematic in a HPA setup when you scale down by two pods at the same time. There was a recent change in KC 26.7 which should prevent this most of the time, see #44620, even for the non-stateless setups. While this has been built to prevent most of the cases, it is mostly "bolted on" as ISPN doesn't support it natively in that version. So consider it more a best effort than a guarantee. Having said all that, it should now be quite possible to run a deployment, but it is not on our priority list. I wouldn't even have the time to look at a community pull request for that at the moment, as we want to get other items ready. |
Uh oh!
There was an error while loading. Please reload this page.
The Kubernetes getting-started guide still deploys Keycloak as a StatefulSet. Now that user sessions
are persisted in the database by default in recent releases, I'm trying to understand whether that is
still technically necessary, or whether a plain Deployment would be equivalent. I'd like a sanity
check before we switch.
My reasoning - a StatefulSet provides three guarantees, and none seem to apply to a DB-backed
Keycloak:
nothing to persist per pod.
JDBC_PING (DB), i.e. membership is label-/DB-based, not tied to the pod ordinal or hostname. A
Deployment's pods are discovered the same way.
(maxUnavailable: 0) plus a PodDisruptionBudget seems to cover availability just as well, arguably
better (no capacity dip during rollout).
The part I want to double-check: persistent sessions remove the "losing a pod loses user sessions"
concern, but the embedded Infinispan cluster is still needed for authenticationSessions, actionTokens,
loginFailures and cache invalidation. However, that requires clustering, not stable node identity -
so it doesn't seem to be an argument for a StatefulSet either.
Questions:
with no local storage and an external DB?
would a Deployment-based example be welcome?
Have I overlooked anything? We plan to run ≥2 replicas behind an HPA" - that reframes it from a theoretical question to a real autoscaling scenario, where StatefulSet ordering is actively awkward.
Environment: Keycloak 26.x, GKE, external database, embedded Infinispan.
All reactions