Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 5. Avoiding downtime with rolling updates

Avoid downtime when changing themes, providers, or configurations in optimized images.

By default, the Red Hat build of Keycloak Operator will perform rolling updates on configuration changes without downtime, and recreate updates with downtime when the image name or tag changes.

This chapter describes how to minimize downtimes by configuring the Red Hat build of Keycloak Operator to perform rolling updates of Red Hat build of Keycloak automatically where possible, and how to override automatic detection for rolling updates.

Use it, for example, to avoid downtimes when rolling out an update to a theme, provider or build time configuration in a custom or optimized image.

5.1. Supported Update Strategies
링크 복사

The Operator supports the following update strategies:

Rolling Updates
Update the StatefulSet in a rolling fashion, avoiding a downtime when at least two replicas are running.
Recreate Updates
Scale down the StatefulSet before applying updates, causing temporary downtime.

5.2. Configuring the Update Strategy
링크 복사

Specify the update strategy within the spec section of the Keycloak CR YAML definition: 

apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
  name: example-kc
spec:
  update:
    strategy: RecreateOnImageChange|Auto|Explicit
1 

    revision: "abc"
2
Copy to Clipboard Toggle word wrap
1
Set the desired update strategy here.
2
Revision value for Explicit strategy. Ignored by the other strategies.
Expand
Table 5.1. Possible field values
ValueDowntime?Description

RecreateOnImageChange (default)

On image name or tag change

Mimics Red Hat build of Keycloak 26.1 or older behavior. When the image field changes, the Operator scales down the StatefulSet before applying the new image.

Auto

On incompatible changes

The Red Hat build of Keycloak Operator detects if a rolling or recreate update is possible.

In the current version, Red Hat build of Keycloak performs a rolling update if the Red Hat build of Keycloak version is the same for the old and the new image. Future versions of Red Hat build of Keycloak will change that behavior and use additional information from the configuration, the image and the version to determine if a rolling update is possible to reduce downtimes.

Explicit

Only the revision field changes

The Red Hat build of Keycloak Operator checks the spec.update.revision value. If it matches the previous deployment, it performs a rolling update.

5.2.1. Understanding Auto and Explicit Update Strategies
링크 복사

When using the Auto update strategy, the Red Hat build of Keycloak Operator automatically starts a Job to assess the feasibility of a rolling update. Read more about the process in the Checking if rolling updates are possible chapter. This process consumes cluster resources for the time of the check and introduces a slight delay before the StatefulSet update begins.

Warning

If the Keycloak CR configured a podTemplate as part of the unsupported configuration parameters, the Keycloak Operator will do its best to use those settings for the started Job. Still it might miss some settings due to the flexibility of the podTemplate feature and its unsupported nature.

As a consequence, the Operator might draw the wrong conclusions if a rolling update is possible from changes to the podTemplate or information pulled in from Secrets, ConfigMaps or Volumes in the podTemplate.

Therefore, if you are using the unsupported podTemplate, you may need to use one of the other update strategies.

The Explicit update strategy delegates the update decision to the user. The revision field acts as a user-controlled trigger. While the Red Hat build of Keycloak Operator does not interpret the revision value itself, any change to the Custom Resource (CR) while the revision remains unchanged will prompt a rolling update.

Exercise caution when using this with automatic Operator upgrades. The Operator Lifecycle Manager (OLM) may upgrade the Red Hat build of Keycloak Operator, and if the Explicit update strategy is in use, this could lead to unexpected behavior or deployment failures as the Operator would attempt a rolling update when this is actually not supported. If you are using the Explicit update strategy, thorough testing in a non-production environment is highly recommended before upgrading.

5.2.2. CR Statuses
링크 복사

The Keycloak CR status of RecreateUpdateUsed indicates the update strategy employed during the last update operation. The lastTransitionTime field indicates when the last update occurred. Use this information to observe actions and decisions taken by the Operator.

Expand
Table 5.2. Condition statuses
StatusDescription

Unknown

The initial state. It means no update has taken place.

False

The Operator applied the rolling update strategy in the last update.

True

The Operator applied the recreate update strategy in the last update. The message field explains why this strategy was chosen.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat