Introduction to Kubernetes Services

This article extends my notes from an Udemy course "Kubernetes for the Absolute Beginners - Hands-on". All course content rights belong to course creators. 

The previous article in the series was Introduction to Kubernetes Networking | My Public Notepad

Kubernetes services:

• Service is an abstraction that defines a logical set of Pods and a policy by which to access them.
• Services ensure stable network endpoints for applications, providing internal load balancing and enabling communication between different components of an application within the cluster, as well as exposing them to the outside world.
• Enable communication between various components within and outside of the application
• Help connecting applications together with other applications or users

For example, our application has groups of pods running various sections, such as a group for serving a 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 microservices in our application.

Introduction to Kubernetes Networking | My Public Notepad explains how pods communicate with each other through internal networking. We now need to cover external communication.

Let's assume we deployed a pod, having a web application running on it. How does an external user access the web page? First of all, let's look at the existing setup:

• The Kubernetes node has an IP address e.g. 192.168.1.2
• Our laptop is on the same network as well, so it has an IP address e.g. 192.168 1.10
• The internal pod network is in the range 10.244.0.0
• The pod has an IP 10.244.0.2

We cannot ping or access the pod at address 10.244.0.2 from our laptop as it is in a separate network.

If we SSH into the Kubernetes node at 192.168.1.2 from, we would be able to access the pod's web page by using curl http://10.244.0.2. Or if the node has a GUI, we would fire up a browser and see the web page in a browser following the address http://10.244.0.2. But this is from inside the Kubernetes node, and that's not what we really want.

We want to be able to access the web server from our 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 a Kubernetes object, just like pods, replica set or deployments. There are several kinds of services:

• NodePort service opens a port on the node, listens on it and forwards requests on that port to the port on the pod running the web application. It makes an internal pod accessible on a port on the node. It exposes the service on a static port on each Node's IP, allowing external traffic to reach the service. More info: Kubernetes NodePort Service | My Public Notepad
• Cluster IP service creates a virtual IP inside the cluster to enable communication between different services, such as a set of frontend servers to a set of backend servers.
• Load balancer provisions a load balancer for our application in supported cloud providers. A good example of that would be to distribute load across the different web servers in your front end tier.

Here's an example of Service manifest:

apiVersion: v1

kind: Service

metadata:

  name: my-app-service

  labels:

    app: my-app

  namespace: prod

spec:

  type: NodePort

  ports:

  - port: 80

    protocol: TCP

    targetPort: 8000

  selector:

    app: my-app

Service DNS Name

In Kubernetes (and therefore EKS), every Service gets a unique DNS name that follows this format:

<service-name>.<namespace>.svc.cluster.local

• <service-name> → the name of your service (metadata.name)
• <namespace> → the namespace the service lives in
• svc.cluster.local → the cluster domain (default in Kubernetes; can be customized but rarely is)

Fully qualified DNS name (FQDN) of the service above will be:

my-app-service.prod.svc.cluster.local 

Services are namespace-specific

In Amazon EKS (and Kubernetes in general), service names only need to be unique within a namespace. Two services in different namespaces can have the same name, because their fully qualified domain names (FQDNs) are different.

For example:

Service my-app-service in namespace namespace-a → DNS:

my-app-service.namespace-a.svc.cluster.local

Service my-service in namespace namespace-b → DNS:

my-app-service.namespace-b.svc.cluster.local

Both can coexist without conflict.

The only caveat: if we try to reference the service without specifying the namespace, Kubernetes will default to looking in the current namespace. So if we want to call across namespaces, we’ll need to use the FQDN or specify the namespace explicitly.

To list all services in some namespace:

kubectl get svc -n <namespace>

---