This page is the reference for the Collectord deployment manifest and the configuration file it ships with — what objects get created in your cluster, how to override settings safely, and a few patterns (secrets, EC2 metadata, dynamic indexes) you’ll likely reach for after the initial install.

collectorforkubernetes.yaml

collectorforkubernetes.yaml

Looking for an older release? Manifests for previous Collectord versions live at github.com/outcoldsolutions/collectord-configurations.

Created Kubernetes Objects

Applying collectorforkubernetes.yaml creates the following objects — everything is scoped to the collectorforkubernetes namespace, and the cluster-level grants are read-only:

Namespace collectorforkubernetes.
ClusterRole collectorforkubernetes with get, list, and watch on the deployment objects Collectord needs to enrich logs and metrics with Kubernetes metadata.
ServiceAccount collectorforkubernetes — the identity Collectord uses to talk to the Kubernetes API.
ClusterRoleBinding collectorforkubernetes binds the service account to the cluster role.
ConfigMap collectorforkubernetes carries the Collectord configuration files.
DaemonSet collectorforkubernetes runs Collectord on non-master nodes.
DaemonSet collectorforkubernetes-master runs Collectord on master nodes.
Deployment collectorforkubernetes-addon is a single Collectord pod that forwards cluster-wide data (events, cluster metrics) once per cluster — not once per node.

The collectorforkubernetes.yaml file itself is heavily commented; read it alongside this page for the full picture of what each input collects.

Collectord configuration

The ConfigMap collectorforkubernetes holds Collectord’s configuration as ini files, with every default value visible inline.

You can override any value through environment variables using this format:

text

1COLLECTOR__{ANY_NAME}={section}__{key}={value}

Environment variables are the quickest way to try things out and debug — but for anything you’re going to keep, edit the configuration file based on the defaults shipped in collectorforkubernetes.yaml. It’s easier to review and easier to diff.

Using secrets to manage configurations

When you don’t want the HEC token or license key sitting in plain text in the manifest, store them in a Kubernetes secret and project them as environment variables. The example below sets up the Splunk HEC token and the license that way.

First, make sure the collectorforkubernetes namespace exists — create it if it doesn’t:

bash

1kubectl create namespace collectorforkubernetes

Create the secret with both values:

bash

1kubectl create secret generic collectorforkubernetes \
2    --namespace collectorforkubernetes \
3    --from-literal=splunk-token="output.splunk__token=B5A79AAD-D822-46CC-80D1-819F80D7BFB0" \
4    --from-literal=license="general__license="

In the YAML manifest, find the env block on each workload (two DaemonSets and one Deployment) and add:

yaml

 1env:
 2- name: COLLECTOR__SPLUNK_TOKEN
 3  valueFrom:
 4    secretKeyRef:
 5      name: collectorforkubernetes
 6      key: splunk-token
 7- name: COLLECTOR__LICENSE
 8  valueFrom:
 9    secretKeyRef:
10      name: collectorforkubernetes
11      key: license

Then apply the manifest as you normally would in the installation guide.

Attaching EC2 Metadata

If you’re running on EC2 and want every event to carry instance-level context — instance ID, instance type, availability zone — point Collectord at the EC2 metadata service. Each entry maps a field name to a path from Instance Metadata and User Data:

ini

1# Include EC2 Metadata (see list of possible fields https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)
2# Should be in format ec2Metadata.{desired_field_name} = {url path to read the value}
3# ec2Metadata.ec2_instance_id = /latest/meta-data/instance-id
4# ec2Metadata.ec2_instance_type = /latest/meta-data/instance-type

For example, to attach ec2_instance_id and ec2_instance_type to every event:

ini

1[general]
2...
3ec2Metadata.ec2_instance_id = /latest/meta-data/instance-id
4ec2Metadata.ec2_instance_type = /latest/meta-data/instance-type
5...

Placeholders in indexes and sources

Static index names work for small clusters, but once you have multiple teams sharing a cluster you’ll often want logs to land in per-team or per-namespace indexes. Collectord lets you use any metadata field as a placeholder in index, source, and sourcetype.

For example, to route each namespace’s logs to its own index:

ini

1[input.files]
2
3index = oc_{{kubernetes_namespace}}

Or to build a structured source path that mirrors the workload hierarchy — useful when a single index holds logs from many namespaces and you want Splunk’s source-based filtering to do the heavy lifting:

ini

1[input.files]
2
3source = /{{kubernetes_namespace}}/{{::coalesce(kubernetes_daemonset_name, kubernetes_deployment_name, kubernetes_statefulset_name, kubernetes_cronjob_name, kubernetes_job_name, kubernetes_replicaset_name, kubernetes_pod_name)}}/{{kubernetes_pod_name}}/{{kubernetes_container_name}}

The coalesce function picks the first non-empty workload name, so a pod owned by a Deployment shows the Deployment name, a standalone pod shows its own name, and so on.

FIPS-compliant images

Since version 26.04, we publish FIPS 140-compliant images alongside the regular images, with a -fips suffix:

outcoldsolutions/collectorforkubernetes:26.04.1-fips

By default, these images use FIPS-certified cryptographic algorithms but still allow fallback to non-approved algorithms when needed. To strictly enforce FIPS 140 mode, set the environment variable GODEBUG=fips140=only — Collectord will crash if any code attempts to use a non-FIPS-140-compliant algorithm.

Collectord logs its FIPS state at startup and includes it in the output of collectord diag and collectord verify.

See FIPS 140-3 Compliance for details on the Go implementation.

Monitoring Kubernetes

Configuration