Deployment strategies for the Jaeger Agent

If you’ve been following the evolution of the Kubernetes templates for Jaeger, you might have noticed an important change recently: the Jaeger Agent is not being deployed as a DaemonSet anymore. Instead, instructions are now being provided on how to deploy it as a “Sidecar”.

The Agent component was developed to act as a “buffer” between the tracer and the collector. This buffer should sit very close to the tracer, usually on localhost. Because of this basic assumption, the tracer can just send the collected spans to the agent via UDP, for an optimal balance between performance and reliability.

While this assumption works great for a deployment on bare metal, a question arises when we start to think about cloud environments and containers: what is localhostfor your Kubernetes pod? Is it the node it’s running on, or is it the pod itself?

The case for DaemonSets

DaemonSets are pods that run at the node level, ideal for scenarios where the pod is a daemon, like a log collector or monitoring agents. They are also a good fit for single tenant environments, where several pods on the node would send data to the pod running as DaemonSet. For the Jaeger Agent, this means that it would receive data from several pods, without caring about security, tenancy or anything else: every pod on the same node are treated equally. This allows for a lower memory overhead, as there will be a single agent caring for potentially hundreds of “application” pods.

The case for Sidecars

Sidecar is the technique of adding another container to your pod, usually as an infrastructure service, like security or resiliency. For the Jaeger Agent, this means that it would sit as a container on the same pod as the tracer. As they run at the application level, they don’t need special permissions on platforms like OpenShift. Besides, each application can send data to a different Jaeger Collector backend, making it ideal for multi tenant scenarios.

Which is better for my case?

Depending on your deployment architecture, you might benefit more from having a single agent per several pods, or one agent per pod: if you have your own internal cloud, with trusted applications running on your Kubernetes cluster, you might benefit from having a lower memory overhead of the DaemonSet approach. If you use a public cloud, or if you need multi tenancy capabilities, having one agent per pod might be a better fit, even if this comes with a small memory hit (under 20Mb per agent).

Tell us about your case

It’s your turn now: tell us what’s the best fit for your deployment scenario and which approach would you rather see when you first encountered Jaeger. Which one is easier to understand and which one is closer to your needs? Feel free to use the comments section or, better yet, join us on Gitter!