So you want to deploy the ForgeRock User Store on Kubernetes?
ForgeRock's advice currently recommends: "... deploying DS in VMs as the processes to do maintenance and troubleshooting are well mastered..." however they "understand and accept that customers choose to deploy in Kubernetes, as long as they understand the limitations"
In this paper we will explain how Midships mitigate the risks associated with deploying the ForgeRock User Store on Kubernetes. Please reach out to us if you have any queries.
Utilise the benefits of Kubernetes (Auto-Restarts and Statefulsets)
Our ForgeRock Accelerator leverages the benefits that comes with using Kubernetes, namely:
Auto-restart on failure
 and  are leveraged by the User, Configuration and Token stores whereas  is used by the Access Manager.
Kubernetes orchestrates Stateful applications using a combination of its “stateful sets”, “persistent volume” and “persistent volume claims” frameworks. All stores are setup with a persistent volume set to a “Retain” reclaim policy. This ensure that when the application is deleted the data remains for later use.
Note: Persistent Volumes use disks outside of the Kubernetes estate, with varying performance and costs, just like Virtual Machines. i.e. the risk of data loss through physical failure is similar to that of Virtual Machines. On most cloud providers you can utilise block-level data storage products that are low latency, high performing, durable, and reliable.
Deploy Multiple User Store Instances
Our ForgeRock Accelerator by default deploys a minimum of two User Store instances in each region in an active-active state, ensuring high availability and data redundancy. Each instance has its own dedicated storage.
Prior to production, we recommend that Customers configure the User Store sizing to support the peak production loads such that in the event a User Store failure, the impact to customers is minimised.
By default all User, Configuration, and Token Stores are deployed and configured with self replication turn on to ensure that all instances are kept in sync. In the case where replication is required across regions or cloud providers, replication servers can be used.
Following the restart of a failed User Store instance, the already running instance will ensure it is up to date by replicating any information that was added, removed or modified while it was unavailable and being restarted.
We provide our customers with a runbook on how to take regular snapshots of the
underlining cloud disks supporting the persistent volumes and how to restore in the event of a disaster. Note we have procedures for AWS, GCP, Azure, AliCloud and OCI.
Note that we recommended customers to move to a multi region and / or multi
cloud model to provide an additional layer of resilience when possible. In the event the underlying storage does fail, the procedures provide an expedient mechanism to recover Customer accounts.