The ScyllaDB team is pleased to announce the release of ScyllaDB Operator 1.4.
ScyllaDB Operator is an open-source project that helps ScyllaDB Open Source and ScyllaDB Enterprise users run ScyllaDB on Kubernetes. The ScyllaDB operator manages ScyllaDB clusters deployed to Kubernetes and automates tasks related to operating a ScyllaDB cluster, like installation, scale out and downscale, as well as rolling upgrades.
ScyllaDB Operator 1.4 improves its performance, stability and brings new features. As with all of our releases, any API changes are backwards compatible.
- ScyllaDBCluster now supports forcing a rollout with
spec.forceRedeploymentReasonAPI field. Forcing a rollout is useful for operating ScyllaDBClusters, e.g. to reload a new config. (#674)
- ScyllaDBCluster CRD now supports the
observedGenerationAPI concept. (#668)
- ScyllaDBCluster’s status got 2 new fields that help to reliably determine a current state which was previously slightly racy. (#684)
- The operator now uses Kubernetes informers and caches the same way as the native Kubernetes controllers do. This significantly reduces the number of API calls made against the Kubernetes apiserver and makes the operator react faster. Over the run of our e2e suite (about 48 minutes) we have observed 94% reduction of API calls made by the scylla cluster sidecars and 82% reduction of API calls from the controller. In normal circumstances, where most of the system is in a reconciled state, the reduction could be even higher. (#534)
- ScyllaDB is now set up and operated in seedless mode, introduced in ScyllaDB 4.3, ScyllaDB Enterprise 2021.1 This means that no scylla node is special anymore and each of them can be replaced automatically. Previously, replacing seed nodes, always the first 2 nodes in the cluster, required manually promoting a node to become a seed node, degrading the current one and a manual replacement. (#534, #597). More on the removal of the seed node from ScyllaDB here: Seedless NoSQL: Getting Rid of Seed Nodes in ScyllaDB
- The operator now reconciles the full ScyllaDBCluster CR, not just a few individual fields. This allows changing all the properties and sets us up to loosen restrictions on some of the fields that are currently forbidden to be changed. (#534)
- The operator now abides by The Three Laws of Controllers as all the native Kubernetes controllers do. (#534)
- The operator prunes the old resources that are not required anymore. Like in the case of a scaledown where there are no excessive services left behind anymore. (#534)
- The webhook server is now split into its own deployment for better availability, security and separation of concerns. (#534)
- Helper containers are now scheduled in the guaranteed QoS class to allow scylla to get exclusive CPUs. (#662)
For more details checkout the GitHub release notes.
- ScyllaDB >=4.3, ScyllaDB Enterprise >=2021.1
- Kubernetes >=1.19.10
- ScyllaDB manager >=2.2
- ScyllaDB monitoring >=1.0
Upgrading from v1.3.x doesn’t require any extra action. Depending on your deployment method, use `helm upgrade` or `kubectl apply` to update the manifests from v1.4.0 tag while substituting the released image.
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 a Kubernetes Cluster here (including MiniKube example)
- ScyllaDB Operator source (on GitHub)
- ScyllaDB Operator image on DockerHub
- ScyllaDB Operator Helm Chart repository
- ScyllaDB Operator documentation
- ScyllaDB Operator for Kubernetes lesson in ScyllaDB University
- Report a problem
We’ll welcome your feedback! Feel free to open an issue or reach out on the #kubernetes channel in ScyllaDB User Slack.
17 Aug 2021