Hello and welcome to this lecture, in this lecture, we will discuss about coordinative services.
Added services enable communication between various components within and outside of the application
covid-19 services helps us connect applications together with other applications or users.
For example, our application has groups of parties running various sections, such as a group for serving
front end load to users and other groups for running back and processes, and a third group connecting
to an external data source.
It is services that enable connectivity between these groups of parts.
Services enabled the front end application to be made available to end users.
It helps communication between backend and front end parts and helps in establishing connectivity to
an external data source.
Thus, services enable loose coupling between micro services in our application.
Let's take a look at one use case of services so far, we talked about how pilots communicate with each
other through internal networking.
Let's look at some other aspects of networking in this lecture.
Let's start with external communication.
So we deployed our pod, having a Web application running on it.
How do we as an external user access the Web page?
First of all, let's look at the existing set up, the Khubani.
This node has an IP address and that is 192 DOT 168 to my laptop is on the same network as well.
So it has an IP address, 190 to 168 dot one or 10.
The internal pod network is in the range 10 to 4.0 dot zero and the part has an IP tendered 240 for
the two.
Clearly I cannot ping or access the pod at address 10 to 40, 4.0 to as it's in a separate network.
So what are the options to see the Web page?
First, if we were to SSX into the Covenant, it now at 192, that was sixty eight to one or two from
the node, we would be able to access the parts web page by doing a call.
Or if the node has a DUI, we would fire up a browser and see the web page in a browser following the
address.
ETP Tanda 240 4.0 dot to.
But this is from inside the cabin is no, and that's not what I really want.
I want to be able to access the Web server from my own laptop without having to SSX into the node and
simply by accessing the IP of the Cuban editor's note.
So we need something in the middle to help us map requests to the node from our laptop through the node
to the port running the web container.
This is where the coroner's service comes into play, the coroner's service is an object just like part
replica set or deployments that we worked with before.
One of its use case is to listen to a report on the note and forward request on that port to a port
on the port running the Web application.
This type of service is known as a known port service because the service listens to a port on the node
and forward request to the.
There are other kinds of services available which we will now discuss.
The first one is what we discussed already know port, where the service makes an internal port accessible
on a port on the node.
The second is close IP, and in this case, the service creates a virtual IP inside the cluster to enable
communication between different services, such as a set of front end servers to a set of backend servers.
The third type is a load balancer where it positions a load balancer for our application in supported
cloud providers.
A good example of that would be to distribute load across the different Web servers in your front and
tier.
We will now look at each of these in a bit more detail, along with some demos.
In this lecture, we will discuss about the node, Port Khubani, the service.
Getting back to Northport, few slides back, we discussed about external access to the application.
We said that a service can help us by mapping a port on the node to a port on the part.
Let's take a closer look at the service, if you look at it, there are three ports involved.
The port on the part where the actual Web server is running is 18 and it is referred to as the target
port because that is where the service forwards the request to the second port.
Is the port on the service itself.
It is simply referred to as the port, remember, these terms are from the viewpoint of the service.
The service is, in fact like a virtual server, inside the node, inside the cluster.
It has its own IP address.
And that IP address is called the cluster IP of the service.
And finally, we have the port on the node itself, which we use to access the Web server externally,
and that is known as the node port.
As you can see, it is said thirty thousand eight.
That is because node ports can only be in a valid range, which by default is from thirty thousand to
thirty two thousand seven hundred and sixty seven.
Let's now look at how to create the service, just like how we created a deployment replica set or pod
in the past.
We will use a definition file to create a service.
The high level structure of the file remains the same as before.
We have the API version, kind metadata and spec sections.
The API version is going to be the one.
The kind is, of course, service.
The metadata will have a name and that will be the name of the service.
It can have labels, but we don't need that for now.
Next we have spek.
And as always, this is the most crucial part of the file as this is where we will be defining the actual
services.
And this is the part of a definition file that differs between different objects.
In the spec section of a service.
We have type and ports.
The type refers to the type of service we are creating.
As discussed before, it could be cluster IP node port or load balancer.
In this case, since we are creating a node port, we will sell it as node port.
The next part of espec is ports.
This is where we input information regarding what we discussed on the left side of the screen.
The first type of port is the target port, which we will set to 80.
The next one is simply port, which is a port on the service object, and we will set that to 80 as
well.
The third is North Port, which we will send to 30000 aid or any number in the valid range, remember
that out of this, the only mandatory field is port.
If you don't provide a target port, it is assumed to be the same as port, and if you don't provide
a known port, every port in the valid range between thirty thousand and thirty two thousand 767 is
automatically allocated.
Also note that sports is an array, so not a dash under the sports section that indicate the first element
in the area.
You can have multiple such sport mappings within a single service.
So we have all the information in, but something is really missing, there is nothing here in the definition
filed that connects the service to the pod.
We have simply specified the target board, but we didn't mention the target board on which pod there
could be hundreds of other pods with Web services running on Port 80.
So how do we do that, as we did with the replica sets previously and a technique that you will see
very often in communities?
We will use labels and selectors to link these together.
We know that the pod was created with a label.
We need to bring that label into the service definition file.
So we have a new property in the specs section, and that is called Selecter, just like in a replica
set and deployment definition filed under The Selecter, provide a list of labels to identify the part.
For this referred to the pod definition file used to create the pod, pull the labels from the pod definition
file and place it under the selector section.
This links the service to the past, once done, create the service using the cube control, create
command and input the service definition file.
And there you have the service created to see the created service, run the cube control, get services,
command that list the service, the cluster IP and the map ports.
The type is node port as we created and the port on the node is set to three thousand eight because
that's the port that we specified in the definition file.
We can now use this port to access the Web service using Kerl or a Web browser so called to 190 to 168
Wando to, which is the IP of the node.
And then I use the port thirty thousand eight to access the web server.
So far, we talked about a service mapped to a single pod, but that's not the case all the time.
What do you do when you have multiple pods in a production environment?
You have multiple instances of your Web application running for high availability and load balancing
purposes.
In this case, we have multiple similar pods running our Web application.
They all have the same labels with a key app and said to a value of my app, the same label is used
as a selector during the creation of the service.
So when the service is created, it looks for a matching pod with the label and finds three of them.
The service then automatically selects all the three parts as endpoints to forward the external request
coming from the user.
You don't have to do any additional configuration to make this happen, and if you're wondering what
algorithm it uses to balance the load across the three different parts, it uses a random algorithm.
Does the service acts as a built in load balancer to distribute load across different parts?
And finally, let's look at what happens when the polls are distributed across multiple nodes in this
case, we have the Web application on Pardes, on separate nodes in the cluster.
When we create a service without us having to do any additional configuration, Cuban errors automatically
creates a service that spans across all the nodes in the cluster and maps the target port to the same
node port on all the nodes in the cluster.
This way, you can access your application using the IP of any node in the cluster and using the same
port number, which in this case is thirty thousand eight.
As you can see, using the IP of any of these nodes, and I'm trying to call to the same port and the
same port is made available on all the nodes, part of the cluster.
To summarize, in any case, whether it be a single pot on a single node, multiple parts on a single
node or multiple paths on multiple nodes, the service is created exactly the same without you having
to do any additional steps during the service creation.
When parts are removed or added, the service is automatically updated, making it highly flexible and
adaptive.
Once created, you won't typically have to make any additional configuration changes.
That's it for this lecture.
Head over to the demo and I will see you in the next lecture.