5.2. 配置更新策略
在 Keycloak CR YAML 定义的 spec
部分中指定 update 策略:
value | 停机时间? | 描述 |
---|---|---|
| 在镜像名称或标签更改时 | 模拟红帽构建的 Keycloak 26.1 或旧行为。当 image 字段更改时,Operator 会在应用新镜像前缩减 StatefulSet。 |
| 不兼容的更改 | Red Hat build of Keycloak Operator 会检测是否可以滚动或重新创建更新。 在当前版本中,如果红帽构建的 Keycloak 版本与旧镜像相同,则红帽构建的 Keycloak 版本会执行滚动更新。红帽构建的 Keycloak 的未来版本将改变该行为,并使用配置中的附加信息、镜像和版本来确定是否可以滚动更新来减少停机时间。 |
|
只有 |
Red Hat build of Keycloak Operator 会检查 |
5.2.1. 了解 Auto 和 Explicit 更新策略 复制链接链接已复制到粘贴板!
使用自动更新策略时,Red Hat build of Keycloak Operator 会自动启动一个作业来评估滚动更新的可行。如果可能滚动更新,请参阅检查滚动更新中有关 流程的更多信息。这个过程会在检查时消耗集群资源,并在 StatefulSet 更新开始前引入小延迟。
如果将 Keycloak CR 配置为 不支持的配置参数
的一部分,则 Keycloak Operator 最好为启动的作业使用这些设置。仍然可能会因为
podTemplate
功能的灵活性及其不受支持的性质而丢失一些设置。
因此,如果从 podTemplate
中的 Secret、ConfigMap 或卷拉取的 podTemplate
或信息进行更改,Operator 可能会绘制错误的结论。
因此,如果您使用不受支持的 podTemplate
,您可能需要使用其它更新策略。
Explicit
更新策略将更新决策委派给用户。revision
字段充当用户控制的触发器。虽然红帽构建的 Keycloak Operator 不会解释 修订值本身,但
保持不变时对自定义资源(CR)的任何更改都会提示滚动更新。
修订版本
在进行自动 Operator 升级时请小心。Operator Lifecycle Manager (OLM)可能会升级 Keycloak Operator 的红帽构建,如果使用 Explicit
更新策略,这可能会导致意外行为或部署失败,因为 Operator 会在实际不支持时尝试滚动更新。如果您使用 Explicit
更新策略,请在升级前在非生产环境中进行全面的测试。
5.2.2. CR 状态 复制链接链接已复制到粘贴板!
RecreateUpdateUsed
的 Keycloak CR 状态指示最后一次更新操作过程中使用的更新策略。lastTransitionTime
字段指示最后一次更新发生的时间。使用这些信息观察 Operator 所采取的操作和决策。
Status | 描述 |
---|---|
| 初始状态。这意味着没有更新。 |
| Operator 在最后一次更新中应用了滚动更新策略。 |
|
Operator 在最后一次更新中应用了 recreate 更新策略。 |