Up next in 10
Join this live session with Rodrigo Díaz Concha for the next episode of Kubernetes Fundamentals on May 03, Wednesday at 8:30 AM Pacific Time (US).
After attending this session, you will learn about Ingress in Kubernetes.
ABOUT SPEAKER
Rodrigo Díaz Concha is a Solutions Architect, Microsoft Regional Director, and Microsoft MVP with more than 22 years of experience. In addition, he is a book author, speaker, and course author for LinkedIn Learning.
Rodrigo has dozens of professional certifications from different companies such as Carnegie Mellon SEI Software Architecture Professional, Microsoft Certified: Azure Solutions Architect Expert, Microsoft Certified: DevOps Engineer Expert, and HashiCorp certifications.
He also has the distinction of having written the first books on Silverlight 5 and Xamarin.Forms in the Spanish language.
C# Corner - Community of Software and Data Developers
https://www.c-sharpcorner.com
#CSharpCorner #CSharpTV #Kubernetes
Show More Show Less View Video Transcript
0:30
Hello, friends, and welcome to another episode of the Kubernetes Fundamental Series here in C Sharp Corner Live
0:43
Today, I'm going to talk about ingress. However, let me go to the previous topics that I explained the other day
0:54
We talked about daemon sets. Those are objects that we deploy to ensure that specific pods are running all the time in each node in the cluster or maybe a subset of nodes
1:09
and I did a demo about Demon Sets and then we talked about jobs
1:18
which is a way of creating tasks that will run until completion
1:26
And then we created cron jobs, which is a specialization of jobs
1:33
You create a cron job with a schedule and that particular cron job
1:37
is going to create job objects. And I'm not going to repeat jobs again
1:43
like I did the other day. Like 50 times I repeated jobs
1:50
Anyways, today I'm going to talk about Ingress, which is a series of objects
1:58
that we can use to expose our services outside the cluster. Of course, you can use, say, I don't know
2:07
So maybe you can use a service, right? A node type kind of service to expose
2:17
that particular service out of the cluster. However, if you do that
2:22
then your clients will need to know the port beforehand. So ingress are another way of exposing those services
2:34
Okay? So with an ingress, you define how external traffic should be routed to the services within the cluster
2:44
So of course you have pods, right? You have dozens of pods
2:49
or maybe you have hundreds or even thousands of pods. And then you create services
2:54
Remember that pods are ephemeral and that's why you need some kind of stable way
3:01
of calling those pods. And that is where services come into the picture, right
3:08
So you create service objects and those services, they have the rules for communicating to the pods, right
3:16
They use label selectors and those kinds of things. And sometimes you need to expose those services
3:24
because you want your applications to invoke the pods functionality, right? So in other words, you need to expose the services. Ingress is a way to expose those services. Ingress is particularly interesting because it consolidates multiple services under a single IP address or even host name
3:49
In this session, I'm going to show you how to use an ingress in the Minikube cluster, of course, because that's the technology that I'm using for explaining Kubernetes
4:05
And I'm going to create an ingress, and I'm going to explain what's going on here in this cluster. Okay
4:12
Okay, another thing about ingress is that they enable load balancing. And of course, it depends on the kind of ingress that you're using
4:24
In this session, I'm going to use NGINX ingress. Okay, however, there are others that I'm going to talk about later on
4:33
Okay, load balancing, SSL termination, and name-based virtual hosting are some of the traits and features
4:43
that ingress is enabled in your cluster. So you create ingress objects by using a manifest file
4:53
I believe there's an imperative way of doing this. However, most of the time
4:57
you're going to use a manifest file. And however, that particular object
5:04
that ingress needs something to be controlling those ingress instances. And that's the ingress controller
5:19
that you need to have installed on your cluster. So we have ingresses and we have ingress controllers
5:26
Those two things are different. And I'm going to explain that in a minute, okay
5:33
So in this diagram, we can see that Of course, we have some applications that we deployed by using maybe a deployment, right
5:42
And then you expose those pods by using a service. The service has the knowledge about the pods because of the label selectors and those kind of things
5:55
And what if you want to expose the service? Well, actually, that's where the ingress object comes into the picture
6:03
You create an ingress object and you define the rules. You define the path that you want to use for the ingress to route the traffic to service A or service B or service C
6:20
Okay? So as I'm mentioning right now, you can have different routing rules for different services in a single ingress object
6:33
Okay. So it sounds great, right? What are some of the main properties for ingresses? Well, you can actually use a host name. You can map a host name for an ingress, or you can use a path and a path type, which is most of the time fixed, or maybe it's a prefix that you want to use for that path
7:01
and you define the service, the backend service that you want to map that path with
7:08
And some other things such as TLS configuration and so on. So here's the manifest file for an ingress
7:16
So you can see that API version is networking.kates.io forward slash v1
7:24
That's the API version for ingress. this is not part of the primitive objects
7:31
that Kubernetes has, right? That's why the API version is different. Okay, ingresses were created after the primitive types
7:44
And the kind is ingress. So as you can see this in the text
7:49
let me put this in silence. Okay, cool. The kind is ingress. Okay
7:57
API version, kind, metadata, spec, regular stuff. I've been talking about this since, I don't know
8:06
10 sessions, right? So we have API version, kind, metadata. That's where the name of the ingress is configured
8:14
And then the spec, inside the spec, you define the rules, the routing rules that you want to use
8:21
for your different services that you want to expose, right? So for instance, in this particular example
8:28
I'm using the forward slash API path to be mapped to my service that is listening on port 3000 Okay So of course I have this fictitious my service object running and listening on port 3000
8:49
And I'm exposing that by using the forward slash API path in this ingress. Okay
8:58
So very easy stuff. So as you can see paths is an array
9:04
That's why you can define different routing rules for different services inside the same ingress object
9:12
So I'm going to do this later today. Before I do that, let me explain to you ingress controllers
9:22
So ingress is this object that you create, right? By using a manifest file, you deploy the ingress
9:29
but there must be something that is watching those Ingress objects. This is similar to the controller manager for deployments
9:41
and the controller for replica sets and those kind of things. Those are controllers that are members of the primitive objects in Kubernetes
9:55
The thing is that Ingress is an external object for your Kubernetes cluster
10:03
That's why you need to install the Ingress controller. This Ingress controller is going to monitor those Ingress objects
10:14
and they, I mean, the Ingress controllers will enforce the routing rules
10:20
So they are the ones that are going to ensure that the desired state of things is fulfilled
10:30
Okay? So you need to install the ingress controller. That's why you need this object
10:36
You don't use an ingress by itself. You need both the ingress and the ingress controller that is watching all the time those ingress resources
10:48
Okay? And this is particularly interesting because the Ingress controllers are not managed by the controller manager in the control plane
10:59
Just as I'm mentioning right now, because they're not part of the primitive types
11:05
They're not part of the basic components that Kubernetes has, right? So Ingress controllers are independent components that you deploy and manage separately within your cluster
11:18
Okay. So there are many ingress controllers that you can use. It depends on the flavor of the ingress controller that you want to use
11:28
Say that I'm going to use Nginx in this session. However, you can use core, you can use STO, you can use traffic, you can use, I think I have the list
11:42
Yes, I do. There are others like the ones that I have here in this list, right
11:48
HA proxy, traffic, STL, contour, what have you. So it depends on your particular skills, technical skills
11:58
and maybe the current investments that your company has on a particular brand of things, right
12:06
So in this session, I'm going to use Nginx because that's an open source English controller
12:11
and that's very powerful and very easy to use. Ingress controller. So the first thing that you want to do is enabling
12:26
or installing the Ingress controller, right? In this particular code that I have here on the screen
12:34
I'm enabling Ingress in Minikube. So that's actually what I need to do in this session
12:44
because I have Minikube, right? and if I execute minikube add-ons list
12:52
you can see that I don't have ingress enabled yet. Let me show you this, right
12:59
This is disabled. So that's why I'm going to clear and then minikube add-ons
13:09
and then the sub command is enabled and the name is ingress
13:16
So this is a way of installing and enabling the NGNX Ingress in your Minikube cluster
13:23
Remember that Minikube is this technology that we use for testing purposes
13:28
It's not meant to be used as a production environment for Kubernetes
13:34
Anyways, I'm going to enable the Ingress controller in the cluster right now
13:42
Okay, this is gonna take some seconds. So it's fine if I just minimize the window
13:48
and continue with the explanation. And then of course, this is gonna install different objects
13:56
such as a deployment and some pods will be running and the ingress controller from Nginx
14:03
is gonna create this ingress-nginx namespace in my cluster. So one way to verify if you have the ingress controller
14:12
running on the cluster, is just by querying all the objects in that particular namespace
14:17
which is ingress-nginx, right? So kubectl get all namespace ingress-nginx and that's one way to verify
14:27
that you have all the things correctly installed. So kubectl get all and the namespace is ingress-nginx
14:38
So as you can see that those objects are running. So I successfully enabled the Nginx Ingress in this Minikube cluster
14:52
So let me show you this again. And Ingress is enabled. So that's one way
14:58
And of course, this is because I'm using Minikube. And there are other ways for installing the Nginx Ingress controller
15:09
Okay. One way is to download the manifest file and then deploy that manifest file
15:16
and then verify with the same technique that I just showed you
15:22
And of course, this is the instructions for NGINX Ingress Controller. The other Ingress Controllers
15:31
will have the different instructions. So you have to follow the particular Ingress Controller instructions
15:38
for installing and verifying if you're using those other objects. There's other technique by using Helm
15:48
I haven't talked about Helm in this series. Helm is a package manager similar to
15:57
you know, if you're a .NET developer, similar to Nougat, right? Or, I don't know, NPM for Node developers
16:06
and those package repositories, okay? So here are the instructions and this is for Helm
16:17
Anyways, so this is great. And now I'm going to create the ingress, okay
16:26
So first I need to have the manifest and actually I'm going to copy this
16:33
because I'm going to use it. and I don't want you to see me typing all the time
16:40
So I'm going to paste this in the notepad that I have here in this other screen, right
16:45
And let's create a C-sharp corner, corner, C-sharp corner, and I'm going to create a new manifest file
16:56
Let's use Visual Studio Code, okay? And I'm going to paste this code
17:04
let's create a new file, my ingress.jml or something like that. And I'm going to save this, okay
17:11
Of course I need the pods I need the service I need some objects to test this because if I execute kubectl get all you can see that I currently in the default namespace
17:24
and I don't have anything, right? I just installed this mini kubectl cluster
17:29
I just deployed it like 10 minutes ago. So this is empty
17:36
So the first thing that I want to do is create some pods. let's execute the following kubectl
17:43
Say that I want to create a deployment, and I'm going to use the image that I created beforehand
17:50
This is my username in Docker Hub, and this is for a course that I recorded a couple of weeks ago
17:59
CKAD, which is the Certified Kubernetes Application Developer Exam, Web App, and I'm going to use Blue
18:08
This is just an ASP.NET core application that shows a blue screen. Okay
18:15
And I want, say, I don't know, five replicas. And let me use this syntax
18:24
And I want to use port 80. Okay. kubectl create deployment and my deployment
18:31
That's the name that I want to use. Image replicas port. Okay
18:36
So as you can see, I created this successfully. Let's query for all the objects
18:43
Those pods are being created right now. So it looks like this is going to work
18:50
Yeah, two pods are running right now. So those will be okay, right
18:56
I created the deployment that has five pods. Nice. So now I want to create the service
19:05
the service that is going to expose those five pods. Okay. So I can create by using kubectl create service
19:14
or maybe I can create a manifest file. However, I'm just going to use kubectl expose deployment and my deployment
19:22
This is a nice and easy way for creating services that are connected to existing pods
19:29
So the name of this service is going to be myService, okay
19:35
And this is going to use target port 80. And this is because the ASP.NET Core application
19:44
that is running on those pods is listening on port 80, okay
19:49
And I want this service to be listening on port 3000, okay
19:57
kubectl.expose.deployment. deployment that's the name of the deployment that I want to expose and some
20:03
other configurations for this service. Okay. So the service was created successfully
20:10
You could all get service, right? So the service was created. Let me show you this describe service and the name is my service
20:20
right? So the most important thing here is that the endpoints field
20:27
has some pods, right? Otherwise, this service will be like in an isolated fashion, right
20:37
So this service is connected to those five pods that I deployed
20:43
And this is actually what I want. So this is great. And now let's go back to the Visual Studio Code instance
20:51
And let me increase the font size. And let me change some things, okay
20:57
So this is my ingress. I'm going to use, say, forward slash, because my application has or it understands the forward slash path
21:11
It doesn't understand the forward slash API path. And later today, I'm going to show you some URL rewriting for controlling this
21:23
Anyways, so this is a path and this is a prefix. Path types could be exact or prefix, those two values
21:34
Let me show you this. Cube kernel explain. Ingress spec rules and then HTTP and then paths
21:48
which is this array and path type. So prefix is one of the options and the other one is exact
21:58
Remember that you can always use kubectl explain for obtaining the, you know
22:04
the documentation about a particular field. So in this case, I'm going to use prefix
22:11
And inside the backend field, this is the place where you define the service
22:18
that you want to map to this path, okay? Okay, so backend service, the name is my service
22:25
That's why I used double dash name equals my service when I exposed the deployment
22:34
And the port number that this service is listening on is 3000
22:41
Okay, so it looks good. I actually don't think that I need to add anything else right now
22:48
Let me go back to the terminal and let's just apply my ingress
22:53
So kubectl apply, file my ingress. And as you can see, the ingress was created successfully
23:01
You can query for all the ingresses that you have on your cluster
23:04
by using kubectl get ingress. Okay, so you can see that my ingress was created, right
23:14
And now I'm ready to test this. So I'm using Minikube. That's why I need to know the IP address that my cluster has
23:27
So in this case, it's this particular IP address. Okay. So I can use something like curl for querying this endpoint
23:39
And remember that I mapped the root path, right? To the service
23:45
So in other words, if I execute this, I'm returning the, you know
23:52
the contents of the ASP.NET Core application that is running on all the different pod instances, right
24:00
I actually have this other paragraph in the HTML that the application is returning
24:08
This is returning the machine name, okay? So in other words, it's returning the name of the pod
24:14
that is responding to this particular request. So this is ending with 98F
24:24
and what happens if I execute this again? Another pod is returning the response, right
24:32
Another pod is answering. So the thing here is that my ingress is acting
24:39
like a load balancing object. And of course, it's sending the traffic to the service
24:46
and the service itself is load balancing the requests to the different pods that are backing the service
24:55
You know what? So this is VDH, kubectl get pods. So we can see that this is VDH and the other one was 98F
25:06
So those two pods were returning the response in my first two attempts, okay
25:14
So that's a nice way for exposing our applications outside the cluster
25:22
So this is nice. However, what happens if I have different services, okay
25:28
I want to expose different services in different paths. So that's another requirement that you need to implement
25:37
in your routing rules. And I'm going to use an annotation that is for rewriting the URL
25:46
Before I do that, let me show you all the objects. So I have my deployment which is you know the deployment that created those five pods that are returning the blue content and I happen to have another image which is ckad web app green okay so this other application
26:13
is returning a web app that has a green background okay so I'm gonna name this my deployment two
26:22
with five replicas on port 80 again. Okay, so I should have 10 pods running in this moment
26:31
kubectl get pods. So those are being created right now. And yeah, I have 10 pods, two deployments
26:41
two replica sets in this particular moment. So now I want to expose this second deployment
26:50
by using kubectl exposed deployment, my deployment two, and let's name this my service two, okay
27:01
I should have renamed this as my blue service and my green service, but I think this should be enough
27:10
And this is gonna listen on port 3001, okay? My service two is gonna listen on port 3001
27:20
So let's expose this and the service was created. Let's query for all these services
27:26
kubectl, get services. I'm sorry about that. I have my service in my service to
27:35
running on different ports, right? And my service to is backing. I mean, it's exposing the green application pods, right
27:45
So let's return once again to Visual Studio Code and let's create another path
27:55
So let me copy this, this entire block, and this is going to be green and this is going to be blue, right
28:08
So, of course, my application doesn't understand forward slash blue, you know, that particular segment in the URL and neither green
28:22
Okay. So, I need something to rewrite things. And that's why I'm going to use that annotation
28:31
However, let me fix this. My service 2 is running on port 3001, green, and it looks good
28:41
Okay. So now the annotation, I'm going to add this in the annotations field inside the metadata
28:49
And the name of this particular annotation is Nginx Ingress Kubernetes.io, blah, blah, blah
28:56
A lot of different, that's a large name. I don't want to type this
29:03
That's why I have this name in this other notepad that I have here on the screen
29:10
So the thing here is that this is gonna change the first position of the URL to something else
29:21
So actually I have this other regular expression that I want to use, right
29:28
And this other one for the green one. So in other words, this is going to map blue, forward slash blue with the service, with the first service
29:39
And this is going to map that URL with the forward slash path inside my application
29:48
And this other one, green, is going to do the same, right
29:53
So this is going to rewrite the target. That's why I'm using this annotation
29:58
And this is just a regular expression syntax for using other segments if I want to
30:07
Anyways, I'm just going to use forward slash blue or forward slash green, okay
30:15
Anyways, it looks good. Let's create this or let's change the current ingress
30:23
by applying the file. So, kubectl apply if my ingress. So, my ingress was configured and I can do this curl, right
30:39
Blue, and this is returning blue deployment, okay? And this other one, if I execute forward slash green
30:50
this is going to return green deployment, okay? So, as you can see, those two services are responding to this particular request
31:04
So, let me show you this. This is not very exciting. However, let me show you this, okay
31:11
Green deployment versus blue deployment, right? And actually this should be blue
31:20
but it's not returning the entire CSS design and all the files that I need
31:28
Anyways, you can see that this is returning blue deployment and the name of the pod
31:35
And this other is returning green deployment with this other application, right
31:41
That is running on another pod. So, and with that, I believe I mentioned everything that I wanted in this particular session
31:58
Let's go back to the presentation. So, as a summary, you have both ingress and ingress controllers
32:11
The ingress controller is the one that is gonna make sure that the desired state is fulfilled
32:18
And then you create ingress objects by using a manifest file. I believe there's an imperative way of doing this
32:26
However, I believe this is easier if you create the manifest file
32:32
and you specify the rules, you know, the traffic rules for this particular ingress
32:39
and the ingress controller is going to make sure that this desired state
32:44
this desired traffic rules are implemented and configured in your cluster. Okay
32:52
And with that, I believe, yes, I have my blank slide
33:02
That means that this is the end of today's session. It was a very quick session
33:08
However, it was filled with a lot of information about ingresses and ingress controllers
33:15
So thank you for your time and see you on the next session
33:21
in this Kubernetes for, Kubernetes, Kubernetes Fundamental session
33:33
That's the name. I was going to say Kubernetes for developers. that's not the name of this series
33:39
Kubernetes Fundamentals, only in C Sharp Corner Live, okay? Thank you and see you next time
34:06
Thank you
#Business & Industrial
#Programming
#Distributed & Cloud Computing