Hi, everyone. My name is Sai Vennam, and today we're going to be talking about Kubernetes Ingress in 5 minutes. Now, I'm going to assume you already have the fundamental understandings of Kubernetes, but if you don't, be sure to check out my video, "Kubernetes Explained". Let's go ahead and get started. Let's assume that we've got a pod scaled out three times within my Kubernetes cluster, and I've got three nodes in my Kubernetes cluster, and this pod is scaled up to three. Now, these pods together - let's say I've created a grouping with the label selector to create what's called a "service". Now, a service basically enables me to load balance requests to one of these pods, and that's going to be our first start here. Let's say we've got a "service.yaml" that defines that service. One of the core things you can define in that is going to be a type, and we're going to start with the basic one, "Cluster IP". Now, basically every service that gets created in Kubernetes has a cluster IP. It enables access to that service from within the Kubernetes network, not the external network. So, let's assume our service has a Cluster IP and move forward to the next, more interesting, option here. I could also specify that type as a Node port. Now, a Node port is actually a lot like the name kind of makes it sound. Now, we've got three nodes in our cluster, and each one of those nodes has a publicly accessible IP. Now, let's say that that publicly accessible IP looks something like 169.0.0.1, 169.0.0.2, and so on for the third one. Now, this is a publicly accessible IP address, but what a Note Port will do is assign the same Node port, so the same port, let's say it's 31,000, to all three of those nodes. So, for external access from outside, from the Internet that's coming in, and that hits that port on any one of these IP addresses that's externally accessible. It's going to route directly to service that's defined in that service.yaml. So, that's an interesting approach and there's a couple of limitations. So, basically any service can only have one port. But more importantly, if a node were to go down, say you're working with a cloud service provider and you scale your nodes up and down a lot, well, you're going to have to maintain that updated IP address that's going to change when a new node comes up. So, although it works, it's
not the best approach to exposing your applications on the public Internet. Let's talk about a third type here. It's going to be type "load balancer". Now a load balancer, when you define it, so, it's really dependent on how a cloud provider is providing their Kubernetes service. But essentially the way it works, the cloud provider is going to spin up something called an NLB, or a "Network Load Balancer", for every service that you expose this way. And so, for users that are coming in and accessing that NLB, that IP address, it's going to route directly to that service. But although this is good, again, it's only one kind of service, one load balancer IP address per service. And, in addition, load balancers are a commodity at the end of the day. If you need to expose a lot of services, that's a lot of load balancers which can be inefficient when going to scale. Now, the last one I want to talk about here is actually not even a service type; it's a new thing called an "Ingress Resource" which maybe we can define with an ingress.yaml file, and this is going to be, you know, you're going to define a "kind: ingress". Now an ingress is a little different. The way ingress is going to work, when you create this, it's going to create basically a set of rules within your cluster, an ingress resource that can route based on a set of rules. These rules are going to be really reminiscent of something like an engine X reverse proxy. So, the first thing that ingress will do is create an external load balancer that's able to handle requests coming in and let's say that request comes in for app.com which maps to an IP address that the ingress supports and now here's where the interesting part comes in. It can actually route based on a set of rules. So, let's say we have a second set of pods in the cluster and these set of pods route to a Service B. Now, this rule - maybe we introduce a rule that says if the rule comes in, or the route comes in with, let's say, serviceb.app.com, then route to this set of services, otherwise route all other traffic to Service A. We'll just say "other". So, an ingress is powerful because you can route multiple backend services with a single IP address and then do path-based routing. So, as other advantages you can do something like TLS termination, do virtual hosts and a number of other kind of capabilities that become available. So, this was Kubernetes ingress in five minutes. If you enjoyed this video, or have any questions, be sure to drop a like or a comment below. Stay tuned and follow us for more videos like this in the future. Thank you.
