Getting Started with the Splunk Operator for Kubernetes

The Splunk Operator for Kubernetes (SOK) makes it easy for Splunk Administrators to deploy and operate Enterprise deployments in a Kubernetes infrastructure. Packaged as a container, it uses the operator pattern to manage Splunk-specific custom resources, following best practices to manage all the underlying Kubernetes objects for you.

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:

COMMUNITY SUPPORTED: 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.

For help, please first read our Frequently Asked Questions

Community Support & Discussions on Slack channel #splunk-operator

File Issues or Enhancements in GitHub splunk/splunk-operator

Known Issues for the Splunk Operator

Please note that the Splunk Operator is undergoing active development and considered to be an “alpha” quality release. We expect significant modifications will be made prior to its general availability, it is not covered by support, and we strongly discourage using it in production.

We are working to resolve the following in future releases:

Please see the Change Log for a history of changes made in previous releases.

Prerequisites for the Splunk Operator

We have tested basic functionality of the Splunk Operator with the following:

While we are only able to test and support a small subset of configurations, the Splunk Operator should work with any CNCF certified distribution of Kubernetes, version 1.12 or later. Setting up, configuring and managing Kubernetes clusters is outside the scope of this guide and Splunk’s coverage of support. For evaluation, we recommend using EKS or GKE.

The Splunk Operator requires three docker images to be present or available to your Kubernetes cluster:

All of these images are publicly available on Docker Hub. If your cluster does not have access to pull from Docker Hub, please see the Required Images Documentation.

The Splunk Operator uses Persistent Volume Claims to store all of your configuration (etc) and event (var) data. If an underlying server fails, Kubernetes will automatically try to recover by restarting Splunk pods on another server 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 be similar to a server restart. The use of Persistent Volume Claims requires that your cluster is configured to support one or more persistent Storage Classes. Please see Setting Up a Persistent Storage for Splunk for more information.

Installing the Splunk Operator

Most users can install and start the Splunk Operator by just running

kubectl apply -f http://tiny.cc/splunk-operator-install

Users of Red Hat OpenShift should read the additional Red Hat OpenShift documentation.

Please see the Advanced Installation Instructions for special considerations, including the use of private image registries, installation at cluster scope, and installing as a regular user (who is not a Kubernetes cluster administrator).

Note: The splunk/splunk:8.0 image is rather large, so we strongly recommend copying this to a private registry or directly onto your Kubernetes workers as per the Required Images Documentation, and following the Advanced Installation Instructions, before creating any large Splunk deployments.

After starting the Splunk Operator, you should 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

To remove all Splunk deployments and completely remove the Splunk Operator, run:

kubectl delete standalones --all
kubectl delete licensemasters --all
kubectl delete searchheadclusters --all
kubectl delete indexerclusters --all
kubectl delete spark --all
kubectl delete -f http://tiny.cc/splunk-operator-install

Creating Splunk Enterprise Deployments

The Standalone resource is used to create a single instance deployment of Splunk Enterprise. For example, run the following command to create a deployment named “s1”:

cat <<EOF | kubectl apply -f -
apiVersion: enterprise.splunk.com/v1alpha2
kind: Standalone
  name: s1
  - enterprise.splunk.com/delete-pvc

The enterprise.splunk.com/delete-pvc finalizer is optional, and may be used to tell the Splunk Operator that you would like it to remove all the Persistent Volumes associated with the instance when you delete it.

Within a few seconds (or minutes if you are pulling the public Splunk images for the first time), you should see a new pod running in your cluster:

$ kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
splunk-operator-7c5599546c-wt4xl   1/1     Running   0          11h
splunk-s1-standalone-0             0/1     Running   0          45s

By default, an admin user password will be automatically generated for your deployment. You can get the password by running:

kubectl get secret splunk-s1-standalone-secrets -o jsonpath='{.data.password}' | base64 --decode

Note: if your shell prints a % at the end, leave that out when you copy the output.

To log into your instance, you can forward port 8000 from your local machine by running:

kubectl port-forward splunk-s1-standalone-0 8000

You should then be able to log into Splunk Enterprise at http://localhost:8000 using the admin account with the password that you obtained from splunk-s1-standalone-secrets.

To delete your deployment, just run:

kubectl delete standalone s1

Standalone is just one custom resource that the Splunk Operator provides. You can find more information about other custom resources and the parameters they support in the Custom Resource Guide.

For additional deployment examples, including clustering, please see Configuring Splunk Enterprise Deployments.

Please see Configuring Ingress for guidance on making your Splunk clusters accessible outside of Kubernetes.