Run a Second Edge Delta Agent in the Same Cluster

Overview

Running two Edge Delta DaemonSets in a single Kubernetes cluster is supported, but several chart resources are shared or non-namespaced, so a second install needs a few overrides to avoid collisions. This page covers deploying a second node agent that reports to a different Edge Delta account, for example an Edge Delta AI Teammate proof of concept (POC) in staging next to an existing production agent.

Before you begin

The single most important rule is to give the second deployment both a distinct Helm release name and a distinct namespace. A distinct namespace on its own is not sufficient, because some resources are cluster-scoped (see Use a distinct release name).

You will also need the API key for the second Edge Delta account. This key is passed to the chart through secretApiKey.value and identifies the account the agent reports to.

1. Use a separate namespace

A few chart resources have hardcoded names that include neither the release name nor the namespace:

• the ed-data-supply-svc, ed-aggregator-svc, and ed-httprecorder-svc Services
• the aggregator-data PersistentVolumeClaim (PVC)

These are namespaced resources, so installing the second agent into its own namespace (with --create-namespace) prevents them from colliding with the first install. The chart also creates a ConfigMap named after the release; a distinct release name already keeps it separate, and a separate namespace isolates it as well.

Note: The aggregator and HTTP-recorder resources only render when those features are enabled (both are off by default), but the pattern holds regardless, so always use a separate namespace.

2. Use a distinct release name

The chart creates a ClusterRole and a ClusterRoleBinding whose names come from the Helm release name (via the edgedelta.fullname helper). These objects are cluster-scoped, so the namespace is not part of their name. Two releases that share a name therefore collide with Helm’s invalid ownership metadata error, even when they live in different namespaces.

The same applies to the OpenShift SecurityContextConstraints object and to any PriorityClass you define.

Always give the second release a unique name, for example edgedelta-staging.

3. Isolate the persisting cursor path

The persisting cursor is enabled by default (persistingCursorProps.enabled: true) and mounts the node hostPath /var/lib/edgedelta (persistingCursorProps.hostMountPath), where the agent stores its cursor.json offset file. Two agents running on the same node that share this path will corrupt each other’s cursor state.

Override the cursor path for the second release so each agent gets its own directory, for example /var/lib/edgedelta-staging. Set both values:

persistingCursorProps:
  hostMountPath: /var/lib/edgedelta-staging
  containerMountPath: /var/lib/edgedelta-staging

If either value is empty, the agent logs persisting cursor path does not exist and disables persisting cursors.

4. Avoid host-port conflicts

Because each agent is a DaemonSet, both agents run a pod on every node. Any host port that both pods claim on the same node conflicts. Two separate things can put a port on the host, and each is handled differently.

Push-based input ports

Push-based (listening) input nodes receive data on a port. When that port is exposed on the host (the exposeInHost option on a port, rendered as a hostPort), two agents that expose the same host port on the same node conflict. This is independent of the tracer.

Only push-based inputs bind a port. These include http_input, otlp_input, tcp_input, udp_input, syslog_input, splunk_hec_input, splunk_tcp_input, datadog_agent_input, fluentd_input, and snmp_trap_input. Pull-based inputs such as file_input (container logs), k8s_event_input, ed_k8s_metrics_input, prometheus_input, kafka_input, and http_pull_input do not listen, so they never conflict.

Give the second pipeline’s push-based inputs distinct host ports. The conflict can be easy to miss: if the two agents share the host network (see below) and both bind, for example, an http_input on port 3421, the second agent logs a warning containing address already in use but keeps running, so the pod still reports Ready with no restarts while that input receives no data.

The tracer (hostNetwork)

Separately, the tracer is enabled by default (tracerProps.enabled: true) and runs the agent on the host network (hostNetwork: true, along with hostPID: true) to power the eBPF-based telemetry sources. This is not related to exposing input ports, and disabling it does not resolve an input-port conflict. If the second agent does not need the eBPF sources, disable it:

tracerProps:
  enabled: false

Note: Disabling the tracer turns off the eBPF-based telemetry sources Kubernetes Trace and Service Map. Disable it only if the second agent does not need those sources. Doing so also reduces the agent’s resource consumption (see Reducing Agent Resource Consumption).

Example install command

Add the Edge Delta Helm repository, then install the second release with all four overrides combined.

helm repo add edgedelta https://helm.edgedelta.com

helm repo update

helm upgrade --install edgedelta-staging edgedelta/edgedelta \
  --version 2.20.0 \
  --namespace edgedelta-staging \
  --create-namespace \
  --set secretApiKey.value=<SECOND_ACCOUNT_API_KEY> \
  --set persistingCursorProps.hostMountPath=/var/lib/edgedelta-staging \
  --set persistingCursorProps.containerMountPath=/var/lib/edgedelta-staging \
  --set tracerProps.enabled=false

Each override addresses one of the requirements above:

• edgedelta-staging is a distinct release name, so the cluster-scoped ClusterRole and ClusterRoleBinding do not collide with the existing release.
• --namespace edgedelta-staging --create-namespace places the second agent in its own namespace, isolating the namespaced Services, PVC, and ConfigMap.
• secretApiKey.value=<SECOND_ACCOUNT_API_KEY> holds the API key or token for the second Edge Delta account, so this agent reports to that account.
• persistingCursorProps.hostMountPath and persistingCursorProps.containerMountPath point the second agent at its own cursor directory, so the two agents do not corrupt each other’s offset state.
• tracerProps.enabled=false disables the eBPF-based telemetry sources (Kubernetes Trace and Service Map) and keeps the second agent off the host network. Include it only if the second agent does not need those sources; it is not required to avoid input-port conflicts.

For the full node pipeline installation flow and other Helm options, see Install with Helm.

Verify

Confirm that both agents are running independently:

1. Check that both DaemonSets are present, one per namespace:

kubectl get ds -A | grep edgedelta

2. Confirm the pods in the second namespace are Ready:

kubectl get pods -n edgedelta-staging

3. In the Edge Delta app for the second account, confirm that data is arriving from the new agent.

4. Confirm the two releases are fully independent Helm releases:

helm list -A

Note: These details reflect chart version 2.20.0. Values and defaults can change between chart versions, so check the chart’s values.yaml for the version you are running.