Hello and welcome to this lecture.
In this lecture, we will discuss about the cabinet, a service cluster IP.
A full stack web application typically has different kinds of parts hosting different parts of an application.
You may have a number of parts running a front end Web server.
Another set of parts running a back in server, a set of parts running a key value store like Redis
and another set of parts.
Maybe running a persistent database like my S cual.
The Web front end server needs to communicate to the backend servers and the back end servers need to
communicate to the database as well as the ready services, etc..
So what is the right way to establish connectivity between these services or tiers of my application?
The parts all have an IP address assigned to them, as we can see on the screen.
But these eyepiece, as we know, are not static.
These parts can go down anytime and new parts are created all the time.
And so you cannot rely on these IP addresses for internal communication between the application.
Also, what if the first front end part at ten to 40 4.0?
Three need to connect to a back and service.
Which of the three would it go to and who makes that decision?
A Cuban at a service can help us group the part together and provide a single interface to access the
parts in a group.
For example, a service created for the back end part will help group all the back and parts together
and provide a single interface for other parts to access to service.
The requests are forwarded to one of the parts under the service randomly.
Similarly, create additional services for Redis and allow the backend parts to access the ready systems
through the service.
This enables us to easily and effectively deploy a micro services based application on Coburn that is
cluster.
Each layer can now scale or move as required without impacting communication between the various services.
Each service gets an IP name assigned to it inside the cluster, and that is the name that should be
used by other paths to access the service.
This type of service is known as cluster IP to create such a service.
As always, use a definition file in the service definition file first used to default template which
has API abortion kind metadata on spec.
The API version is V.
One kind is service and we will give a name to our service.
We will call it back and under specification we have type and ports.
The type is cluster IP.
In fact, cluster IP is the default type.
So even if you didn't specify it, it will automatically assume the type to be cluster IP under-report.
We have a target port and port.
The target port is the port where the back end is exposed, which in this case is 80 and the port is
where the service is exposed, which is 80 as well, to link the service to a set of ports, we use
selector.
We will refer to the port definition file and copy the labels from it and remove it under selector.
And that should be it.
We can now create the service using the cube control, create command and then check its status using
the cube control gets services command.
The service can be accessed by other parts using the cluster IP or the service name.