I have installed Istio using the helm chart with the following settings:
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 > istio.yamlWhen I check the services running in the cluster under the istio-system namespace I see multiple services around tracing.
jaeger-agent ClusterIP None <none> 5775/UDP,6831/UDP,6832/UDP
jaeger-collector ClusterIP 10.100.66.107 <none> 14267/TCP,14268/TCP
tracing ClusterIP 10.100.81.123 <none> 80/TCP
zipkin ClusterIP 10.100.64.9 <none> 9411/TCP Since Jaeger is the default setting, I was expecting to see only the jaeger-collector. It is not clear as to what the role of jaeger-agent, tracing and zipkin are, any ideas ? ,
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 & deployments to communicate with one another through an interface which always stays the same, regardless of how many pods or servers there are.
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.
Generally a Kubernetes deployed utility will be deployed as a few parts which make up the bigger picture. For instance in your case:
jaeger-agent - This is the components which will collect all the traffic and tracing from your nodes.
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.
tracing - might be the component which injects the tracing ID's into network traffic for the agent to watch.
zipkin - could be the UI which allows debugging with traces, or replaying requests etc.
The above might not be absolutely correct, but I hope you get the idea of why multiple parts would be deployed.
In the same way we deploy mysql, and our containers separately, Kubernetes projects are generally deployed as a set of deployments or pods.
To complement @christiaan-vermeulen's answer: the tracing service is Jaeger's UI (jaeger-query) so that the same URL can be used for alternative backends, whereas the Zipkin service is a convenience service, allowing applications using Zipkin tracers (like Brave) to send data to Jaeger without requiring complex changes. If you look closely, the Zipkin service is backed by the jaeger-collector as well.