Was this page helpful?
Caution
You're viewing documentation for an unstable version of ScyllaDB Operator. Switch to the latest stable version.
Kubernetes prerequisites¶
Because ScyllaDB Operator aims to leverage the best performance available, there are a few extra steps that need to be configured on your Kubernetes cluster.
Kubelet¶
Static CPU policy¶
By default, kubelet uses the CFS quota to enforce pod CPU limits. When the Kubernetes node runs a lot of CPU-bound Pods, the processes can move over different CPU cores, depending on whether the Pod is throttled and which CPU cores are available. However, kubelet may be configured to assign CPUs exclusively by setting the CPU manager policy to static.
To get the best performance and latency ScyllaDB Pods should run under static CPU policy to pin cores.
Note
Configuring kubelet options is provider specific. We provide a few examples for the major ones in this section, otherwise please consult the documentation for your Kubernetes platform.
GKE allows you to set static CPU policy using a node system configuration:
kubeletConfig:
cpuManagerPolicy: static
eksctl allows you to set static CPU policy for each node pool like:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
# ...
nodeGroups:
- name: scylla-pool
kubeletExtraConfig:
cpuManagerPolicy: static
In Red Hat OpenShift, you can configure CPU Manager policy to static by creating a KubeletConfig resource and configuring it to select the MachineConfigPool dedicated to your ScyllaDB nodes.
Please follow the steps outlined in the Red Hat documentation: Setting up CPU Manager.
Nodes¶
Labels¶
For the purposes of the installation guides, we assume that the nodes meant to run ScyllaDB (ScyllaClusters) have label scylla.scylladb.com/node-type=scylla.
Packages¶
xfsprogs¶
ScyllaDB Operator’s NodeConfig controller requires xfsprogs to be installed on the Kubernetes
nodes to format the local disks with XFS file system.