[RELEASE] ScyllaDB Operator 1.22.0

Release Notes
, ,
1

AD_4nXfBdYbYIPh86HPzd8pKtyLOsaTei2K6kIalInIwibJ-48wr3HBtp5l4u-iuQ1-BDV4xswcaU3AIARAGWsq1jqYLIaebiNjqfrzf8SYqOh0ndneS_SAEJsRC7-Pi4T-PZ_DZW5IVuw
AD_4nXfBdYbYIPh86HPzd8pKtyLOsaTei2K6kIalInIwibJ-48wr3HBtp5l4u-iuQ1-BDV4xswcaU3AIARAGWsq1jqYLIaebiNjqfrzf8SYqOh0ndneS_SAEJsRC7-Pi4T-PZ_DZW5IVuw800×400 10.7 KB

The ScyllaDB team is pleased to announce the release of ScyllaDB Operator 1.22.0.

ScyllaDB Operator is an open-source project that helps you run ScyllaDB on Kubernetes by managing ScyllaDB clusters deployed to Kubernetes and automating tasks related to operating a ScyllaDB cluster, like installation, vertical and horizontal scaling, as well as rolling upgrades.

ScyllaDB Operator 1.22 brings parallel node bootstrap for faster cluster creation, automatic defaulting of API objects through a new mutating admission webhook, and a number of bug fixes and stability improvements.

Parallel node bootstrap

Until now, ScyllaDB Operator always started ScyllaDB nodes one at a time, with each node waiting for the previous one to become ready. For larger clusters, this made the initial bring-up time grow linearly with the cluster size.

ScyllaDB Operator 1.22 introduces parallel node bootstrap. With the new optional enableParallelNodeOperations field on ScyllaCluster.spec and set to true, the nodes of a rack are started without each one waiting for the previous ordinal to become ready, and all missing racks are created at once - significantly cutting the time it takes to bring up a cluster. Creating new racks still waits for any in-flight scaling, update, or upgrade of the existing racks to settle first.

Parallel bootstrap can be enabled in Operator with ScyllaDB 2026.2 or newer.

Newly created clusters have parallel bootstrap enabled by default when their ScyllaDB image supports it (>= 2026.2), while existing clusters keep bootstrapping sequentially and can opt in explicitly. The setting can be changed on a running cluster without disruption to existing nodes.

Looking ahead: the scope of enableParallelNodeOperations is expected to widen in an upcoming version of ScyllaDB Operator, where it will most likely also allow decommissioning nodes in parallel. In other words, enabling it now opts you into parallel node operations as a whole – setting it to true today may take effect for more operations after a future upgrade. (#3568, #3578, #3588)

Admission webhook now applies API defaults

The operator’s webhook server now serves a mutating admission webhook that applies API defaults to ScyllaClusters when they are created. A matching MutatingWebhookConfiguration is included in the operator’s manifests. (#3579)

With defaulting happening at admission time, the effective values are persisted in the stored object, so what you see with kubectl get is what the operator acts on. This is also the mechanism behind parallel bootstrap being enabled by default for newly created clusters: on creation, enableParallelNodeOperations is set to true when the ScyllaDB image tag is a semver-parseable version supporting parallel bootstrap, and the persisted value then stays in effect across image changes until you explicitly change it.

Bug fixes

This release also delivers a set of bug fixes improving rollout reliability and cleanup correctness:

  • Fixed ScyllaDBDatacenter rollouts getting stuck when a new rack was inserted before existing racks while an existing rack was still progressing. (#3513)

  • Fixed nodes being skipped by cleanup after the token ring changed. Every node is now cleaned up once the ring changes; note that this increases the number of cleanup jobs created at once from N-1 to N for an N node cluster. (#3574)

  • Fixed the ScyllaDBDatacenter controller discarding failures to sync ScyllaDBDatacenterNodesStatusReport objects, which lost the retry with backoff for failed syncs. (#3587)

  • Fixed the sidecar returning spurious errors during node decommission. (#3538)

Other notable changes

  • ScyllaDB Operator now runs scylladb-node-exporter as a dedicated sidecar container for ScyllaDB clusters running version 2026.3 or later, since these versions no longer bundle node-exporter. The node-exporter container image is configurable via ScyllaOperatorConfig.spec.scyllaDBNodeExporterImage. (#3482)

  • The bootstrap barrier now only takes into account nodes that have already joined the ScyllaDB cluster and own tokens in it. ScyllaDBDatacenterNodesStatusReport reflects the same: a node appears in it only once it’s a member of the ScyllaDB cluster, so the absence of an entry no longer implies the corresponding node is missing or unhealthy. (#3530)

  • The default ScyllaDB Manager version was updated from 3.11.2 to 3.12.0. (#3520)

For more changes and details, check out the changelog.

Upgrade instructions

For instructions on upgrading ScyllaDB Operator to 1.22, please refer to the Upgrading ScyllaDB Operator section of the documentation. This release requires no version-specific upgrade steps.

Supported versions

  • ScyllaDB 2025.1, 2025.3 - 2026.3

  • Red Hat OpenShift 4.20

  • Kubernetes 1.33 - 1.36

  • Container Runtime Interface API v1

  • ScyllaDB Manager 3.7 - 3.9

Getting started with ScyllaDB Operator

  • ScyllaDB Operator Documentation

  • Learn how to deploy ScyllaDB on Google Kubernetes Engine (GKE) here

  • Learn how to deploy ScyllaDB on Amazon Elastic Kubernetes Engine (EKS) here

  • Learn how to deploy ScyllaDB on Oracle Kubernetes Engine (OKE) here

  • Learn how to deploy ScyllaDB on OpenShift (OCP) here

  • Learn how to deploy ScyllaDB on a Kubernetes Cluster here

Related links

Your feedback is always welcome! Feel free to open an issue or reach out on the #scylla-operator channel in ScyllaDB User Slack.

Regards,

The ScyllaDB Operator Team