Keycloak Upgrade with Zero downtime

[Navin Kaushik]

Hello All,

We are going to use Keycloak in Kubernetes cluster with mysql in HA mode, does Keycloak supports zero downtime upgrade ?

-Regards,

Navin

[gaurav singh]

Are you trying to do rolling upgrade  for instances ? if you're about to do a rolling upgrade for KC cluster, then it's still not supported yet please see https://issues.redhat.com/browse/KEYCLOAK-7301 

As a work around you need to shutdown instances running 11 version and then start 12 version,

Sent from my iPhone

On 30-Jun-2021, at 11:12 PM, Navin Kaushik <navink...@gmail.com> wrote:

Hello All,

We are going to use Keycloak in Kubernetes cluster with mysql in HA mode, does Keycloak supports zero downtime upgrade ?

-Regards,

Navin

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/5f6fee54-b06a-40b3-bd15-46acac1efd86n%40googlegroups.com.

[Navin Kaushik]

We are planning to use Codecentric helm chart, I asked in new thread which charts are recommended.

[benjam...@gmail.com]

If it is just specific on Keycloak upgradeability in cluster in a zero downtime manner, from our experience it's almost a yes. Ours are deployed on AWS ECS cluster rather than Kubernetes cluster and we do rolling upgrades. The only issues have been with the embedded Infinispan: We ran into problem upgrading from Keycloak 11 to 12, and 12 to 13/14, with errors from new upgraded instances trying to join the Infinispan cluster by existing Keycloak instances. Workaround was to force the new instances to form a new Infinispan cluster. The upgrades were fine otherwise with minimal downtime. 

[Shiva Prasad Thagadur Prakash]

Hi Benjamin,

How did you force the instances to continue forming a cluster? is there any configuration that we need to do? could you please tell what you guys have done?

kind regards,

Shiva

--

You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/27495f92-da05-49e4-b1ad-ac83e06537c5n%40googlegroups.com.

[dc...@prosentient.com.au]

I haven’t done many Keycloak upgrades yet, but I’m curious how you deal with database migrations.

 

The first new node would perform the migration, but then the old node would be using the old schema, unless Keycloak is careful with its database schema changes so as to allow rolling upgrades? Then you just upgrade the other nodes (or rather destroy and replace) quickly enough not to notice any problems?

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

--

[benjam...@gmail.com]

We played with the Jgroups discovery mechanism - we use JDBC_PING so we simply force the upgraded Keycloak instance to use an alternate JGROUPPING table which in essence forms a new Infinispan cluster. The downside is that all users will have to re-authenticate because the cache couldn't be carried over but the service will remain up. We would do this only if we find within the test env that the Infinispan would cause a problem during a rolling upgrade. 

[benjam...@gmail.com]

Database migration - this is a risk. We accept the risk that during the minutes while the rolling upgrade occur it may cause some errors with existing instances, but as you said, hopefully it'd be quick enough not to be noticed. We try to upgrade in pace with new versions of Keycloak to minimize database changes. The biggest worry is if the database migration fails halfway in production, causing both old and new instances to fail, despite us doing successful rolling upgrade runs in test environments...