K8s KnowHow: Using A Service

This is the second article of the Kubernetes Knowhow series. In this article, we will see how to expose a pod to the outside world. In the last article https://dzone.com/articles/k8s-knowhow-running-first-pod-1, we learned how to run a Spring Boot sample application in a pod. We also learned to start an interactive shell in order to access pod.  However, we could not access the welcome url from outside of K8s cluster, for an instance from the browser, a Rest client. Now, the next step is to expose this pod outside of K8s cluster. Let’s get started!

I will start with our pod definition.

K8s pods are mortal. In addition, each pod gets its own IP address and IP addresses are not fixed. That means IP addresses are not relied upon. For instance, if the pod is restarted then it is quite possible that pod gets a different IP address in a subsequent run. In addition, the pod is not visible outside the K8s cluster. So what is the solution? Service comes to our rescue.

K8s service is an abstraction that defines a logical set of pods and policy by which to access them. Service is a REST object just like a pod and has an endpoint so that service can be accessed from outside provided type supports visibility. What the heck does it mean? It implies that even Service can be hidden from the outside world. Let us first understand service types.

In the current version of K8s, the following four service types are supported.

• ClusterIP – Exposes the service on cluster internal IP. That means the service is accessible inside the cluster only. This is the default service type.
• NodePort – Exposes the service outside. This is something extremely useful to us considering the purpose of the article. With the NodePort service type K8s exposes the service on Node’s IP at fixed static port. A ClusterIP service, to which the NodePort service will route, is automatically created. In addition, NodePort service is accessible from outside at <NodeIP>:<NodePort>.
• LoadBalancer – Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.
• ExternalName – Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value.

We will see NodePort with scrupulous attention at the end of this article.

Let us first see the service definition in order to expose above pod (refer to pod definition above).

K8s reserves a nodePort on all its nodes. All nodes that running the Service's pods have this port open. Now, this is happening because of Kube-Proxy, ipTable, and routing. Kube-Proxy uses the ipTables to resolve the requests coming on a specific nodePort and redirect them to appropriate pods. Kubernetes master allocates a port from a range specified by the --service-node-port-range   flag (default: 30000-32767), and each Node will proxy that port (the same port number on every Node) into your Service. That port will be reported in service’s .spec.ports[*].nodePort field.

A NodePort exposes the following:

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Now it’s time to get into some action. Let us apply the changes pertaining to the service configuration. I am assuming that pod is up and running as follows.

Now get the IP address of the cluster and hit the browser. Navigate to http://<minikube_ip_address>:31080/welcome and you should see the welcome page.

Just to summarize, K8s Service is the abstraction that allows pods to die and replicate in Kubernetes without affecting your application. A Service routes traffic across a set of Pods. Discovery and routing among dependent Pods are handled by Kubernetes Services.