You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cluster Discovery for Dynamic k8s (Karpenter) after 'kubernetes' stack deprecation
#47293
Infrastructure: AWS EKS with Karpenter (frequent node consolidation/IP changes)
Database: External Postgres
Context
We are currently running Keycloak 26 in a Kubernetes environment where nodes are frequently consolidated by Karpenter. We recently encountered a critical health check failure (Keycloak cluster health check: DOWN) after restoring a database snapshot.
The Problem
The issue stems from the default jdbc-ping protocol. When a database snapshot is restored, the jgroups_ping table contains stale IP addresses from the time the snapshot was taken.
New Keycloak pods start.
They read the restored jgroups_ping table.
They attempt to form a cluster with "ghost" IPs that no longer exist in the current K8s VPC.
The cluster enters a degraded state, and the health check fails.
The Conflict
The official documentation notes that the kubernetes cache stack is deprecated. However, the default jdbc-ping approach appears brittle in environments involving:
Database snapshot restores.
Karpenter consolidation, where Pod IPs change frequently, leading to a build-up of stale entries in the DB before timeouts occur.
Questions for the Community/Maintainers
Given the deprecation of the kubernetes stack, what is the officially recommended "stateless" discovery method for Keycloak in k8s?
Are there built-in mechanisms to force-clear discovery metadata on startup without manual SQL intervention (DELETE FROM jgroups_ping)?
I'd appreciate any guidance to handle discovery that survives both node mobility and database lifecycle events.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Environment
Context
We are currently running Keycloak 26 in a Kubernetes environment where nodes are frequently consolidated by Karpenter. We recently encountered a critical health check failure (Keycloak cluster health check: DOWN) after restoring a database snapshot.
The Problem
The issue stems from the default
jdbc-pingprotocol. When a database snapshot is restored, thejgroups_pingtable contains stale IP addresses from the time the snapshot was taken.jgroups_pingtable.The Conflict
The official documentation notes that the
kubernetescache stack is deprecated. However, the defaultjdbc-pingapproach appears brittle in environments involving:Questions for the Community/Maintainers
Given the deprecation of the
kubernetesstack, what is the officially recommended "stateless" discovery method for Keycloak in k8s?Are there built-in mechanisms to force-clear discovery metadata on startup without manual SQL intervention (DELETE FROM jgroups_ping)?
I'd appreciate any guidance to handle discovery that survives both node mobility and database lifecycle events.
All reactions