Nico Vibert is a Senior Technical Marketing Engineer at Isovalent – the company behind the open-source cloud native solution Cilium. Nico has worked in many different roles – operations and support, design and architecture, technical pre-sales – at companies such as HashiCorp, VMware and Cisco. Nico’s focus is primarily on network, cloud and automation and he loves creating content and writing books. Nico regularly speaks at events, whether on a large scale such as VMworld, Cisco Live or at smaller forums such as VMware and AWS User Groups or virtual events such as HashiCorp HashiTalks. Outside of Isovalent, Nico’s passionate about intentional diversity & inclusion initiatives and is Chief DEI Officer at the Open Technology organization OpenUK.
Back to Basics – L7 Flow Visibility
[07:26] In this short demo, we look at the 2 options to achieve Layer 7 flow observability using Cilium and Hubble.
Let’s now look at layer 7 flow observability with Cilium and Hubble. Now, in the previous video, what we looked at was how we can use Cilium and Hubble to automatically create a flow diagram, right? Looking at things like IP addresses, HTTP Port, but also having some kind of awareness of Kubernetes objects. But clearly, what you would also like to have is, if you can, if possible, is to have more granular visibility into at layer 7. For example, at the HTTP request packets to find out more about HTTP path status code, or that kind of data. And the way to do it is to use the embedded Envoy proxy that lives within Cilium. We can’t do it natively within eBPF, so we have to forward the traffic internally to the Envoy proxy that is running within the Cilium agent. For this, I’m going to be using the Cilium service mesh lab again. Now, we have two ways. One is to annotate a pod, and I would add layer 7 visibility to our Hubble flow, right? You can even see here back in the documentation here, um, as you can see, we can just add some kind of annotation and it has to follow a specific format. You can see the traffic direction, example, egress, Layer 4, Port, protocol, and then the layer 7 protocol, right? So maybe you want to look for DNS traffic or maybe you want to look for HTTP traffic, right? So you can annotate a specific pod, and, automatically, it will generate some,, you will start seeing some visibility for this traffic. No let’s try straight away here. So we’re going to annotate here so we look at how we are applying the label based on this annotation, based on the label ‘product page,’ and we are looking for Ingress traffic over Port 9080 for TCP and HTTP, right? So we’re being quite granular about the type of traffic we are looking for. If I just now refresh that application, let’s see in the Hubble UI, you can see HTTPS just appear. So we are now sending some visibility into at the HTTP level. You can see that there was a GET call to a ‘/productpage’ path. Great, so that’s option number one. Then, now let’s, now, look at option number two.
In option number two, what we are doing is using network policies, so again, the layer 7 policies, network policies will result in the traffic being proxied through an Envoy instance, provided in each agent pod. So we’re going to use this example policy which essentially applies to,, TCP traffic of about 80, 8090, 9080, etc., and we’ll apply it across the whole cluster.
All right, let’s look. Again, let’s refresh your application, and now we should begin to see more and more data in here, all right? So you can see ‘/product page’ to ‘/reviews,’ there was a call made to ‘/reviews/0,’ go back again, to ‘/details.’
And if we use Hubble CLI, we start to see more information about exactly the type of call. Now, let’s be a bit more granular, and that’s the beauty of the CLI, especially is how you can add more and more filters. So right now, we are looking for traffic over Port HTTP, and we are just looking for the traffic that matches the label ‘app=reviews’ over Port 9080. Again, you can see HTTP 1.1 GET traffic to the specific URL. That you can look so traffic based on the path or, for example, just traffic to ‘/details.’ Again, you can find it. You can see it comes from the product page to the details pod. You could also – and actually we don’t need this, we can just look for, let’s say, HTTP status 200. Again, you see the 200 status code requests replying successfully.
And you can just be very granular with how you observe traffic. Again, we can, for example, use the method, so you can filter based on all the GET calls and you could combine several different flags. For example, if you want to see the GET calls to a specific application, you can base it on the labels. We want to see the traffic to the details app, and we’ll just change it forward, and again, you can see traffic. You can see the timestamp, source, destination, network policy, verdict, and the layer 7 filter.
So that’s the end of the video. Again, you’ll see we’ve got a couple of different ways to gain layer 7 visibility. One was to annotate a pod, or one was to apply a layer seven network policy but as you can see, it’s very powerful. We’ve only shown examples for HTTP, but it works with, you know, gRPC or Kafka, some different types of layer 7 protocols. Okay, well, thanks for watching. If you like this video, feel free to subscribe, and we’ll see you soon. Bye.