This chart has been deprecated and moved to its new home:

• GitHub repo: https://github.com/jaegertracing/helm-charts
• Charts repo: https://jaegertracing.github.io/helm-charts

To add the repo:

$ helm repo add jaegertracing https://jaegertracing.github.io/helm-charts

Jaeger is a distributed tracing system.

This chart adds all components required to run Jaeger as described in the jaeger-kubernetes GitHub page for a production-like deployment. The chart default will deploy a new Cassandra cluster (using the cassandra chart), but also supports using an existing Cassandra cluster, deploying a new ElasticSearch cluster (using the elasticsearch chart), or connecting to an existing ElasticSearch cluster. Once the back storage available, the chart will deploy jaeger-agent as a DaemonSet and deploy the jaeger-collector and jaeger-query components as standard individual deployments.

• Has been tested on Kubernetes 1.7+

  • The spark cron job requires K8s CronJob support:

    You need a working Kubernetes cluster at version >= 1.8 (for CronJob). For previous versions of cluster (< 1.8) you need to explicitly enable batch/v2alpha1 API by passing --runtime-config=batch/v2alpha1=true to the API server (see Turn on or off an API version for your cluster for more).

• The Cassandra chart calls out the following requirements (default) for a test environment (please see the important note in the installation section):

resources:
  requests:
    memory: 4Gi
    cpu: 2
  limits:
    memory: 4Gi
    cpu: 2

• The Cassandra chart calls out the following requirements for a production environment:

resources:
  requests:
    memory: 8Gi
    cpu: 2
  limits:
    memory: 8Gi
    cpu: 2

• The ElasticSearch chart calls out the following requirements for a production environment:

client:
  ...
  resources:
    limits:
      cpu: "1"
      # memory: "1024Mi"
    requests:
      cpu: "25m"
      memory: "512Mi"

master:
  ...
  resources:
    limits:
      cpu: "1"
      # memory: "1024Mi"
    requests:
      cpu: "25m"
      memory: "512Mi"

data:
  ...
  resources:
    limits:
      cpu: "1"
      # memory: "2048Mi"
    requests:
      cpu: "25m"
      memory: "1536Mi"

To install the chart with the release name myrel, run the following command:

$ helm install incubator/jaeger --name myrel

After a few minutes, you should see a 3 node Cassandra instance, a Jaeger DaemonSet, a Jaeger Collector, and a Jaeger Query (UI) pod deployed into your Kubernetes cluster.

IMPORTANT NOTE: For testing purposes, the footprint for Cassandra can be reduced significantly in the event resources become constrained (such as running on your local laptop or in a Vagrant environment). You can override the resources required run running this command:

helm install incubator/jaeger --name myrel --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

Tip: List all releases using helm list

If you already have an existing running Cassandra cluster, you can configure the chart as follows to use it as your backing store (make sure you replace <HOST>, <PORT>, etc with your values):

helm install incubator/jaeger --name myrel --set provisionDataStore.cassandra=false --set storage.cassandra.host=<HOST> --set storage.cassandra.port=<PORT> --set storage.cassandra.user=<USER> --set storage.cassandra.password=<PASSWORD>

Tip: It is highly encouraged to run the Cassandra cluster with storage persistence.

If you already have an existing running Cassandra cluster with TLS, you can configure the chart as follows to use it as your backing store:

Content of the values.yaml file:

storage:
  type: cassandra
  cassandra:
    host: <HOST>
    port: <PORT>
    user: <USER>
    password: <PASSWORD>
    tls:
      enabled: true
      secretName: cassandra-tls-secret

provisionDataStore:
  cassandra: false

Content of the jaeger-tls-cassandra-secret.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: cassandra-tls-secret
data:
  commonName: <SERVER NAME>
  ca-cert.pem: |
    -----BEGIN CERTIFICATE-----
    <CERT>
    -----END CERTIFICATE-----
  client-cert.pem: |
    -----BEGIN CERTIFICATE-----
    <CERT>
    -----END CERTIFICATE-----
  client-key.pem: |
    -----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----
  cqlshrc: |
    [ssl]
    certfile = ~/.cassandra/ca-cert.pem
    userkey = ~/.cassandra/client-key.pem
    usercert = ~/.cassandra/client-cert.pem

kubectl apply -f jaeger-tls-cassandra-secret.yaml
helm install incubator/jaeger --name myrel --values values.yaml

To install the chart with the release name myrel using a new ElasticSearch cluster instead of Cassandra (default), run the following command:

$ helm install incubator/jaeger --name myrel --set provisionDataStore.cassandra=false  --set provisionDataStore.elasticsearch=true --set storage.type=elasticsearch

After a few minutes, you should see 2 ElasticSearch client nodes, 2 ElasticSearch data nodes, 3 ElasticSearch master nodes, a Jaeger DaemonSet, a Jaeger Collector, and a Jaeger Query (UI) pod deployed into your Kubernetes cluster.

Tip: If the ElasticSearch client nodes do not enter the running state, try --set elasticsearch.rbac.create=true

If you already have an existing running ElasticSearch cluster, you can configure the chart as follows to use it as your backing store:

helm install incubator/jaeger --name myrel --set provisionDataStore.cassandra=false --set provisionDataStore.elasticsearch=false --set storage.type=elasticsearch --set storage.elasticsearch.host=<HOST> --set storage.elasticsearch.port=<PORT> --set storage.elasticsearch.user=<USER> --set storage.elasticsearch.password=<password>

Tip: It is highly encouraged to run the ElasticSearch cluster with storage persistence.

If you already have an existing running ElasticSearch cluster with TLS, you can configure the chart as follows to use it as your backing store:

Content of the jaeger-values.yaml file:

storage:
  type: elasticsearch
  elasticsearch:
    host: <HOST>
    port: <PORT>
    scheme: https
    user: <USER>
    password: <PASSWORD>
provisionDataStore:
  cassandra: false
  elasticsearch: false
query:
  cmdlineParams:
    es.tls.ca: "/tls/es.pem"
  extraConfigmapMounts:
    - name: jaeger-tls
      mountPath: /tls
      subPath: ""
      configMap: jaeger-tls
      readOnly: true
collector:
  cmdlineParams:
    es.tls.ca: "/tls/es.pem"
  extraConfigmapMounts:
    - name: jaeger-tls
      mountPath: /tls
      subPath: ""
      configMap: jaeger-tls
      readOnly: true

Content of the jaeger-tls-cfgmap.yaml file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: jaeger-tls
data:
  es.pem: |
    -----BEGIN CERTIFICATE-----
    <CERT>
    -----END CERTIFICATE-----

kubectl apply -f jaeger-tls-cfgmap.yaml
helm install incubator/jaeger --name myrel --values jaeger-values.yaml

To uninstall/delete the myrel deployment:

$ helm delete myrel

The command removes all the Kubernetes components associated with the chart and deletes the release.

Tip: To completely remove the release, run helm delete --purge myrel

The following table lists the configurable parameters of the Jaeger chart and their default values.

For more information about some of the tunable parameters that Cassandra provides, please visit the helm chart for cassandra and the official website at apache.org.

For more information about some of the tunable parameters that Jaeger provides, please visit the official Jaeger repo at GitHub.com.

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm install --name myrel \
    --set cassandra.config.rack_name=rack2 \
    incubator/jaeger

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart.

Jaeger itself is a stateful application that by default uses Cassandra to store all related data. That means this helm chart has a dependency on the Cassandra helm chart for its data persistence. To deploy Jaeger with storage persistence, please take a look at the README.md for configuration details.

Override any required configuration options in the Cassandra chart that is required and then enable persistence by setting the following option: --set cassandra.persistence.enabled=true

• Sidecar deployment support