The Splunk Operator for Kubernetes enables you to quickly and easily deploy Splunk Enterprise on your choice of private or public cloud provider. The Operator simplifies scaling and management of Splunk Enterprise by automating administrative workflows using Kubernetes best practices.
This guide is intended to help new users get up and running with the Splunk Operator for Kubernetes. It is divided into the following sections:
SPLUNK SUPPORTED: The Splunk Operator for Kubernetes is a supported method for deploying distributed Splunk Enterprise environments using containers.
COMMUNITY DEVELOPED: Splunk Operator for Kubernetes is an open source product developed by Splunkers with contributions from the community of partners and customers. This unique product will be enhanced, maintained and supported by the community, led by Splunkers with deep subject matter expertise. The primary reason why Splunk is taking this approach is to push product development closer to those that use and depend upon it. This direct connection will help us all be more successful and move at a rapid pace.
If you’re interested in contributing to the SOK open source project, review the Contributing to the Project page.
Community Support & Discussions on Slack channel #splunk-operator-for-kubernetes
File Issues or Enhancements in GitHub splunk/splunk-operator
Review the Change Log page for a history of changes in each release.
The Splunk Operator should work with any CNCF certified distribution of Kubernetes. We do not have platform recommendations, but this is a table of platforms that our developers, customers, and partners have used successfully with the Splunk Operator.
|Splunk Development & Testing Platforms||Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE)|
|Customer Reported Platforms||Microsoft Azure Kubernetes Service (AKS), Red Hat OpenShift|
|Partner Tested Platforms||HPE Ezmeral|
|Other Platforms||CNCF certified distribution|
Each Splunk Operator release has specific Splunk Enterprise compatibility requirements. Before installing or upgrading the Splunk Operator, review the Change Log to verify version compatibility with Splunk Enterprise releases.
Apps and add-ons can be installed using the Splunk Operator by following the instructions given at Installing Splunk Apps. Premium apps such as Enterprise Security and IT Service Intelligence are currently not supported.
The Splunk Operator requires these docker images to be present or available to your Kubernetes cluster:
splunk/splunk-operator: The Splunk Operator image built by this repository or the official release (1.0.3 or later)
splunk/splunk:<version>: The Splunk Enterprise image (8.2.2 or later)
Review the Change Log page for a history of changes and Splunk Enterprise compatibility for each release.
The resource guidelines for running production Splunk Enterprise instances in pods through the Splunk Operator are the same as running Splunk Enterprise natively on a supported operating system and file system. Refer to the Splunk Enterprise Reference Hardware documentation for additional details. We would also recommend following the same guidance on Splunk Enterprise for disabling Transparent Huge Pages (THP) for the nodes in your Kubernetes cluster. Please be aware that this may impact performance of other non-Splunk workloads.
Based on Splunk Enterprise Reference Hardware documentation, a summary of the minimum reference hardware requirements is given below.
|Standalone||Search Head / Search Head Cluster||Indexer Cluster|
|Each Standalone Pod: 12 Physical CPU Cores or 24 vCPU at 2Ghz or greater per core, 12GB RAM.||Each Search Head Pod: 16 Physical CPU Cores or 32 vCPU at 2Ghz or greater per core, 12GB RAM.||Each Indexer Pod: 12 Physical CPU cores, or 24 vCPU at 2GHz or greater per core, 12GB RAM.|
Splunk Operator does not support vCPU licensing.
In addition to the guidelines provided in the reference hardware, Kubernetes Quality of Service Classes can be used to configure CPU/Mem resources allocations that map to your service level objectives. For further information on utilizing Kubernetes Quality of Service (QoS) classes, see the table below:
||When the CPU and memory
||When the CPU and memory
Examples on how to implement these QoS are given at Examples of Guaranteed and Burstable QoS section.
The Splunk Operator uses Kubernetes Persistent Volume Claims to store all of your Splunk Enterprise configuration (“$SPLUNK_HOME/etc” path) and event (“$SPLUNK_HOME/var” path) data. If one of the underlying machines fail, Kubernetes will automatically try to recover by restarting the Splunk Enterprise pods on another machine that is able to reuse the same data volumes. This minimizes the maintenance burden on your operations team by reducing the impact of common hardware failures to the equivalent of a service restart. The use of Persistent Volume Claims requires that your cluster is configured to support one or more Kubernetes persistent Storage Classes. See the Setting Up a Persistent Storage for Splunk page for more information.
The Kubernetes infrastructure must have access to storage that meets or exceeds the recommendations provided in the Splunk Enterprise storage type recommendations at Reference Hardware documentation - what storage type to use for a given role? In summary, Indexers with SmartStore need NVMe or SSD storage to provide the necessary IOPs for a successful Splunk Enterprise environment.
For production environments, we are requiring the use of Splunk SmartStore. As a Splunk Enterprise deployment’s data volume increases, demand for storage typically outpaces demand for compute resources. Splunk’s SmartStore Feature allows you to manage your indexer storage and compute resources in a cost-effective manner by scaling those resources separately. SmartStore utilizes a fast storage cache on each indexer node to keep recent data locally available for search and keep other data in a remote object store. Look into the SmartStore Resource Guide document for configuring and using SmartStore through operator.
A Kubernetes cluster administrator can install and start the Splunk Operator by running:
kubectl apply -f https://github.com/splunk/splunk-operator/releases/download/1.0.3/splunk-operator-install.yaml
The Advanced Installation Instructions page offers guidance for advanced configurations, including the use of private image registries, installation at cluster scope, and installing the Splunk Operator as a user who is not a Kubernetes administrator. Users of Red Hat OpenShift should review the Red Hat OpenShift page.
Note: We recommended that the Splunk Enterprise Docker image is copied to a private registry, or directly onto your Kubernetes workers before creating large Splunk Enterprise deployments. See the Required Images Documentation page, and the Advanced Installation Instructions page for guidance on working with copies of the Docker images.
After the Splunk Operator starts, you’ll see a single pod running within your current namespace:
$ kubectl get pods NAME READY STATUS RESTARTS AGE splunk-operator-75f5d4d85b-8pshn 1/1 Running 0 5s
For information on upgrading the Splunk Operator, see the How to upgrade Splunk Operator and Splunk Enterprise Deployments page.
Standalone custom resource is used to create a single instance deployment of Splunk Enterprise. For example:
cat <<EOF | kubectl apply -f - apiVersion: enterprise.splunk.com/v2 kind: Standalone metadata: name: s1 finalizers: - enterprise.splunk.com/delete-pvc EOF
enterprise.splunk.com/delete-pvc finalizer is optional, and tells the Splunk Operator to remove any Kubernetes Persistent Volumes associated with the instance if you delete the pod.
Within a few minutes, you’ll see new pods running in your namespace:
$ kubectl get pods NAME READY STATUS RESTARTS AGE splunk-operator-7c5599546c-wt4xl 1/1 Running 0 11h splunk-default-monitoring-console-0 1/1 Running 0 30s splunk-s1-standalone-0 1/1 Running 0 45s
Note: if your shell prints a
% at the end, leave that out when you copy the output.
kubectl port-forward splunk-s1-standalone-0 8000
Get your passwords for the namespace. The Splunk Enterprise passwords used in the namespace are generated automatically. To learn how to find and read the passwords, see the Reading global kubernetes secret object page.
Log into Splunk Enterprise at http://localhost:8000 using the
admin account with the password.
To delete your standalone deployment, run:
kubectl delete standalone s1
Standalone custom resource is just one of the resources the Splunk Operator provides. You can find more custom resources and the parameters they support on the Custom Resource Guide page.
For additional deployment examples, including Splunk Enterprise clusters, see the Configuring Splunk Enterprise Deployments page.
For additional guidance on making Splunk Enterprise ports accessible outside of Kubernetes, see the Configuring Ingress page.
If you are a Splunk Enterprise customer with a valid support entitlement contract and have a Splunk-related question, you can open a support case on the https://www.splunk.com/ support portal.