Kubernetes Service & Endpoints

4 min readMar 19, 2022

Kubernetes service can act as an abstraction which can provide a single IP address and DNS through which pods can be accessed.

A service gets allocated a virtual IP address as well (called a clusterIP in Kubernetes), and lives until explicitly destroyed. Requests to the service get redirected to the appropriate pods, thus the service serves as a stable endpoint used for inter-component or application communication.

KUBERNETES SERVICE TYPE:

NodePorts, LoadBalancers, and Ingress are different ways to get external traffic into a Kubernetes cluster

ClusterIP :

A ClusterIP service is the default type of service in Kubernetes. It creates a service inside the Kubernetes cluster, which can be accessed by other applications in the cluster, without allowing external access.

NodePort :

A NodePort service opens a specific port on all the Nodes in the cluster, and any traffic sent to that port is forwarded to the service.

If the service type is NodePort, then kubernetes will allocate a port default:( 30000–32767 ) on every worker node.
Each node will proxy that port into your service.

Challenge with NodePort
We need to access it via IP/DNS: Port
example: kubernetes.com:31418

And the above is not good way for end-user to use the URL along with Port.

LoadBalancer :

A LoadBalancer is a standard way to expose a Kubernetes service externally so it can be accessed over the internet.

LoadBalancer Service Type will automatically deploy an external load balancer.
This load balancer takes care of routing requests to the underlying service.

The overall implementation of LoadBalancer depends on Cloud Provider
If you plan to use it in bare-metal, then you will have to provide own load balancer implementation.

Ingress :

Ingress is actually not a type of service. It sits in front of multiple services and performs smart routing between them, providing access to your cluster. There are several types of ingress controllers that have different routing capabilities. In GKE, the ingress controller creates an HTTP Load Balancer, which can route traffic to services in the Kubernetes cluster based on path or subdomain.

Sample Service Definition:

# Create a service — expose POD
kubectl expose pod nginx --name ngx-service — port=80 --target-port=80#Create a service- Expose Deployment
kubectl expose deployment nginx --name ngx-dep-service --port=80 — target-port=9080# Create a NodePort Service
kubectl expose deployment nginx --name Nod-port-service --port=80 --target-port=9080 --type=NodePort

A service in Kubernetes can be created via an API request by passing in a service definition such as:

kind: Service
apiVersion: v1
metadata:
  name: service1
spec:
  selector:
    app: App1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9336

In above sample example, the new service is named service1 and will target TCP port 9336 on any pod with the metadata label "app=App1" . Kubernetes constantly evaluates the service’s label selector to determine at any given moment which pods are included in the service. This means that a new service can include existing pods that already match the label selector.

To facilitate port changes in the pods/applications, Kubernetes supports strings for targetPorts, so each pod in the service can expose a different port, as long as there’s a mapping to a commonly named port. This allows, for example, to change the port number that pods expose in the next version of your backend software, without breaking clients.

ENDPOINTS

Endpoints tracks the IP address of the objects that service can send traffic to. Basically, the endpoints are the backend pod IPs & port. Kubernetes service will connect to the pods using this endpoints.

Endpoint can be viewed using below command

kubectl get endpoints.

An endpoint resource is referenced by a kubernetes service, so that the service has a record of the internal IPs of pods in order to be able to communicate with them.