<p>I have installed Istio using the helm chart with the following settings:</p>

<pre><code>helm template --set kiali.enabled=true --set tracing.enabled=true --set pilot.traceSampling=100 --set grafana.enabled=true --set sidecarInjectorWebhook.enabled=true install/kubernetes/helm/istio --name istio --namespace istio-system &gt; istio.yaml
</code></pre>

<p>When I check the services running in the cluster under the <code>istio-system</code> namespace I see multiple services around tracing. </p>

<pre><code>jaeger-agent             ClusterIP      None      &lt;none&gt;     5775/UDP,6831/UDP,6832/UDP                                                                                                                   
jaeger-collector         ClusterIP      10.100.66.107    &lt;none&gt;  14267/TCP,14268/TCP
tracing                  ClusterIP      10.100.81.123    &lt;none&gt;   80/TCP                                                                                                                                       
zipkin                   ClusterIP      10.100.64.9      &lt;none&gt;   9411/TCP 
</code></pre>

<p>Since Jaeger is the default setting, I was expecting to see only the <code>jaeger-collector</code>. It is not clear as to what the role of <code>jaeger-agent</code>, <code>tracing</code> and <code>zipkin</code> are, any ideas ?
,</p>

mithrandir
<p>Just mentioning beforehand (you might already know) that a Kubernetes Service is not a "service" as in a piece of code. It is a way for Kubernetes components &amp; deployments to communicate with one another through an interface which always stays the same, regardless of how many pods or servers there are. </p>

<p>When Istio deploys it's tracing mechanism, it deploys modular parts so it can deploy them independently, and also scale them independently, very much like micro-services. </p>

<p>Generally a Kubernetes deployed utility will be deployed as a few parts which make up the bigger picture. For instance in your case: </p>

<p>jaeger-agent - This is the components which will collect all the traffic and tracing from your nodes.</p>

<p>jaeger-collector - This is the place where all of the jaeger-agents will push the logs and traces they find on the node, and the collector will aggregate these as a trace may span multiple nodes. </p>

<p>tracing - might be the component which injects the tracing ID's into network traffic for the agent to watch.</p>

<p>zipkin - could be the UI which allows debugging with traces, or replaying requests etc. </p>

<p>The above might not be absolutely correct, but I hope you get the idea of why multiple parts would be deployed. </p>

<p>In the same way we deploy mysql, and our containers separately, Kubernetes projects are generally deployed as a set of deployments or pods. </p>
