Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.7. 单集群部署的概念

通过同步复制了解单集群部署。

本主题描述了单集群设置和预期的行为。它概述了高可用性架构的要求，并描述了优点和权衡。

2.7.1. 何时使用此设置
复制链接

使用此设置将红帽构建的 Keycloak 部署到 OpenShift 集群。

2.7.2. 单个或多个可用区
复制链接

红帽构建的 Keycloak 部署的行为和高可用性性能最终由 OpenShift 集群的配置决定。通常，OpenShift 集群部署在单个可用区中，但为了提高容错能力，可以在 多个可用区间部署集群。

Red Hat build of Keycloak Operator 默认定义了以下拓扑分布约束，首选红帽构建的 Keycloak pod 部署到不同的节点上，并尽可能使用不同的可用区： 

      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: "ScheduleAnyway"
          labelSelector:
            matchLabels:
              app: "keycloak"
              app.kubernetes.io/managed-by: "keycloak-operator"
              app.kubernetes.io/instance: "keycloak"
              app.kubernetes.io/component: "server"
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: "ScheduleAnyway"
          labelSelector:
            matchLabels:
              app: "keycloak"
              app.kubernetes.io/managed-by: "keycloak-operator"
              app.kubernetes.io/instance: "keycloak"
              app.kubernetes.io/component: "server"
Copy to Clipboard Toggle word wrap
重要

为了通过多个可用区配置高可用性，数据库也能够处理区域故障，因为红帽构建的 Keycloak 依赖于底层数据库来保持可用。

2.7.3. 此设置可以存活的故障
复制链接

在单一区中的单个集群中部署红帽构建的 Keycloak，或跨多个可用区，或带有所需网络延迟和数据库配置的数据中心，并显著改变高可用性特性，因此我们会独立考虑这些架构。

2.7.3.1. 单区
复制链接

在测试高可用性 单集群 部署过程中，我们观察到以下恢复时间，以了解上述事件：

Expand
失败恢复RPO1RT2

红帽构建的 Keycloak Pod

在集群中运行多个 Keycloak Pod 的红帽构建。如果一个实例失败，一些传入的请求可能会收到错误消息，或者延迟几秒钟。

没有数据丢失

少于 30 秒

OpenShift 节点

在集群中运行多个 Keycloak Pod 的红帽构建。如果主机节点停止，则该节点上的所有 pod 都将失败，一些传入的请求可能会收到错误消息，或者延迟一段时间（以秒为单位）。

没有数据丢失

少于 30 秒

红帽构建的 Keycloak 集群连接

如果 OpenShift 节点之间的连接丢失，则数据不能在这些节点上托管的 Keycloak pod 之间发送。传入的请求可能会收到错误消息，或者延迟（以秒为单位）。红帽构建的 Keycloak 最终会从其本地视图中删除无法访问的 pod，并停止向它们发送数据。

没有数据丢失

秒到分钟

表注：

1 测试的恢复点目标，假设设置的所有部分都健康。
2 最大恢复时间观察到。

2.7.3.2. 多个区
复制链接

在测试高可用性多集群部署过程中，我们观察到以下恢复时间，以了解上述事件： #multi-cluster-introduction#multi-cluster-supported-configuration

Expand
失败恢复RPO1RT2

数据库节点3

如果写入器实例失败，则数据库可以提升相同或其他区域中的读者实例，使其成为新的写入器。

没有数据丢失

分钟的秒数（取决于数据库）

Red Hat build of Keycloak pod

在集群中运行多个 Keycloak 实例的红帽构建。如果一个实例失败，一些传入的请求可能会收到错误消息，或者延迟几秒钟。

没有数据丢失

少于 30 秒

OpenShift 节点

在集群中运行多个 Keycloak pod 的红帽构建。如果主机节点停止，则该节点上的所有 pod 都将失败，一些传入的请求可能会收到错误消息，或者延迟一段时间（以秒为单位）。

没有数据丢失

少于 30 秒

可用区失败

如果一个可用区失败，则该区中托管的 Keycloak pod 的所有红帽构建也会失败。至少部署与可用区相同的红帽构建的 Keycloak 副本数量，应该确保不会丢失数据，停机时间最小，因为存在其他 pod 可用于服务请求。

没有数据丢失

秒

连接数据库

如果可用区间的连接丢失，同步复制将失败。有些请求可能会收到错误消息，或延迟几秒钟。根据数据库，可能需要手动操作。

没有数据丢失3

分钟的秒数（取决于数据库）

红帽构建的 Keycloak 集群连接

如果 OpenShift 节点之间的连接丢失，则数据不能在这些节点上托管的 Keycloak pod 之间发送。传入的请求可能会收到错误消息，或者延迟（以秒为单位）。红帽构建的 Keycloak 最终会从其本地视图中删除无法访问的 pod，并停止向它们发送数据。

没有数据丢失

秒到分钟

表注：

1 测试的恢复点目标，假设设置的所有部分都健康。
2 最大恢复时间观察到。
3 假设数据库也在多个可用区间复制

2.7.4. 已知限制
复制链接

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

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

  2. 如果节点故障数大于或等于缓存配置的 num_owners，则多次节点故障可能会导致 authenticationSessions、loginFailures 和 actionTokens 缓存丢失条目，默认为 2。

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

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

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

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

  4. Operator 不会在 Pod 中配置站点的名称（请参阅 配置分布式缓存），因为它的值无法通过 Downward API 提供。machine name 选项使用调度 Pod 的节点的 spec.nodeName 进行配置。

2.7.5. 后续步骤
复制链接

继续阅读 构建块单集群部署 章节中的蓝图，以查找不同构建块的蓝图。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat