将其作为为产品环境确定大小的起点。根据您的负载测试，根据需要调整环境中的值。
|
总结
使用的 CPU 与请求数量成线性比例，直到以下测试的限制。
建议
包括 Realm 数据缓存和 10,000 个缓存会话的 Pod 的基本内存使用量为 1250 MB RAM。
在容器中，Keycloak 为基于堆的内存分配了 70% 的内存限制。它还将使用大约 300 MB 的非基于堆的内存。要计算请求的内存，请使用上面的计算。作为内存限制，从上面的值中减去非堆内存，然后将结果除以 0.7。
每秒 15 次基于密码的用户登录，为集群分配 1 个 vCPU（测试高达每秒 300 次）。
Keycloak 将大部分 CPU 时间用于对用户提供的密码进行哈希处理，并且它与哈希迭代次数成正比。
每秒 200 次客户端凭据授予，为集群分配 1 个 vCPU（测试高达每秒 2000 次）。
大部分 CPU 时间都用于创建新的 TLS 连接，因为每个客户端只运行一个请求。
每秒 120 个刷新令牌请求，为集群分配 1 个 vCPU（测试高达每秒 435 个刷新令牌请求）。
留出 150% 的额外空间来处理负载峰值。这可确保节点快速启动，并具有足够的容量来处理故障转移任务。在我们的测试中，当 Keycloak 的 Pod 被限制时，其性能显着下降。
Keycloak 默认情况下将用户会话存储在数据库中，需要以下资源才能在 Aurora PostgreSQL 多 AZ 数据库上获得最佳性能
每秒 100 个登录/注销/刷新请求
预算为 1400 写入 IOPS。
分配 0.35 到 0.7 个 vCPU 之间。
vCPU 要求以范围形式给出，因为随着数据库主机上 CPU 饱和度的增加，每个请求的 CPU 使用量会减少，而响应时间会增加。数据库上的较低 CPU 配额会导致峰值负载期间响应时间变慢。如果峰值负载期间快速响应时间至关重要，请选择更大的 CPU 配额。请参阅以下示例。
目标大小
每秒 45 次登录和注销
每秒 600 次客户端凭据授予
每秒 360 次刷新令牌请求（登录的比例为 1:8）
3 个 Pod
计算的限制
每个 Pod 请求的 CPU：3 个 vCPU
（每秒 45 次登录 = 3 个 vCPU，每秒 600 次客户端凭据授予 = 3 个 vCPU，345 次刷新令牌 = 3 个 vCPU。这总计为 9 个 vCPU。在集群中运行 3 个 Pod，则每个 Pod 请求 3 个 vCPU）
每个 Pod 的 CPU 限制：7.5 个 vCPU
（允许额外 150% 的 CPU 请求来处理峰值、启动和故障转移任务）
每个 Pod 请求的内存：1250 MB
（1250 MB 基本内存）
每个 Pod 的内存限制：1360 MB
（1250 MB 预计内存使用量减去 300 个非堆使用量，然后除以 0.7）
Aurora 数据库实例：db.t4g.large 或 db.t4g.xlarge，具体取决于峰值负载期间所需的响应时间。
（每秒 45 次登录，每秒 5 次注销，每秒 360 次刷新令牌。这总计为每秒 410 个请求。这预计的 DB 使用量为 1.4 到 2.8 个 vCPU，DB 空闲负载为 0.3 个 vCPU。这表明使用 2 个 vCPU 的 db.t4g.large 实例或 4 个 vCPU 的 db.t4g.xlarge 实例。如果允许峰值使用期间响应时间更高，则 2 个 vCPU 的 db.t4g.large 会更具成本效益。在我们的测试中，在给定此场景的情况下，当 2 个 vCPU 的 db.t4g.large 实例上的 CPU 饱和度达到 90% 时，登录和令牌刷新的中位数响应时间增加了 120 毫秒。为了在峰值使用期间获得更快的响应时间，请考虑在此场景中使用 4 个 vCPU 的 db.t4g.xlarge 实例。）
要创建具有一个 AWS 区域中的两个 AZ 的主动-主动 Keycloak 设置的大小，请按照以下步骤操作
在第二个站点上创建相同数量的 Pod，并使用与上面相同的内存大小。
数据库大小保持不变。两个站点都将连接到同一个数据库写入程序实例。
关于 CPU 请求和限制的大小，根据预期的故障转移行为，有不同的方法
为第二个站点保留与上面相同的 CPU 请求和限制。这样，任何剩余的站点都可以立即接管来自主站点的流量，而无需扩展。
将第二个站点的 CPU 请求和限制降低上面值的 50%。当其中一个站点发生故障时，手动、自动或使用水平 Pod 自动缩放器将剩余的站点从 3 个 Pod 扩展到 6 个 Pod。这需要集群上有足够的备用容量或集群自动缩放功能。
将第二个站点的 CPU 请求降低 50%，但保留与上面相同的 CPU 限制。这样，剩余的站点可以接收流量，但缺点是节点将遇到 CPU 压力，因此在峰值流量期间响应时间会变慢。这种设置的优点是，在故障转移期间无需扩展 Pod 数量，这更易于设置。
以下设置用于检索上面的设置，以运行大约 10 分钟的不同场景测试
通过 ROSA 在 AWS 上部署的 OpenShift 4.16.x。
具有 m5.4xlarge 实例的 Machinepool。
使用 Operator 和 3 个 Pod 在高可用性设置中部署 Keycloak，并在主动/主动模式下有两个站点。
在传递模式下运行的 OpenShift 的反向代理，客户端的 TLS 连接在 Pod 处终止。
多 AZ 设置中的数据库 Amazon Aurora PostgreSQL。
使用 Argon2 的默认用户密码哈希，以及 5 次哈希迭代和至少 7 MiB 的内存大小，如 OWASP 建议的那样（这是默认值）。
客户端凭据授予不使用刷新令牌（这是默认值）。
数据库中包含 20,000 个用户和 20,000 个客户端的种子数据。
Infinispan 本地缓存默认为 10,000 个条目，因此并非所有客户端和用户都适合缓存，一些请求需要从数据库中获取数据。
根据默认设置，所有身份验证会话都在分布式缓存中，每个条目有两个所有者，允许一个 Pod 发生故障而不会丢失数据。
所有用户和客户端会话都存储在数据库中，并且不在内存中缓存，因为这是针对多站点设置进行测试的。对于单站点设置，由于将缓存固定数量的用户和客户端会话，预计性能会略高。
OpenJDK 21