1|Page

Kubernetes Services enable communication and see the webpage in a browser following
between various components within the address http://10.244.0.2. But this is
and outside of the application. Kubernetes from inside the Kubernetes node and that's
Services helps us connect applications not what I really want. I want to be able to
together with other applications or users. For access the web server from my own laptop
example, our application has groups without having to SSH into the node and
of Pods running various sections, such as a simply by accessing the IP of the
group for serving frontend loads to users, Kubernetes node. So we need something in
and other group for running backend the middle to help us map requests to the
processes, and a third group connecting to node from our laptop, through the node, to
an external data source. It is Services that the Pod running the web container. This is
enable connectivity between these groups of where the Kubernetes Service comes into
Pods. Services enable the frontend play. The Kubernetes Service is an object,
application to be made available to end just like Pods, ReplicaSet, or Deployments
users. that we worked with before. One of its use
It helps communication between backend case is to listen to a port on the node and
and frontend Pods, and helps in establishing forward request on that port to a port on the
connectivity to an external data source. Thus Pod running the web application. This type
Services enable loose coupling between of service is known as a NodePort service
microservices in our application. Let's take a because the service listens to a port on the
look at one use case of Services. So far we node and forward request to the Pods. There
talked about how Pods communicate with are other kinds of services available,
each other through internal networking. which we will now discuss. The first one is
Let's start with external communication. So what we discussed already, NodePort where
we deployed our Pod having a web the service makes an internal port accessible
application running on it. How do we, as an on a port on the node. The second is
external user, access the webpage? First of CluserIP, and in this case, the service creates
all, let's look at the existing setup. The a virtual IP inside the luster to enable
Kubernetes node has an IP address and that communication between different services,
is one 192.168.1.2. My laptop is on the same such as a set of frontend servers
network as well, so it has an IP address, to a set of backend servers. The third type is
192.168.1.10. The internal Pod network is in a LoadBalancer, where it provisions
the range 10.244.0.0. And the Pod has an IP a load balancer for our application in
10.244.0.2 Clearly I cannot ping or access supported cloud providers. A good example
the Pod at address 10.244.0.2 as it's in a of that would be to distribute load across the
separate network. So what are the options to different web servers in your frontend tier.
see the webpage? First, if we were to SSH We will now look at each of these in a bit
into the Kubernetes node at 192.168.1.2 more detail along with some demos.
from the node, we would be able to access
the Pod's webpage by doing a curl. Or if the
node has a GUI we would fire up a browser
2|Page

Now i will discuss about the NodePort of a definition file that differs between
Kubernetes service. , as we discussed about different objects. Next, we have spec, and as
external access to the application. We said always, this is the most crucial part of the
that a service can help us by mapping a port file, as this is where we will be defining the
on the node to a port on the Pod. Let's take a actual services, and this is the part of a
closer look at the service. definition file that differs between different
If you look at it, there are three ports objects. In the spec section of a service, we
involved. The port on the Pod where the have type and ports. The type refers to the
actual web server is running is 80, and it is type of service we are creating. As discussed
referred to as the target port because that is before, it could be ClusterIP, NodePort, or
where the service forwards their request to. LoadBalancer. In this case, since we are
The second port is the port on the service creating a NodePort we will set it as
itself. NodePort. The next part of a spec is ports.
It is simply referred to as the port. This is where we input information
Remember, these terms are from the regarding what we discussed on the left side
viewpoint of the service. The service is, in of the screen. The first type of port is the
fact, like a virtual server inside the node. targetPort, which we will set to 80. The next
Inside the cluster it has its own IP address, one is simply port, which is a port on the
and that IP address is called the ClusterIP of service object, and we will set that to 80 as
the service. well.
And finally, we have the port on the node The third is nodePort, which we will set to
itself which we use to access the web server 30,008 or any number in the valid range.
externally, and that is as the node port. As Remember, that out of these, the only
you can see, it is set to 30,008. That is mandatory field is port.
because node ports can only be in a valid If you don't provide a targetPort, it is
range which by default is from 30,000 to assumed to be the same as port.
32,767. Let's now look at how to create the And if you don't provide a nodePort, a free
service. Just like how we created a port in the valid range between 30,00 and
deployment ReplicaSet or Pod in the past, 32,767 is automatically allocated. Also, note
we will use a definition file to create a that ports is an array, so note the dash under
service. The high-level structure of the file the port section that indicate the first
remains the same. As before, we have the element in the array. You can have multiple
API version, kind, metadata, and spec such port mappings within a single service.
sections. The API version is going to be v1. So, we have all the information in, but
The kind is of course service. The metadata something is really missing. There is
will have a name, and that will be the name nothing here in the definition file that
of the service. It can have labels, but we connects the service to the Pod. We have
don't need that for now. Next, we have spec, simply specified the target port but we didn't
and as always, this is the most crucial part of mention the target port on which Pod. There
the file, and this is where we will be could be hundreds of other Pods with web
defining the actual services, and this is a part services running on port 80. So how do we
3|Page

do that? As we did with the ReplicaSets In this case, we have multiple similar Pod
previously, running our web application.
and a technique that you will see very often They all have the same labels with a key app
in Kubernetes, we will use labels and and set to a value of my app.
selectors to link these together. We know The same label is used as a selector during
that the Pod was created with a label. the creation of the service.
We need to bring that label into the service So, when the service is created, it looks for a
definition file. So, we have a new property matching Pod with the label and finds three
in the specs section of them. The service then automatically
and that is called selector, just like selects all the three Pods
in a ReplicaSet and deployment definition as endpoints to forward the external request
files. coming from the user. You don't have to do
Under the selector provide a list of labels any additional configuration to make this
to identify the Pod. happen. And if you're wondering what
For this, refer to the Pod definition file algorithm it uses to balance the load across
used to create the Pod. the three different Pods,
Pull the labels from the Pod definition file it uses a random algorithm. Thus, the service
and place it under the selector section. acts as a built-in load balancer
This links the service to the Pod. Once done, to distribute load across different Pods. And
create the service using the finally, let's look at what happens when
kubectl create command, and input the the Pods are distributed across multiple
service definition file. And there you have nodes. In this case, we have the web
the service created. To see the created application on Pods on separate nodes in the
service run the kubectl get services cluster. When we create a service,
command that lists the service, the without us having to do any additional
ClusterIP, and the map ports. The type is configuration Kubernetes automatically
nodePort as we created creates a service that spans across all the
and the port on the node is set to 30,008, nodes in the cluster and maps the target port
because that's the port that we specified to the same node port on all the nodes in the
in the definition file. We can now use this cluster. This way you can access your
port to access the web service using curl or a application using the IP of any node in the
web browser. So curl to 192.168.1.2, which cluster and using the same port number
is the IP of the node. which in this case is 30,008. As you can see,
And then I use the port 30,008 to access the using the IP of any of these nodes,
web server. So far we talked about a service and I'm trying to curl to the same port, and
mapped to a single Pod. But that's not the the same port is made available
case all the time. What do you do when you on all the nodes part of the cluster. To
have multiple Pods? In a production summarize, in any case, whether it be a
environment, you have multiple instances single Pod on a single node, multiple Pods
of your web application running for high on a single node, or multiple Pods on
availability and load balancing purposes. multiple nodes, the service is created exactly
4|Page

the same without you having to do any Which, which of the three would it go to
additional steps during the service creation. and who makes that decision?
When Pods are removed or added, the A Kubernetes service can help us group the
service is utomatically updated, making it pods together
highly flexible and adaptive. Once created, and provide a single interface to access the
you won't typically have to make any pods
additional configuration changes. in a group.
For example, a service created for the
Cluster IP backend pods
will help group all the backend pods
In this lecture we will discuss about the together
Kubernetes service cluster IP. A full stack and provide a single interface
web application typically has different kinds for other pods to access this service.
of pods hosting different parts of an The requests are forwarded to one of the
pplication. pods
You may have a number of pods running a under the service randomly.
front end web server, another set of pods Similarly, create additional services for
running a backend server, a set of pods Redis
running a key value store like Redis and and allow the backend pods
another set of pods may be running a to access the Redis systems through the
persistent database like MySQL. The web service.
front end server needs to communicate to This enables us to easily
the backend servers, and the backend servers and effectively deploy a microservices based
need to communicate to the database as well application
as the Redis services, et cetera. on Kubernetes cluster.
So what is the right way to establish Each layer can now scale
connectivity or move as required without impacting
between these services or tiers of my communication
application? between the various services.
The pods all have an IP address assigned to Each service gets an IP and name assigned
them, to it
as we can see on the screen, inside the cluster, and that is the name that
but these IPs, as we know, are not static. should be used
These pods can go down anytime by other pods to access the service.
and new pods are created all the time This type of service is known as cluster IP.
and so you cannot rely on these IP addresses To create such a service, as always,
for internal communication between the use a definition file in the service definition
application. file first
Also, what if the first front end pod use the default template,
at 102440.03 need to connect to a backend which has API version, kind, metadata, and
service? spec.
5|Page

The APA version is V1, kind is service,

and we will give a name to our service.
We will call it backend.
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 ports, we have a target port and port.
The target port is the port where the backend
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 pod definition file and
copy the labels
from it and move 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 Get Services
command.
The service can be accessed
by other pods using the cluster IP or the
service name.