K8s services

First, let’s start with a quick story to comprehend the pain points without K8s services.

Suppose you started a new contact center business. Initially, you started with inbound calls for insurance businesses only. You hired around 10 agents. Now the concern is how customers will contact the agents. You started with the most basic solution and published all 10 numbers on your website and customer can call any of these numbers.

Let’s think about the problems:

• Notify customers if the count of agents in the contact center changes.
• Notify customers (which you probably even don’t know) if the contact number to the agents has changed.
• The distribution of the inbound calls across the agents is unequal.
• Think about the user experience in the worst case where all agents are already on a call with other customers.

Suppose now you started to serve multiple businesses from your contact center e.g. property and insurance. Now customers even have to differentiate the contact numbers for each category which increases the overhead of customers.

The above scenarios are also valid for the pods without the service, hence K8s introduced the services.

Let’s take a step back and think about services in a world without K8s. Suppose in a platform like swiggy, the order service needs to communicate with the notification service to send a notification to the customer once the order has been placed.

Problems without K8s service

One solution here is to store the IP address of the notification service in the configuration of the order service. Albeit this solution is not valid in the K8s world because of the pain points similar to what you read above in the contact center story.

Configuration files are not valid solutions in K8s because:

• Pods can go down and come up anytime due to various reasons eg. scale-up pods, cluster node crash, an issue with kubelet, etc.
• Pod IP can be known only after the pod has been started on the node.
• The client has to take responsibility for the distribution of traffic across multiple pods.

K8s service

K8s service is a type of Kubernetes resource that provides a single entry point to a set of replica K8s pods.

When you create a K8s service resource it gets assigned with an IP and port. This IP and port are immutable throughout the lifecycle of the service. IP and port are used by the clients to interact with the pods behind the service.

Let’s again review a use case of service, suppose want to run multiple instances of the web-tier of your application and a single instance of the database tier.

In web-tier, a number of instances keep on changing, and database-tier let’s assume it can move across the cluster and IP address can keep on changing. But ideally, the client shouldn’t be aware of these changes. Hence you can create one service for the web tier and one for the database-tier

Another question arises here, how service know which pods are part of the service?

In service, you specify a label selector, K8s filters the pod based on the label satisfying the criteria and create the endpoint. An endpoint is used by the service for the distribution of the traffic to the pods.

A lot of theory !!!

Create our first service with file service1.yaml

apiVersion: v1
kind: Service
metadata:
  name: first-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: first-app

Anatomy:

• Service name is first-service
• It accepts requests on port 80
• Service redirect the traffic to the pod at port 8080
• Service find the pods with label app: first-app

Now you can create a service by running the following command:

kubectl apply -f service1.yaml

List K8s services

kubectl get svc

Get detail on the service

kubectl describe svc first-service

If you look closely at the IP address, this is the IP address internal to the cluster, which means by default service is not accessible from the outside of the cluster. Though like the above example of order service and notification service if both the running in the same cluster, then they can access each other. To create a service accessible from outside you need to create a service of the type load balancer

In certain scenarios, you may want the client request from the same client will always be redirected to the same pod. K8s support a feature called session affinity. Though K8s support session affinity only one IP address only. K8s doesn’t support cookie-based affinity because K8s works at TCP/UDP layer.

spec:
  sessionAffinity: ClientIP