Hello everyone, my name is Josh Roseau and I'm a cloud native architect at VMware. Today I'm going to be talking to you about Ingress. Specifically, how do we get Xtrim traffic into the Kubernetes cluster, into our pods. To demonstrate this I've made a cars app and a mountains app, that serve images of each.

Each pod has it own IP address, but normally we won't route directly to pods. Typically we introduce services in Kubernetes. Services give us a consistent virtual IP that our clients can rely on as pod IP's change over time or you scale pods up, or scale them down. Then you always can still call the virtual IP, which will route to any number of pods that underlie it.

To demonstrate this, I have a service for cars and mountains. Now there's many different types of services and I encourage you to check out the Kubernetes documentation to better understand them. But I'm using a simple one called cluster IP. In my router, In my network knows how to route to this particular cluster IP or virtual IP. So, if I open up a web browser and head to this address on core8000, where my pod is receiving traffic. I am now routing into the cars app, likely if I come back to the mountains app, and grab that cluster IP, I will be routing to the mountains application.

So, no matter which pod it routed to, I just had to call the IP address, the bip, and it would route into that particular pod, that represents the application; pretty easy. No this is a pretty simplified model, and if we wanted to make it more advance we might introduce something called an Ingress controller.

Now an Ingress controller, provides us the ability to have layer 7 routing, so if a client comes in and says, "mountains," or "cars," the path can go to the mountains app based on the path; or cars based on the path so we introduce layer 7 concepts. This also works with DNS or host names. We also can do fancier stuff like going in and load balancing based on certain algorithms, like least connections. We can also terminate TLS at this layer. So it gives us a lot more flexibility.

Now, and Ingress controller may seem like a pretty foreign topic to you, but it's actually not. Ingress controllers are the technologies your pretty use to. Things like INGINX or HA proxy. There's also Ingress controllers like contour that reuse the envoy proxy, and traffic. Now these Ingress controllers are basically taking technologies, like INGINX that you might be use to, and making them Kubernetes aware.

What this ends up looking like, is you end up with an Ingress controller that runs in the cluster, and then inside the Ingress controller itself represented by these green boxes, you'll have the load balancer itself, which will send and receive traffic. Then you'll usually have some kind of controller component, and the controller is what makes all the difference.

The controller, understands the Kubernetes API, so that as there's modifications, additions and deletions to ingress objects, it can program or configure the load balance or proxy technology that you choose, be it HA proxy, INGINX, Envoy and so on. So all in all this might be separate processes, it might actually just run in one pod as one container, one process, depends on which ingress controller you choose, but at the end of the day this is all an ingress controller is. A controller paired with some type of load balancer technology that will then route into pods that you specify layer 7 rules for.

Now to show you what this looks like I have an ingress document, and the ingress API is nothing too confusing. In fact I'll simplify this a bit to start us out. What I can say here is, alright, I want the ingress to be set up so that requests that come into mountains.vmware.com will route to the pod IP's that sit behind the service mountains. So I can go ahead and apply this manifest after I save it. So, cube, cuddle, apply. So we'll apply that manifest, and now if I go back to my web browser, assuming that my DNS is set up, I can call mountains.vmware.com in this ingress controller, in this case I'm running Contour, so this will go through Envoy, is sitting at port 8080. So I'll hit enter and boom, I get mountains.

Now we can also make this more advance, right? We could maybe make another rule inside here or even introduce another ingress document or object, but in this case I'll do it all in the same file and I could add in a path called cars, and lets say if things come in on the cars path I want to route to the service name cars, or particularly the pod IP's that sit behind the cars service. Save that up, apply it just like before, now I can come into where mountains are set and I can ask for the path, cars, and boom; now I get cars just like that.

So, we can introduce these layer 7 rules and these can be really cool for multi- team environments, where you might want to introduce a layer of load balancing, that just teams introduce these objects to, and all of a sudden your cluster just is set up to route, that's it. Your team doesn't have to worry about programming INGINX or Contour, Envoy in particular; they just have to add one of these documents and your cluster just respects it, that's it.

Another cool example of this is, we can look at adding TLS. So let's say hypothetically and I'm going to open up a different document here. I want to introduce TLS to this same doc. So the change here is in the TLS part of the spec, by adding the TLS section of the spec, I can reference a secret in my Kubernetes cluster. So, I have a secret in this cluster called SSLCERT, and I'll show you what that looks like in the bottom here.

So, if I cubecuddle get secrets. You can see the SSLCert right in side of here and if we do a getsecretssslcert and we will output the yamil and put it through last. We can look in what the cert contains. Now, it's a lot of text here, but basically I have a simple self signed certificate I generated, and inside of here there is the date itself, okay, and the data actually consists of a TLS cert which is of course the certificate, which is bay 64 encoded in this case, and then a TLS key inside of here, which is the private key for the certificate.

So by referencing this particular secret SSL-cert inside of my TLS, I'm going to be able to terminate TLS at this level and still respect all of my routing rules as well. So let's try that out, if we take this manifest, save it up, and in this case we'll even change a couple things. So mountains.vmware.com our path will just be on, lets just say MTNS path here just to make sure we can see the change happen. So I'll go ahead and apply this TLS manifest and then coming back to our web browser here a couple things we'll need to change. So fist off we need to be able to put in 8443, which is where my contour instance is running at the edge of my cluster on, for TLS traffic I'll put https in the beginning as well. I'll go ahead and hit enter.

Now you can see I'm getting a certificate. Now my browser's warning me because this is a self signed certificate, I totally expect this to happen, but, if I go ahead and click mountains.vmware.com, it does actually go though on https, but I am getting a 404. So if we go back our manifest here, oh yeah, so we had the path specified as MTNS, to kind of change it up a bit with this new Ingress resource.

So if we head back to our browser, add MTNS here. Now we have mountains again. So, hopefully you can see by introducing an Ingress controller, and there are many to choose from. Your developers can just create these Ingress resources alongside their application deployments and poof there will be the layer 7 routing into their apps.

Now it's just on you to look for an Ingress controller that meets your needs. Many of the advanced ones like Contour, Traffic, HA proxy, INGINX, have a lot of great features, and you should check those out to make in informed decision for what Ingress controller is best for you.