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:
- Known Issues for the Splunk Operator
- Prerequisites for the Splunk Operator
- Installing the Splunk Operator
- Creating Splunk Enterprise Deployments
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
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:
- The Deployment Monitoring Console is not currently configured properly for new deployments
Please see the Change Log for a history of changes made in previous releases.
We have tested basic functionality of the Splunk Operator with the following:
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Red Hat OpenShift (4.1)
- Docker Enterprise Edition (3.1)
- Open Source Kubernetes (1.15.1)
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:
splunk/splunk-operator
: The Splunk Operator image (built by this repository)splunk/splunk:8.0
: The Splunk Enterprise image (8.0 or later)splunk/spark
: The Splunk Spark image (used when DFS is enabled)
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.
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
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
metadata:
name: s1
finalizers:
- enterprise.splunk.com/delete-pvc
EOF
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.