As a market leader in data analytics, Splunk helps users to make sense of their data.
Containerized workloads are becoming a popular way to implement Splunk. In this demonstration,
we will show you how easy HPE makes it to deploy. Splunk in an environment
built on Kubernetes and RedHat OpenShift container platform.
This can be done on-premises and in hybrid cloud environments.
With our solution, you get all the benefits of containers and the cloud experience
without the risks of moving your sensitive data to the public cloud.
Here is a diagram representing our RedHat OpenShift environment.
Our infrastructure includes two HPE Apollo 2000 platforms with
five HPE ProLiant XL170R Gen10 servers.
Our storage is an HPE Alletra all-flash storage array.
On this infrastructure, we deployed the RedHat OpenShift container platform.
This gives us a five-node cluster containing three master nodes and two worker nodes.
A look at the software stack shows the HPE Alletra storage array on the bottom
with the HPE container storage interface driver called the HPE CSI driver.
The CSI driver allows the OpenShift cluster to dynamically provision volumes on the storage array.
The HPE Alletra is built for very app, from traditional to modern.
It spans workload-optimized systems to deliver architectural flexibility without
the complexity of traditional storage management.
Since the Alletra is built for modern apps, no complex setup is necessary.
All that is needed for this configuration is the storage system,
user name and password for an account with the correct privileges to perform storage management.
We used the Splunk operator to deploy Splunk Enterprise on one of the worker nodes of the cluster.
Now here's Denise to show you how easy it is to set up the storage and deploy Splunk
in the cluster.
The HPE CSI driver is deployed using industry-standard means by way of Helm charts,
operator or object configuration files, depending on the Kubernetes cluster type for this demo,
we used a Jupyter Notebook for displaying live code and YAML files.
We followed the HPE documentation for deploying the HPE CSI driver on RedHat OpenShift.
In order to be able to communicate with the OpenShift cluster,
we can use kubectl, which is the main command line tool for Kubernetes
or we can use open shifts command line
called OC.
kubectl and OC are identical in most ways.
But OC provides extra features that simplify tasks, such as container image deployment
and logging into clusters.
For this demo, we will be using LC.
We head over to our OpenShift Console, go into our kube.admin, drop down menu,
click on copy login command and display our token.
We copy our token and we head back to our Notebook
and paste our log in command and run the command.
So now we are officially logged in into our OpenShift cluster.
We use the OC get node command, to make sure we can communicate
And as Keith mentioned, we can see we have two workers and three masters.
Now we can prepare the cluster with the prerequisites needed to install the HPE CSI operator.
The HPE CSI operator needs to run in privileged mode and needs access to host ports,
host network, and should be able to amount host path volumes. Before deploying the HPE CSI
Operator on OpenShift, the correct security context constraints need to be created.
This allows the CSI operator to be running with these privileges.
First, the security context constraints are downloaded to where you have access to OC and the OpenShift cluster.
We use the curl command to download the security context and named the downloaded security
context constraints YAML file,
hpe-scc-sec.yaml.
Then a new project named hpe-csi-driver is created.
We use the set command to change my-hpe-csi-operator
to the name of the project we just created.
This updates the security context, which allows us to update the security constraints.
We then use OC create to apply the new settings.
We are now ready to install the HPE CSI driver operator.
This can be completed using the web console or command line.
For this demo we will use a web console.
We head over to our console, we go to our operator hub
and then we can search out for hpe-csi and here we can see the hpe-csi-operator,
we click on it, we click on install,
we select the name space where the security context constraints were applied
and then we choose Manual and then click Install,
we click Approve, we view our operator,
and now we create an instance, and, normally, no extra configuration is needed.
So we can just go ahead and click Create.
And now we can go to our Developer view so we can see that our CSI driver
is instantiated correctly.
And here we can see it is.
Once the operator is successfully deployed,
two additional objects are needed to dynamically provision persistent storage.
The secret object contains the HPE Alletra's user name and password for an account with the correct
privileges to perform storage management as well as the IP address of the Alletra.
The storage class provides a way for administrators to describe the types of storage available
for Kubernetes clusters.
We deployed the secret object, then create a storage class referencing the secret object.
We use the OC get sc command to display the new storage class we just created.
We can see our storage class is called hpe-storage-alletra-9000-sc.
Now it's time to display the Splunk operator. First, we download the Splunk operator, YAML file
and create the Splunk operator for a specific name space.
In this case, it will be the specific name space called splunk-operator.
You can also download and install the Splunk operator to run cluster wide. We use our OC
apply -F command to deploy the Splunk operator and when that completes, the Splunk operator is deployed.
We change our context to run under the Splunk operator project and we are ready to deploy the Splunk instance.
To deploy the Splunk instance, we use the YAML fall specified
for a standard Splunk standalone instance with two custom parameters.
The first parameter is the finalizer which just means when the standalone instance is deleted,
the storage volumes on the HPE Alletra are also deleted.
The second parameter references the specific storage class, which was created earlier.
In our demo, the standalone Splunk instance is named s1.
Once deployed the Splunk instance needs a way to be exposed and reachable in the environment.
OpenShift assigned a fully qualified domain name to expose our instance.
Creating the route is done simply by issuing the OC exposed service command.
Once the route has been established, the Splunk instance is now accessible.
To get to the Splunk URL, you issued the following OC get route command.
Before you can log into the instance, you need to run the OC GET secret command to get the password.
Now that we have the password, we can log into our instance.
This installs the certified CSI operator specifically for OpenShift.
You can use this QR code to find the documentation we used.
Thanks, Denise.
It only took a few minutes to successfully deploy Splunk
using containers in a RedHat OpenShift cluster.
This gives you the perfect way to take advantage of the flexibility and benefits
of Splunk in containers.
With our solution, you get the cloud experience,
but you keep your sensitive data on site or in a private hybrid cloud