3.4. 已知限制

红帽构建的 Keycloak 升级过程中的停机时间

如果 可能出现滚动更新，可以通过启用检查补丁版本来解决此问题。

使用带有 whenUnsatisfiable: ScheduleAnyway s 的默认 topologySpreadConstraints 的部署，如果多个 pod 调度到失败的节点/区，则可能会在节点/区上出现数据。

用户可以通过使用 whenUnsatisfiable: DoNotSchedule 定义 topologySpreadConstraints 来缓解这种情况，以确保 pod 始终在区和节点间平均调度。但是，如果无法满足限制，这可能会导致一些红帽构建的 Keycloak 实例不会被部署。

因为 Infinispan 在分发缓存条目时不知道网络拓扑，因此如果缓存数据的所有 num_owner 副本都存储在失败的节点/区域中，则数据术语仍可发生在 node/availability-zone 失败时发生。您可以通过为节点和区定义 requiredDuringSchedulingIgnoredDuringExecution 将红帽构建的 Keycloak 实例总数限制为可用的节点或可用区的数量。但是，这代价是可扩展性，作为红帽构建的 Keycloak 实例的数量，这些实例可以被置备到 {kubernetes} 集群中的节点/可用区数量。

有关如何配置自定义反关联性 拓扑SpreadConstraints 策略，请参阅 Operator 高级配置详情。