Ingress gateways and virtual services - Kubernetes Tutorial

- [Instructor] One of the most common uses of the Istio environment is to provide a more efficient and flexible router than a classic Kubernetes Ingress. In fact, it's a more efficient and flexible router than just about any other similar container-based Ingress like service, even outside of the Kubernetes space. In order to do that, there are actually two components. If we do a listing of our module directory here, we see that we have a gateway description manifest and we have a virtual service manifest. The gateway just connects the external Kubernetes service, a classic Kubernetes Ingress service, it turns out, to the internal virtual server. So, the gateway is just bridging that Kubernetes model for how to connect to the outside world. The gateway also does actually manage TLS configuration if you were to enable security in the ingress environment. But, beyond that it's actually a fairly simple ingress-based model, but then the real work is done within the virtual service. If we do a more on the hostname-virtualservice.yaml file, we can see that, not only do we have definition, we've called this service hostname, just to sort of keep it consistent with the application that we're deploying, and at the very bottom, our route into the environment is via host hostname, and that's actually a service connection that gets created, but we also are calling out specifically a host called hostname.example.com. Now, this is a made up name and we're going to trigger this route by passing a header to the gateway definition to actually create that route. So, we're going to now go look at our routing basics file, with more routing basics, and this sort of goes through the same set of processes, or steps that we have to do to turn these resources on. Firstly, we have to create the gateway, and so that connects ourselves to the Kubernetes Ingress, so they have a way of getting into this particular routed path. Secondly, we create the virtual service. And then, we can check and make sure that we can actually get into these different resources. We're going to that one of two ways. First, we're going to make sure that we can still talk to the underlying Kubernetes service. Now, we expose that as a known NodePort, 31575, and that's just based in the service definition that we created earlier. And then, we're also going to use the gateway model, and we're going to look at port 31380. Now, that's also a standard know port. If it was not available on 31380 for some reason, you could check the Istio System namespace to see what the service mapping actually was. In our case, we don't have to do that. We can just use the 31380 parameter, because that's the correct known port. So, the first thing we have to do is, we have to create our gateway, so we'll go ahead and copy those commands. Copy and then paste them. Great. And then we can create our virtual service. Same thing, copy and paste. Simple enough. So, we have our gateway on our service created. And then, just for good measure, we're going to check the underlying Kubernetes style service to see exactly what that looks like. Now, we're passing the -I parameters or the curl, because that way we're just looking at the headers. And specifically what I wanted to see was that we were talking to a server, which is the nginx server, and the ETag, which is effectively a cashe of the content that we're delivering is -d4, is really all we need to see. Now, we should be able to curl against the gateway service, and so that's the port 31380, and we're going to pass the hostname parameter as well. And now what we see is that our server is no longer nginx. Our server is now envoy, and that's the Istio Proxy gateway, but you can see that the data that we delivered is still the same, it's still that -e4 data. And, that's using the gateway to route data within Istio.