Services

Introduction

• Services logically connect pods across the cluster to enable networking between them

• The lifetime of an individual pod cannot be relied upon; everything from their IP addresses to their very existence is prone to change.

• Kubernetes doesn’t treat its pods as unique, long-running instances; if a pod encounters an issue and dies, it’s Kubernetes’ job to replace it so that the application doesn’t experience any downtime

• Services make sure that even after a pod(back-end) dies because of a failure, the newly created pods will be reached by its dependency pods(front-end) via services. In this case, front-end applications always find the backend applications via a simple service(using service name or IP address) irrespective of their location in the cluster

• Services point to pods directly using labels. Services do not point to deployments or ReplicaSets. So, all pods with the same label gets attached to same service

• 3 types: ClusterIP, NodePort and LoadBalancer

Types of Services

ClusterIP

• ClusterIP service is the default Kubernetes service.

• It gives you a service inside your cluster that other apps inside your cluster can access

• It restricts access to the application within the cluster itself and no external access

• Useful when a front-end app wants to communicate with the back-end

• Each ClusterIP service gets a unique IP address inside the cluster

Note: Services point to pods directly using labels!!!

When services are not available

• Imagine 2 pods on 2 separate nodes node-1 & node-2 with their local IP address

• pod-nginx can ping and connect to pod-python using its internal IP 1.1.1.3.

• Now let’s imagine the pod-python dies and a new one is created.

• Now pod-nginx cannot reach pod-python on 1.1.1.3 because its IP is changed to 1.1.1.5.

Enter services…

• Services logically connect pods together

• Unlike pods, a service is not scheduled on a specific node. It spans across the cluster

• Pod-nginx can always safely connect to pod-python using service IP 1.1.10.1 or the DNS name of service (service-python)

• Even if the python pod gets deleted and recreated again, the nginx pod can still reach the python pod using the service but not with IP of the python pod directly

• Multiple ClusterIP services

NodePort

• NodePort opens a specific port on all the Nodes in the cluster and forwards any traffic that is received on this port to internal services

• Useful when front-end pods are to be exposed outside the cluster for users to access it

• NodePort is built on top of the ClusterIP service by exposing the ClusterIP service outside of the cluster

• NodePort must be within the port range 30000-32767

• If you don’t specify this port, a random port will be assigned. It is recommended to let k8s auto-assign this port

NodePort Limitations

• In the NodePort service, users can access applications using the URL http://<node-ip>:<node-port>

• In Production environment, we do not want the users to have to type in the IP address every time to access the application

• So we configure a DNS server to point to the IP of the nodes. Users can now access the application using the URL xyz.com:30001

• Now, we don’t want the user to have to remember the port number either.

• However, the NodePort service can only allocate high-numbered ports which are greater than 30,000.

• So we deploy a proxy server between the DNS server and the cluster that proxies requests on port 80 to port 30001 on the nodes.

• We then point the DNS to the proxy server’s IP, and users can now access the application by simply visiting xyz.com

Load Balancer

• A LoadBalancer service is the standard way to expose a Kubernetes service to the internet

• On GKE(Google Kubernetes Engine), this will spin up a Network Load Balancer that will give you a single IP address that will forward all external traffic to your service

• All traffic on the port you specify will be forwarded to the service

• There is no filtering, no routing, etc. This means you can send almost any kind of traffic to it, like HTTP, TCP, UDP or WebSocket's

• Few limitations with LoadBalancer:

▪ Every service exposed will gets its own IP address

▪ It gets very expensive to have external IP for each of the service(application)

• On Google Cloud, AWS, or Azure, a service type of LoadBalancer in the service manifest file will immediately run an Elastic / Cloud Load Balancer that assigns external IP (public IP) to your application

• But for on-prem or bare-metal k8s clusters, this functionality is not available

• Using service type as LoadBalancer on bare-metal will not assign any external IP and service resource will remain in a Pending state forever

We will the practical demonstration of Kubernetes Services in the next blog

That's a wrap........