… it’s at least a bigger number, anyway. Here’s a status update on the Backube projects and where they are going.

:stopwatch: SnapScheduler :stopwatch:

SnapScheduler had a good run during the first half of 2020. The most recent release (v1.1.1) was included in OperatorHub and is available on OpenShift clusters that are version 4.6+. This is in addition to the Helm chart that has been available for some time.

With Kubernetes 1.20, snapshots have now moved out of beta, and it’s time to take stock of the Kubernetes versions that we will continue to support. Currently, SnapScheduler is supported from Kube 1.13 up to the latest (1.20), but with snapshots moving to GA, it’s time to trim this list down a bit.

Here’s the plan:

  • One more release of SnapScheduler v1…
    This will provide an opportunity to add a few small features while keeping the backward compatibility. The v1.y release will continue to have the dual support for alpha and beta snapshot APIs, so it will likely continue to work until the beta snapshot support in Kubernetes is removed.
  • Onward to SnapScheduler v2…
    SnapScheduler v2 will only support the v1 snapshot API, limiting it to Kubernetes 1.20 and beyond. There is currently no plan to change the SnapshotSchedule CR with this switch, so moving configurations from v1 to v2 should be largely seamless. Removing the alpha and beta APIs will slim down the code and make it more maintainable for the future.

:pen: Scribe :pen:

Scribe is a new operator that just got started in the last couple of months. It’s goal is to provide asynchronous data replication, in a storage system independent way.

We’re all familiar with storage systems that support data replication— whether to provide a remote copy for disaster recovery, to facilitate data migration, or for replicating to a central data lake for processing. Some of them even work in Kube and allow cross-cluster replication. BUT… Your data isn’t actually mobile if you’re locked into a single vendor.

With Scribe, we’re building asynchronous replication at the Kubernetes level. This means:

  • Configuration is handled via CustomResources.
  • Scribe requires only CSI features (snapshots & clones), so the underlying storage doesn’t need to support replication. Snaps and clones aren’t even strictly necessary, but the guarantees are fewer.
  • Scribe can replicate between different storage providers. Use the most efficient storage for your platform and replicate across them.

If you’re interested in more information about how we see it being used, check out some of the use cases we’re targeting.

An initial release plus a Helm chart for Scribe will be coming in the near future, so stay tuned!

Scribe is under heavy development, and while trying it out and providing feedback would be greatly appreciated, it shouldn’t be you current DR plan— just your future one!