- About the speakerNico Vibert
Senior Staff Technical Marketing Engineer
Back to Basics – Hubble UI
[03:33] In this short demo, Senior Technical Marketing Engineer Nico Vibert revisits the Hubble UI and how a Service Map can be automatically build for your micro-services applications running on a Cilium-managed network.
Transcript
In this short video, I’m going to go back to the basics of the observability platform Hubble. One of the main features of Hubble is its ability to automatically build a service map for you with zero effort. Hubble is built on top of Cilium. So, once you deploy Cilium and start deploying applications, you will automatically see a service map built to represent network connectivity between all your different microservices.
The example I’m using here is the same one we use for many service mesh demos and service mesh labs. We deploy the bookinfo application, which is typically used and developed by the people beyond Istio. We can deploy an Ingress resource or Gateway API resource to access this microservices-based application through the Ingress controller.
What you can see here is a diagram showcasing all the different microservices: product page, a set of reviews Pods, and Node.js ratings, a Ruby application for the details. All this represents a very basic book information database. So, we can see information about books from Shakespeare and different reviews.
Building this diagram on Whimsical is a manual process. But what would be great is if a similar diagram is generated automatically when you deploy and start using this application. That’s exactly what you have with Hubble UI. You can see that I’m accessing my application through Ingress. It hits a product page, and then I can go through the details, including the reviews. Even if I click on the reviews, you see the product page, two reviews, and two ratings. It requires no effort to build this diagram.
It provides layer three and layer four confirmation about TCP or UDP flows. It includes all the context around the type of applications, such as Kubernetes labels, namespaces, and you can have more information about the flows used to build this service map. You can see the source service and destination service. If needed, I can actually provide the pod’s IP address. The service map also shows the verdict of network policies: approved, denied, or simply forwarded traffic. Even the TCP flag for this kind of transaction is indicated.
And that’s it for the first demo.