Was this page helpful?
OverviewCopy
KubernetesCopy
Scylla Operator is a set of controllers and Kubernetes API extensions. Therefore, we assume you either have an existing, conformant Kubernetes cluster and/or are already familiar with how a Kubernetes cluster is deployed and operated.
Scylla Operator controllers and API extensions may have dependencies on some of the newer Kubernetes features and APIs that need to be available. More over, Scylla Operator implements additional features like performance tuning, some of which are platform/OS specific. While we do our best to implement these routines as generically as possible, sometimes there isn’t any low level API to base them on and they may work only on a subset of platforms.
Caution
We strongly recommend using a supported Kubernetes platform. Issues on unsupported platforms are unlikely to be addressed.
Note
Before reporting an issue, please see our support page and troubleshooting installation issues
Scylla Operator componentsCopy
Scylla Operator consists of multiple components that need to be installed in your cluster. This is by no means a complete list of all resources, rather it aims to show the major components in one place.
Note
Depending on which storage provisioner you choose, the local-csi-driver may be replaced or complemented by a different component.
Scylla OperatorCopy
Scylla Operator contains the Kubernetes API extensions and corresponding controllers and admission hooks that run inside scylla-operator namespace.
You can learn more about the APIs in resources section and the generated API reference.
ScyllaDB ManagerCopy
ScyllaDB Manager is a global deployment that is responsible for operating all ScyllaClusters and runs inside scylla-manager namespace.
Scylla Operator syncs the ScyllaCluster metadata, backup and repair tasks into the manager (and vice versa). This way it allows avoiding direct access to the shared instance by users. Unfortunately, at this point, other task like restoring from a backup require executing into the shared ScyllaDB Manager deployment which effectively needs administrator privileges.
ScyllaDB Manager uses a small ScyllaCluster instance internally and thus depends on the Scylla Operator deployment and the CRD it provides.
NodeConfigCopy
NodeConfig is a cluster-scoped custom resource provided by Scylla Operator that helps you set local disks on Kubernetes nodes, create and mount a file system, configure performance tuning and more.
ScyllaOperatorConfigCopy
ScyllaOperatorConfig is a cluster-coped custom resource provided by Scylla Operator to help you configure Scylla Operator. It helps you configure auxiliary images, see which ones are in use and more.
Local CSI driverCopy
ScyllaDB provides you with a custom Local CSI driver that lets you dynamically provision PersistentVolumes, share the disk space but still track the capacity and use quotas.
NotesCopy
Note
Before reporting and issue, please see our support page and troubleshooting installation issues
Installation modesCopy
Depending on your preference, there is more than one way to install Scylla Operator and there may be more to come / or provided by other parties or supply chains.
At this point, we provide 2 ways to install the operator - GitOps/manifests and Helm charts. Given we provide only a subset of helm charts for the main resources and because Helm can’t update CRDs - you still have to resort to using the manifests or GitOps anyway. For a consistent experience we’d recommend using the GitOps flow which will also give you a better idea about what you actually deploy and maintain.
Caution
Do not use rolling tags (like latest, 1.14) with our manifests in production.
The manifests and images for a particular release are tightly coupled and any update requires updating both of them, while the rolling tags may surprisingly update only the images.
You should always use the full version (e.g. 1.14.0) and/or using the corresponding sha reference.
Note
To avoid races, when you create a CRD, you need to wait for it to be propagated to other instances of the kubernetes-apiserver, before you can reliably create the corresponding CRs.
Note
When you create ValidatingWebhookConfiguration or MutatingWebhookConfiguration, you have to wait for the corresponding webhook deployments to be available, or the kubernetes-apiserver will fail all requests for resources affected by these webhhok configurations. Also note that some platforms have non-conformant networking setups by default that prevents the kube-apiserver from talking to the webhooks - see our troubleshooting guide for more info.
GitOpsCopy
We provide a set of Kubernetes manifest that contain all necessary objects to apply to your Kubernetes cluster.
Depending on your preference applying them may range from using git with a declarative CD to git and kubectl.
To keep the instructions clear for everyone we’ll demonstrate applying the manifests using kubectl, that everyone is familiar with and is able to translate it to the GitOps platform of his choosing.
For details, please see the dedicated section describing the deployment using GitOps (kubectl).
HelmCopy
Warning
Helm doesn’t support managing CustomResourceDefinition resources (#5871, #7735). Helm only creates CRDs on the first install and never updates them, while keeping the CRDs up to date (with any update) is absolutely essential. In order to update them, users have to do it manually every time.
For details, please see the dedicated section describing the deployment using Helm.
UpgradesCopy
Please see the dedicated section describing the upgrade process.