Uploaded image for project: 'Red Hat build of Keycloak'
  1. Red Hat build of Keycloak
  2. RHBK-2130

Zero-downtime image change for the KC Operator

XMLWordPrintable

    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected

      Narrative

      When using optimized or customized images, the Keycloak CR is configured with an image name. Whenever the image name changes, the KC Operator will scale down the StatefulSet when doing a redeployment, which leads to a small but noticeable downtime.

      Due to that, changing a theme or changing a built time configuration always leads to a downtime, even if the version of Keycloak stays the same.

      Value Proposition

      Allow updates of build time parameters for optimized images and updates of custom images with themes without a downtime as rolling updates

      Goals

      • Allow the Operator to determine if the new image is using the same Keycloak version as the currently running version, and then decide when to scale down or when to do a rolling update.
      • Allow an option with toggles to configure the rolling vs. recreate behavior in the Keycloak CR
      • Decision should be taken by the Keycloak image, and not by the Operator to allow the functionality to be used also outside of Kubernetes.

      Non-Goals

      • (future) Allow rolling updates for different versions of Kecyloak. See RHBK-1917 for zero downtime upgrades for patch releases.
      • (future) Allow configuration changes to contribute to the decision, so that they can prevent a rolling upgrade.
      • (future) Allow a changed theme or a Keycloak extension to contribute to the decision, so that either of these can prevent a rolling upgrade

      Implementation Notes

      The KC Operator could spin up the old and the new image as a pod and they could pass on information between them as a JSON file using a new command. The exit code or the termination log can be used to pass the outcome to the Operator.

      Benefits: No additional information outside of the image needs to be passed in Keycloak's CR. No image metadata needs to be parsed outside of the standard Kubernetes API. A similar mechanism could work non-Kubernetes environments.

      The issues RHBK-1917 and RHBK-1918 would be using the same mechanism.

      Further discussion: https://docs.google.com/document/d/1pKyKLPDNoFe2rKN68R-RgVDe1ENPM3AUmZQWycQFsOY/edit?tab=t.0

              pruivo@redhat.com Pedro Ruivo
              aschwart@redhat.com Alexander Schwartz
              Votes:
              1 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: