Resource management

The Stackable Data Platform and its operators deploy their products in containers within Pods using StatefulSets or DaemonSets. In order for the Kubernetes scheduler to select a suitable Node for a Pod, resource requests and limits for CPU and memory can be specified. The Kubernetes scheduler ensures that the sum of the CPU and memory requests does not exceed the capacity of a given Node.

Terminology

The most commonly defined resources are CPU and memory (RAM). Keep in mind that there are other resources as well. For more information have a look at the Kubernetes documentation on resources.

CPU

Requests

The CPU request defines which containers are allowed to have more CPU resources in case of a shortage of compute resources.

Limits

The CPU limit is a hard bound on how much CPU resources the container can use. The Linux kernel checks to see if the limit is exceeded and waits if this is the case to resume the process.

Memory

Requests

The memory request is used during Kubernetes scheduling and checks which Nodes offer sufficient memory for a Pod to be scheduled.

Limits

The memory limit is a hard bound. If a container tries to use more memory than specified, the container is usually marked for restart. To avoid the restart it is critical to specify sufficient resources.

Storage

Some Stackable products require data storage. This is done using Persistent Volume Claims where the size of storage can be specified.

Kubernetes resource requests

In Kubernetes, you can specify resource requests and limits within containers of Pods.

---
apiVersion: v1
kind: Pod
metadata:
  name: stackable
spec:
  containers:
  - name: stackable
    image: stackable:0.1.0
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

This Pod/container will be scheduled on a Node that has at least 64Mi of free memory. It is allowed to use a maximum amount of 128Mi of memory or will be restarted if this value is exceeded. It can not use more CPU resources than 500m (which is half of a physical or virtual core), but has a guaranteed CPU resources of 250m.

Stackable resource requests

CPU and memory

Stackable operators handle resource requests in a sligtly different manner than Kubernetes. Resource requests are defined on role or role group level. On a role level this means that by default, all workers will use the same resource requests and limits. This can be further specified on role group level (which takes priority to the role level) to apply different resources.

This is an example on how to specify CPU and memory resources using the Stackable Custom Resources:

---
apiVersion: example.stackable.tech/v1alpha1
kind: ExampleCluster
metadata:
  name: example
spec:
  workers: # role-level
    config:
      resources:
        cpu:
          min: 300m
          max: 600m
        memory:
          limit: 3Gi
    roleGroups: # role-group-level
      resources-from-role: # role-group 1
        replicas: 1
      resources-from-role-group: # role-group 2
        replicas: 1
        config:
          resources:
            cpu:
              min: 400m
              max: 800m
            memory:
              limit: 4Gi

In this case, the role group resources-from-role will inherit the resources specified on the role level, resulting in a maximum of 3Gi memory and 600m CPU resources.

The role group resources-from-role-group has a maximum of 4Gi memory and 800m CPU resources (which overrides the role CPU resources).

For Java products the actual used heap memory is lower than the specified memory limit due to other processes in the Container requiring memory to run as well. Currently, 80% of the specified memory limit is passed to the JVM.

For memory, only a limit can be specified, which will be set as memory request and limit in the container. This is to always guarantee a container the full amount memory during Kubernetes scheduling.

Storage

This is an example on how to specify storage resources using the Stackable Custom Resources:

---
apiVersion: example.stackable.tech/v1alpha1
kind: ExampleCluster
metadata:
  name: example
spec:
  workers: # role-level
    config:
      resources:
        storage:
          data: # name of the storage
            capacity: 3Gi
    roleGroups: # role-group-level
      resources-from-role: # role-group 1
        replicas: 1
      resources-from-role-group: # role-group 2
        replicas: 1
        config:
          resources:
            storage:
              data: # name of the storage
                capacity: 4Gi

In this case, the role group resources-from-role will inherit the resources specified on the role level. Resulting in a 3Gi storage space for data.

The role group resources-from-role-group has maximum of 4Gi storage space for data (which overrides the role resources).

Stackable operators use different names (data in this example) for their storage specification. This is documented in the operator specific documentation.

StorageClass

A StorageClass defines a type of storage with certain properties. The StorageClasses that are available on a Kubernetes cluster are configured by the cluster administrator. Different classes can be configured to provide different levels of reliability or speed, or be configured to be more suited for read or write heavy loads. This configuration is either done in the storage backend or Kubernetes settings (find more information in the Kubernetes documentation).

For Stackable resources, setting a StorageClass is not mandatory; if a StorageClass is not set, the default StorageClass will be used. If you want to use a specific StorageClass for a particular storage, the StorageClass can be set on the resource:

...
resources:
  storage:
    data: # name of the storage
      capacity: 4Gi
      storageClass: my-storage-class