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.
Cilium Gateway API – HTTP Header Modifier
In this short video, Senior Technical Marketing Engineer Nico Vibert walks you through how to use Cilium Gateway API to modify HTTP headers.
In this quick video, we’re going to test a Cilium feature that enables you to rewrite the HTTP header using the Gateway API. So, we start with Cilium, which is already deployed, and we’ve got the Gateway API feature enabled. Here it is.
And we’ve got our Cilium Gateway, which is already there. Already, it’s got an IP address of 172.18.255.201, which we can see also there.
When you deploy Gateway API, you get a Kubernetes service of the type of LoadBalancer, and we allocate an IP address, which is how we’re going to access our internal service. The internal service we’re trying to access is this one called echo-server, and the way we’ve done it with Gateway APIs is using something called HTTP Route APIs. So, if we just go in, and we’re going to use this one here.
So, as mentioned, we’re using the HTTP Route CRD to essentially take the traffic that matches this particular path Cilium-add-a-header and we’ll send that to our backend service, which is the echo server service of our port 9080. Let’s now connect to the service.
Wow, so that’s working fine, and we are actually making an HTTP curl request to an echo server, and what we get in return is the same reply back. Right, so we know we’ve got successful connectivity, and we even see with Hubble.
We can verify the traffic has been sent from my host to the Gateway API, it’s been forwarded to the embedded Envoy proxy, and we see the reply back again because it’s an identical HTTP request coming back, and let me see it coming back with Hubble now.
We’re just going to filter a bit because that’s was pretty messy, so let’s have a look with JQ we get something that is a bit more human-readable, and we’re just going to go and filter on Request.headers, and we can see again that original HTTP request header that we made which was sent back to us. So, if you wanted to get used to use Gateway API to other HTTP header, which you know that’s what many of the front-end load buttons so might do in this kind of scenario, we’re just going to update this file, this manifest, and what we’re doing is we’re adding, we’re using this filter to simply add a header which will be called nico-header-name, and the value will be nico-header-value, we’re just going to save it and apply it. And we’re going to make the same request.
What you can see here is that header has been added to my HTTP request, and that’s it. That’s as simple as that. So that’s one of the use cases for Gateway API. We’ve talked about it in the previous demos about just routing HTTP traffic, HTTP/HTTPS, also some kind of traffic splitting for canary testing, and you can also use it to modify HTTP headers, and that’s it. Thanks for watching.