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

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.

Container Port

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.

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.

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

kubectl run -i --tty busybox --image=busybox --restart=Never -- sh

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

wget -O - http://172.17.0.4

Replace the IP address with the one you got from end point. This should print the welcome page of nginx as below

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.

Conclusion

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.

What’s Next?

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.