Complimentary Gartner® Report! 'A CTO's Guide to Open-Source Software: Answering the Top 10 FAQs.'Read more

BindPlane Agent architecture

Deploy BindPlane Agents to Kubernetes

BindPlane manages three different Kubernetes Agent types. Node, Cluster, and Gateway. Each agent type serves a unique purpose within the cluster. They can be used together or independently.

Node

The BindPlane Node agents are deployed as a DaemonSet. The Node agent scales up and down with the size of the cluster. Each agent is responsible for collecting logs and metrics from the node it is running on.

Additionally, the Node agent supports receiving OTLP metrics, traces, and logs from other services running in the cluster, via clusterIP service.

Supported Sources

Persistence

The Node agent makes use of Host Path volumes to persist the agent configuration file and exporter persistent queue directories.

The Host Path /var/lib/observiq/otelcol/containeris mounted at /etc/otel/storage within the agent container.

Persistence allows the agents to operate during a BindPlane or backend outage.

Cluster

The BindPlane Cluster agent is deployed as a Deployment. The Cluster agent operates a single pod and is responsible for collecting cluster-level metrics and events (logs). The Cluster agent is not intended to scale above one pod, therefore it is limited to sources that should run on a single replica to avoid duplicate telemetry.

Supported Sources

Gateway

The BindPlane Gateway agents are deployed as a Deployment or StatefulSet. The Gateway agent is intended to operate as an aggregation layer, allowing other agents or services to forward metrics, traces, and logs to the gateway for additional processing before being shipped to a backend.

The Gateway agent is optional for monitoring a Kubernetes cluster. It should be used during the following situations:

  • Offload processing from the Node and Cluster agent
  • Limit backend access to a dedicated set of agents.
  • You already have a solution for logs and metrics, and need a solution to receive telemetry from services running in the cluster.

Supported Sources

Persistence

The Gateway agent uses a Volume Claim Template to generate and assign volumes to each Gateway agent pod. The volume contains the agent's configuration file and exporter persistent queue directories. If an agent pod is killed or restarted for any reason, the volume assigned to that pod will be attached to the new instance of the pod, allowing the new pod to continue where the previous instance left off.

Persistence allows the agents to operate during a BindPlane or backend outage.

Limitations

Change Configurations

Kubernetes agents are bound to a single configuration. Changes to that configuration are supported, however, changing to a new configuration is not supported. To change to a new configuration, you can re-deploy the agents by using the Install Agents page and selecting your new configuration.

Non Kubernetes Agents

Agents running outside of Kubernetes can be installed as long as ingress has been configured. See the getting started guide for agent installation instructions.