Quality of Service class examples for Splunk pods

You can change the CPU and memory resources and assign different Quality of Service (QoS) classes to your pods.

Guaranteed QoS class

Set equal requests and limits values for CPU and memory to establish a QoS class of Guaranteed.

Example: The minimum resource requirements for a Standalone Splunk Enterprise instance in production are 24 vCPU and 12GB RAM.

apiVersion: enterprise.splunk.com/v4
kind: Standalone
metadata:
  name: example
spec:
  imagePullPolicy: Always
  resources:
    requests:
      memory: "12Gi"
      cpu: "24"
    limits:
      memory: "12Gi"
      cpu: "24"

Burstable QoS class

Set the requests value for CPU and memory lower than the limits value to establish a QoS class of Burstable.

Example: This Standalone Splunk Enterprise instance starts with minimal indexing and search capacity, but can scale up if Kubernetes allocates additional CPU and memory up to the limits values.

apiVersion: enterprise.splunk.com/v4
kind: Standalone
metadata:
  name: example
spec:
  imagePullPolicy: Always
  resources:
    requests:
      memory: "2Gi"
      cpu: "4"
    limits:
      memory: "12Gi"
      cpu: "24"

BestEffort QoS class

With no requests or limits values set for CPU and memory, the QoS class defaults to BestEffort. Do not use the BestEffort QoS class with Splunk Operator.

Pod resources management

CPU throttling

Kubernetes starts throttling CPUs if a pod demand for CPU exceeds the value set in the limits parameter. If your nodes have extra CPU resources available, leaving the limits value unset allows the pods to use more CPUs.

Pod eviction (OOM)

Unlike CPU throttling, Kubernetes evicts a pod from the node if the pod memory demand exceeds the value set in the limits parameter.