Operator lifecycle
Version-aware installation, stable API selection, CRD ownership, reconciliation, admission, release compatibility, and rollback preparation.
ScyllaDB Operator engineering
ScyllaDB on Kubernetes
In short: ScyllaDB on Kubernetes uses ScyllaDB Operator to reconcile clusters and related lifecycle resources. JusDB DBREs design stable ScyllaCluster APIs, NodeConfig, storage, rack-aware topology, Manager tasks, monitoring, upgrades, and recovery, while documenting the DBA and platform responsibilities that an Operator cannot automate.
Production acceptance covers database behavior through pod, node, volume, zone, and maintenance scenarios—not only Kubernetes resource health.
ScyllaDB Kubernetes scope
Datacenter and rack topology
ScyllaCluster resources, racks, zones, node pools, external seeds, affinity, disruption controls, and maintenance capacity.
Node and storage design
NodeConfig, CPU and memory reservation, disk layout, local versus network storage, filesystems, replacement, and failure rehearsal.
Manager tasks and recovery
Repair and backup scheduling, object storage, credentials, retention, monitoring, isolated restores, and recovery evidence.
Security and observability
TLS, secrets, access, network controls, ScyllaDBMonitoring, actionable alerts, audit needs, and platform ownership.
Scaling and upgrades
Preflight checks, capacity, staged changes, streaming and tablet movement, health gates, pause criteria, rollback, and verification.
Release gates before production
- 01Confirm the current Operator, Kubernetes, and ScyllaDB support matrix.
- 02Benchmark the intended node, CPU, memory, network, and storage path.
- 03Exercise scaling, replacement, upgrade, and application connection behavior.
- 04Restore backup data into isolation and record recovery evidence and ownership.
ScyllaDB Kubernetes questions
What does ScyllaDB Operator manage?
ScyllaDB Operator reconciles ScyllaCluster resources and creates the Kubernetes objects needed for a ScyllaDB datacenter. Current documentation also describes NodeConfig for node preparation, ScyllaDBMonitoring for the monitoring stack, and ScyllaDBManagerTask for supported backup and repair tasks. Resource APIs and support depend on the installed Operator release.
Which ScyllaDB Operator API should a new deployment use?
The current stable Operator documentation identifies ScyllaCluster in the scylla.scylladb.com/v1 API as the stable resource for deploying ScyllaDB on Kubernetes. Before changing an existing deployment, we verify the installed Operator version, CRDs, support matrix, release notes, and conversion path rather than copying manifests from a different release.
Should ScyllaDB use local NVMe or network-attached storage?
Official Operator guidance recommends local NVMe for production performance, while also documenting network-attached storage trade-offs. The decision must include latency, throughput, durability, replacement, attachment, cost, failure domains, recovery, and platform support. We benchmark the actual storage path and rehearse node and volume loss before accepting either design.
How is ScyllaDB topology mapped to Kubernetes?
We map ScyllaDB datacenters and racks to Kubernetes clusters, zones, node pools, labels, affinity, topology spread, and storage. Current Operator guidance describes one ScyllaCluster resource per datacenter and externalSeeds for multi-datacenter connections. The design also accounts for quorum, maintenance capacity, network paths, and failure isolation.
Does the Operator make repair and backup automatic?
The Operator can integrate ScyllaDB Manager and reconcile ScyllaDBManagerTask resources for supported repair or backup tasks. Teams still need schedules, retention, credentials, storage, monitoring, capacity, restore tests, and response procedures. A completed task is operational evidence, but only an isolated restore can demonstrate that the required data is recoverable.
Can ScyllaDB scale on Kubernetes without risk?
No scaling operation is risk-free. Changing members can involve scheduling, storage provisioning, streaming, tablet or token movement, cleanup, and resource pressure. We validate headroom, topology, support, and workload thresholds; stage the change; observe data movement; and define pause or rollback conditions instead of promising automatic, interruption-free scaling.
Technical review and primary sources
ScyllaDB on Kubernetes guidance checked against Operator docs
Review scope: ScyllaDB Operator reconciliation, ScyllaCluster resources, NodeConfig, storage, rack and datacenter topology, ScyllaDB Manager tasks, monitoring, TLS, upgrades, and recovery. Recommendations and outcomes remain specific to the ScyllaDB and Operator releases, workload, schema, topology, infrastructure, and tested failure conditions. Licensing and product terms should be rechecked before procurement or upgrade.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed: . See the team and roles.
- What is ScyllaDB Operator?
Official overview of the stable ScyllaCluster API, controllers, and managed resources.
- ScyllaDB Operator storage
Primary guidance for local and network-attached storage trade-offs on Kubernetes.
- ScyllaDB Operator releases
Current support matrix and release-specific requirements for Operator, Kubernetes, and ScyllaDB.