Hello and welcome to this lecture.
My name is Mumshad Mannambeth. In this lecture we will discuss about Kubernetes Services. Kubernetes
Services enable communication between various components within and outside of the application. Kubernetes
services helps us connect applications together with other applications or users.
For example our application has groups of pods running various sections such as a group for serving
front end load to users and other group for running back end processes and a third group connecting
to an external data source.
It is services that enable connectivity between these groups of pods services enable the front end
application to be made available to end users it helps communication between back end and front end
pods 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 pods 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 us look at the existing setup.
The Kubernetes Node has an IP address and that is 192.168.1.2. My laptop is
on the same network as well.
so it has an IP address 192.168.1.10.
The internal POD network is in the range
10.244.0.0 and the POD has an IP 10.244.0.2.
Clearly, I cannot ping or access the POD at address 10.244.0.2 as its in a separate network.
So what are the options to see the webpage? First,
if we were to SSH into the kubernetes node at 192.168.1.2, 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 could fire up a browser
and see the webpage in a browser following the address http://10.244.0.2. But this is from inside
the kubernetes Node 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 SSH into the node and simply by accessing the IP of the kubernetes
node.
So we need something in the middle to help us map requests to the node from our laptop through the node
to the POD running the web container.
This is where the kubernetes service comes into play.
The kubernetes service is an object just like PODs, Replicasetor Deployments that we worked with
before.
One of its use case is to listen to a port on the Node and forward requests on that port to a port
on the POD running the web application.
This type of service is known as a NodePortservice because the service listens to a port on the Node
and forwards requests to PODs.
There are other kinds of services available which we will now discuss.
The first one is what we discussed already.
NodePortwere the service makes an internal POD accessible on a Port on the Node.
The second is cluster 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 back end servers.
The third type is a LoadBalancer, were it provisions a load balancer for our service in supported cloud
providers.
A good example of that would be to distribute load across the different web servers in your front end
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 NodePortKubernetes Service.Getting back to NodePort,
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 POD. Let’s take a
closer look at the service.
If you look at it there are three ports involved.
The port on the POD were the actual web server is running is 80. And it is referred to as the targetPort
because that is were the service forwards the requests 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 30008.
That is because NodePorts can only be in a valid range which by default is from 30000 to
32767.
Lets now look at how to create the service.
Just like how we created a Deployment, ReplicaSet 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 specs sections the API version is going to be V1.
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 spec and as always this is the most crucial part of the file and that is where we will
be defining the actual services.
And this is the part of a definition file that differs between different objects.
Next we have spec 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 set it has nodeport.
The next part of a spec 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 NodePort which we will set to 30008 or any number in the valid range.
Remember that out of these the only mandatory field is port if we don't provide a target port.
It is assumed to be the same as port.
and if you don’t provide a nodePort a free port in the valid range between 30000 and
32767 is automatically allocated. Also note that ports is an array.
So no the dash under the port section that indicate the first element
in the array. You can have multiple such port mappings within a single service. So we have all the information
in
but something is really missing.
There is nothing here in the definition file that connects the service to the pod.
We have simply specified the target port but we didn't mention the target port on which pod.
There could be 100s 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 kubernetes, 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 spec section
and that is called selector.
Just like in a replica set and deployment definition files under the selector provide a list of labels
to identify the pod for this.
Refer 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 pod.
Once done create the service using the kubectlcreate command and input the service-definition file
and there you have the service created. To see the created service, run the kubectlget services
command that list the service the cluster IP and the map port.
The type is node port as we created and the port on the node is set to 30008 because
that's the port that we specified in the definition file.
We can now use this port to access the web service using curl or a web browser.
So curl to 192.168.1.2 which is the IP of the node and then use the port 30008
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 set 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 pods as endpoints to forward the external requests
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 pods
it uses a random algorithm does the service acts as a built in load balancer to distribute load across
different pods and finally let us look at what happens when the pods are distributed across multiple
nodes.
In this case we have the web application on pods on separate nodes in the cluster.
When we create a service without us having to do any additional configuration kubernetes 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 30008 as you
can see using the IP of any of these nodes.
And I'm trying to curl 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 pod on a single node multiple pods on a single node
or multiple pods on multiple nodes the service is created exactly the same without you having to do
any additional steps during the service creation when pods are removed or added.
The service is automatically updated making its highly flexible and adaptive once created.
You won't typically have to make any additional configuration changes that's it for this lecture and
I will see you in the next lecture.