In last blog, we discussed about the compute abstraction of kubernetes. In that blog, we discussed about creating a pod with nginx container. At the end of the blog, we needed ability to expose nginx pod for consuming it services. To do that, we need to understand how networking works in kubernetes.So in this fourth blog of the series, we are going to discuss various network related abstractions provided kubernetes. You can access all the blog in the series here.
Network abstractions in the kubernetes are the one which facilitate the communication between the pods or the communication of the pods from external world. Commonly these are known as service abstractions.
In the following sections, we are going to explore different service abstractions.
As part of the pod definition, we can define which ports to be exposed from the container using containerPort property. This will expose that specific port in the container on it’s ip address.
Let’s define port at 80 in our nginx deployment.
You can access complete file here.
Once we defined the container port, next step is to define service.
Service abstraction defines a set of logical pods. This is a network abstraction which defines a policy to expose micro service using these pods to other parts of the application.
This separation of container and it’s service layer allows us to upgrade the different parts of the applications independent of each other. This is the strength of the microservice.
Let’s define a service for our nginx deployment.
The above configuration defines the service. The import sections to focus are
kind - As we specified with pod and deployment abstractions, we specify the service using this parameter.
selector - Connecting pods with service. This is the way kubernetes knows which pod to forward the requests to the service. In this , we are specifying the selector on label called name and it’s value nginx. This should be same labels that we have specified in the nginxdeployment.yaml. The below was the our deployment definition
In above configuration, we have specified the labels in our template. This shows how label abstraction is used to connect service and pod abstractions.
- ports - This specifies the ports which service should connect on the container. By default the service port on which it listens is same as container port. You can change it if you want by specifying the targetPort parameter.
You can access complete configuration on github.
Once we have defined the configuration, we can start the service using below command.
We can list all the services, as below
It should show the service running below.
Now we have successfully started the service.
Service we have created above is only accessible within the kubernetes cluster. There is a way to expose the service to external world, but we will be not discussing that in this post.
To connect to the service, we need to know the machine it runs. As we are running kubernetes in local mode, it will be virtual machine running minikube.
Run below command to get the end point details
It should show the output as below.
In above command, we are describing the complete information about service. We are interested in the EndPoints parameter. This gives the IP and port of the machine to which we can connect. Note that the actual values of these parameter will be different on your machine.
Testing with busy box
Now we have end point to call. But we need another pod in cluster to connect to this machine. So let’s run another pod
The above command shows another way creating and running the pods. The different pieces of the command are
run - Specifies create and run pod
-i - Specifies run the pod interactively. This allows us to send commands using pod
–tty - Gives access to the terminal of the pod
busybox - Name of the pod.
–image - image to run inside the container. We are a running an image called busybox, which gives minimal linux shell utilities
– restart-never - Since it’s a temporary pod, we don’t need HA
sh - Specifies run shell command to access
Once you run the above command, you should drop into a familiar linux shell.
From the shell, run below command
Replace the IP address with the one you got from end point. This should print the welcome page of nginx as below
Now we have successfully connected our service and used our pod.
Service layer of the kubernetes may look little complicated. It is. It’s built for varieties of use cases. So it has multiple layer of redirection. We will explore more about this abstraction in upcoming posts.
In this blog, we have discussed how to define and consume services. Services are one of the important features of the kubernetes which makes it powerful platform to deploy clustered applications.
Now we know pod, deployment and service abstractions. These are minimal abstractions we need, to build our spark cluster on kubernetes. In next post, we will be discus how to build and scale spark cluster on kubernetes.