Set up an Edge Processor in a Kubernetes cluster

Deploy Edge Processor to a Kubernetes cluster using the Edge Processor Helm chart on GitHub. The chart packages all required resources, such as StatefulSet, Service, ConfigMap, and any additional resources into a single, versioned release to consolidate deployment and lifecycle management.

For container deployments outside of Kubernetes, see Set up an Edge Processor in a Docker container.

Before you begin, fulfill the following prerequisites:

  • Access to a functioning Splunk Cloud Platform tenant.

  • Permissions to deploy resources in a Kubernetes cluster version 1.25 or higher.

  • Helm version 3.x or higher installed on the machine used to deploy the Helm chart.

  • Scaling down is turned off by default. The chart's HorizontalPodAutoscaler field is configured to scale up aggressively, but not scale down automatically. Because each replica maintains a local event queue on its PVC, terminating a pod before its queue fully drains will delay those events until the pod is rescheduled and reattaches to its volume. If you need to reduce replica count, either wait for queues to drain before scaling down manually, or configure a gradual scale-down policy with a stabilization window long enough for queues to clear.

  • Port changes made in the Edge Processor Shared settings page are not automatically propagated to existing Helm releases. If the ports configured in the UI diverge from those specified in your chart, the Service routes traffic to container ports that the Edge Processor service is no longer listening on, resulting in data loss. To prevent this, run the helm upgrade command with the updated values any time S2S, HEC, or Syslog ports are changed.

  • The default Service type is ClusterIP, meaning Edge Processor is reachable only from within the Kubernetes cluster. No external traffic can reach it directly. If your data sources live outside the cluster, like on-premise forwarders or external syslog sources, change the Service type to make the deployment reachable. For example, set service.type: LoadBalancer to provision a cloud load balancer or service.type: NodePort to expose the Service on a static port across all cluster nodes. Additionally, you can pass cloud-specific annotations for internal and external load balancers through service.annotations, if needed.

Architecture overview

Edge Processor deploys as a StatefulSet, rather than as a deployment. Doing so provides the following advantages:

  • Stable network identifiers: Each pod receives a predictable, human-readable host name like splunk-edge-processor-0, which is displayed as the instance name in the tenant's web UI.

  • Persistent storage: Each pod maintains its own PersistentVolumeClaim, enabling Edge Processor instances to preserve their event queues across pod restarts.

  • Parallel scaling: The Splunk Helm chart sets the podManagementPolicy to Parallel, which scales pods simultaneously rather than sequentially. Because of this, the cluster can respond faster to ingestion volume changes.

See the following diagram of an architecture overview of Edge Processor in a Kubernetes cluster.
The following image displays an architecture overview of Edge Processor in a Kubernetes cluster.

Shared service principal

During installation, a one-time Kubernetes Job provisions a service principal, which is used to interact with other Splunk Cloud Platform services. The generated credentials are then stored in a Kubernetes Secret and mounted into each pod at /opt/splunk-edge/etc/principal.yaml, allowing all replicas in the StatefulSet to share the same service principal.

Deployment and port exposure

By default, the chart deploys 3 replicas, enables horizontal pod autoscaling with target utilization thresholds of 70% for CPU and 80% for memory, and exposes the following ports:

Port Protocol Description
8088 TCP HTTP Event Collector (HEC)
9997 TCP Splunk forwarders
10514 TCP or UDP Syslog
Note: Port changes made using the Edge Processor's Shared Settings page do not automatically propagate to Kubernetes. You must update your corresponding Service resource, such as by using the helm upgrade command, to reflect the latest values.

Helm chart installation

Perform the following tasks to install the Splunk Helm chart.

Add the Helm repository
CODE 
helm repo add splunk https://splunk.github.io/edge-processor-helm-charts

Deploy the Helm chart

Find the following values in your tenant's web UI:

  • TENANT: Typically matches the ID of the Splunk Cloud Platform deployment paired with the tenant and appears in the top-right after your username.

  • GROUP_ID: Found by selecting a processor from the Edge Processors page, then copying its associated ID field, like 431e1ead-fd5b-4af8-ac89-ccae2ae81eda.

  • TOKEN: Navigate to the Edge Processors page, and select or create a processor. Choose Actions > Install/Uninstallfrom the drop-down menu in the top- right corner, then set the Instance type to Kubernetes. Find the token in the resulting script.

Using the command line, run the following command and provide each of the following values:
CODE 
helm install <release-name> splunk/edge-processor --version <version> \
  --namespace <target-namespace> \
  --set config.REGION=<region> \
  --set config.TENANT=<tenant-id> \
  --set config.GROUP_ID=<edge-processor-id> \
  --set config.TOKEN=<access-token>
Note: If --namespace is not specified, Helm installs the release into the namespace configured in your current Kubernetes context, resolving to default if none is set.
Override default values
The Splunk Helm chart is preconfigured with best practice defaults for most configuration settings. To customize a release, create a separate overwritten-values.yaml file that contains only the parameters you wish to override, and pass it using the --values flag. At render time, Helm merges your file with the chart's defaults, applying your overrides while preserving unspecified settings. For example:
PYTHON 
# overwritten-values.yaml

# (Optional) Specify required config values here
# rather than providing them via the `--set` flag
config:
  TENANT: splunk-foobar
  GROUP_ID: 431e1ead-fd5b-4af8-ac89-ccae2ae81eda
  TOKEN: ey···QmnGg

# Expect forwarded events to be received on port 9998
# (instead of 9997). Also, explicitly disable ingestion
# from the HTTP Event Collector (HEC) and Syslog
ports:
  forwarder:
    port: 9998
  hec:
    enabled: false
  syslog:
    enabled: false

# Scale the number of replicas managed by the StatefulSet
# from 3 → 10 to process higher event volumes by default
deployment:
  replicaCount: 10
CODE 
helm install <release-name> splunk/edge-processor --version <version> \
  --namespace <target-namespace> \
  --values overwritten-values.yaml

For a complete list of available configuration options, inspect the chart's default values by running the helm show values splunk/edge-processor command or see https://github.com/splunk/edge-processor-helm-charts/blob/main/charts/edge-processor/values.yaml on GitHub.

Upgrade Helm chart

As a best practice, keep your deployment aligned with the latest stable chart release. New versions can include bug fixes, security patches, updates to the Edge Processor container image, as well as enhancements to the chart itself.

Run the following command to check for available versions:
CODE 
helm repo update
helm search repo splunk/edge-processor --versions
Run the following command to upgrade using a values file:
CODE 
helm upgrade <release-name> splunk/edge-processor --version <version> \
  --namespace <target-namespace> \
  --values overwritten-values.yaml
Run the following command to upgrade while retaining the currently-deployed configuration:
CODE 
helm upgrade <release-name> splunk/edge-processor --version <version> \
  --namespace <target-namespace> \
  --reuse-values
Note: During an upgrade, the StatefulSet uses a rolling update strategy, replacing pods one at a time to maintain availability. This behavior is independent of podManagementPolicy, which applies only to scaling operations.

Uninstall Helm chart

Uninstalling a Helm release removes the Kubernetes resources managed by the chart, but PersistentVolumeClaims (PVCs) are not automatically deleted. Instead, they are retained to preserve persistent data and prevent accidental loss, such as when a release is uninstalled unintentionally or as part of a reinstall workflow.

To uninstall the release, run the following command:
CODE 
helm uninstall <release-name> --namespace <target-namespace>

Clean up persistent data

The retained PVCs store each instance's persistent state, including its local event queue and identity information. Deleting them permanently removes all queued events and erases the instance's stored identity.

To fully remove the deployment and its data, delete the PVCs manually:
CODE 
kubectl delete pvc -l app.kubernetes.io/name=<release-name> -n <target-namespace>

Remove namespace

If your Helm chart is deployed in a dedicated namespace that is no longer needed, you can delete the namespace:
CODE 
kubectl delete namespace <target-namespace>
Note: This action is irreversible. Deleting a namespace removes all resources in it, not just those managed by the chart. Perform this action only if no other important workloads are actively running there.