If you haven’t heard, Jaeger was recently accepted as a Cloud Native Computing Foundation (CNCF) hosted project, announced at Open Source Summit North America. The addition of Jaeger helps round out the monitoring and metrics capabilities in the CNCF catalog complementing the OpenTracing and Prometheus projects. This blog will take a look at deploying a Jaeger, OpenTracing, and Prometheus stack to a Kubernetes cluster the hard way, manually using YAML files, and the easy way, using a newly contributed Helm Chart for Jaeger.

You may be thinking about now, why would I do anything the “hard way”? Well, there are a couple of reasons:

  • There is a lot of value knowing the architecture and components involved in a production Jaeger deployment (covered in the “hard way” section).
  • Helm, although progressing quickly, is in the infancy of seeing deployments in production environments.
  • Helm Charts are convenient, but deploying individual components via the “hard way” allow the user to completely customize all aspects of the application as they see fit.

Deploying Jaeger, OpenTracing, and Prometheus the Hard Way


If you missed my previous blog post about deploying a Zipkin, OpenTracing, and Prometheus stack to a Kubernetes environment, I would highly recommend you give it a read as there is some overlap. To avoid the duplication, this blog will focus on Jaeger and the various components in its architecture. If you are interested in following along to deploy Jaeger and Prometheus in your existing Kubernetes cluster, this GitHub repo has been created to make obtaining the YAML required to deploy various components easier.

Before we begin, let’s create all the required services that Jaeger will require in Kubernetes. You can do that by simply navigating to the root of the GitHub repo and then executing the following commands:

cd services
kuebctl create -f jaeger.yaml
cd ..

In a production deployment of Jaeger, there are individual 5 components that make up Jaeger:

  • Cassandra (or optionally ElasticSearch)
  • Collector
  • Agent
  • Query UI
  • Schema

All Jaeger tracing data that is collected is stored via Cassandra in a typical 3-node production configuration. In the YAML, the Cassandra cluster named “jaeger” is configured to auto discover other Cassandra nodes and uses the tmpDir or temporary scratch space for storage. To set up Cassandra to use persistent storage, please take a look at the previous blog post or the Kubernetes documentation for more details. To deploy a 3-node Cassandra instance, run the following commands:

cd deployments
kubectl create -f jaeger1-cassandra-scratch.yaml
cd ..

The next couple of components can be deployed just after Cassandra is up and running. The first component is actually a Kubernetes job called cassandra-schema which is nothing more than a job that initializes the Cassandra keyspace so that it can store tracing data. The other component is the Jaeger Agent which is deployed in the form of a DaemonSet; meaning the Agent is deployed to each of the Kubernetes worker/compute nodes. You can deploy both of these components by running the following commands:

cd deployments
kubectl create -f jaeger2-schema-agents.yaml
cd ..

The final two components that make up a production Jaeger instance are the Collector and the Query UI. The Collector’s function sounds exactly like its name; it collects tracing data from either Jaeger Agents or directly via the Jaeger or Zipkin protocols. The Query UI provides the web interface that will help graphically visualize the interactions between the various microservices being used. To deploy these components run the following command:

cd deployments
kubectl create -f jaeger3-collector-ui.yaml
cd ..

There you have it! A fully functional Jaeger environment! So that’s deploying Jaeger the hard way, but it seems like there has to be an easier way than that. You would be correct! Let’s take a look a Helm Charts in the next section.


To deploy Prometheus, as it was covered in the previous blog post, run the following commands:

cd services
kubectl create -f prometheus.yaml
cd ..

cd deployments
kubectl create -f prometheus-scratch.yaml
cd ..

Give Me the Easy Button


The Hard Way can be pretty complicated. Is there an easier way to deploy Jaeger into a Kubernetes environment? Glad you asked! The {code} team recently contributed a Jaeger Helm Chart to the Kubernetes Chart repo! As with all new chart submissions, you can find the Jaeger Chart in the incubator directory, here.

So how do I go about deploying the Jaeger Chart using Helm? If you haven’t already installed Helm, the instructions are in the Kubernetes documentation. You will also need to enable Helm to access the incubator Charts in the repo (or if you had previously added the incubator repo and need to refresh the list of Charts). You can do that by running the following command:

$ helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/

Once that is complete, pick a Helm release name. In this case we will use myjaeger and installing Jaeger is as simple as running the following command:

helm install incubator/jaeger --name myjaeger

Simple huh?! Should you need to override some default values of the chart (for example deploying Jaeger into a limited resource environment for demo purposes), you can always override values like so:

helm install incubator/jaeger --name myjaeger \
--set cassandra.config.max_heap_size=1024M \
--set cassandra.config.heap_new_size=256M \
--set cassandra.resources.requests.memory=2048Mi \
--set cassandra.resources.requests.cpu=0.4 \
--set cassandra.resources.limits.memory=2048Mi \
--set cassandra.resources.limits.cpu=0.4

You can deploy Helm quickly and easily by running the following command:

helm install stable/prometheus --name myprom

If you want to just test the waters and disable the persistent volume feature of Prometheus, you can run the following command:

helm install stable/prometheus --name myprom \
--set alertmanager.persistentVolume.enabled=false \
--set server.persistentVolume.enabled=false

What’s next?

Jaeger is an awesome project to help with tracing various components in your application by providing insight into the health and visualizing the interactions between your microservices. This blog post should help make it easier to quickly deploy and consume Jaeger in your Kubernetes environment.

Where do we go from here? Around the time the Jaeger chart was being contributed to the Kubernetes community, we reached out to the project maintainers for Jaeger with an offer to help contribute resources. After a cursory review of the Helm Chart, we were asked to take a look at adding ElasticSearch as an optional backing store. That is currently being worked on. If you want to learn more about Jaeger, visit the official GitHub page or the Jaeger documentation to learn more.