Kubernetes Service Types

Services in Kubernetes are used to group pods into a single endpoint. As Pods can be recreated, they can be attached to services for stable IP addresses.

A service can be defined using yaml file. Example of Kubernetes service using yaml file is given below. The "targetport" specified in the yaml file is the port value where the container is running.

apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8085

There are different service types used in Kubernetes. These services differ by how they expose Pods internally or externally and how they handle the traffic. The different services types are described below.

Kubernetes Service Types

Cluster IP

This is the default service that uses an internal ClusterIP to expose Pods. In ClusterIP, the services are not available for external access of the cluster and used for internal communications between different Pods or microservices in the cluster.

apiVersion: v1
kind: Service
metadata:
  name: clusterip-demo-service
spec:
  selector:
    app: myapp
  type: ClusterIp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8085

In the above configuration, the container running in Pod is exposed on 8085 port and the ClusterIP service port is running on 80. Any internal service can connect to this port 80 to access this Pod.

NodePort

This service exposes outside and allows the outside traffic to connect to Kubernetes Pods through the node port which is the port opened at Node end.

The Pods can be accessed from external using <NodeIp>:<Nodeport>

If there are multiple nodes, multiple IP addresses with the same port can be exposed.

The sample yaml configuration for NodePort is given below.

apiVersion: v1
kind: Service
metadata:
  name: nodeport-demo-service
spec:
  selector:
    app: myapp
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8085
      nodePort: 30070

NodePort value is the port exposed at Node end where the external traffic can connect.

TargetPort value is the port exposed by the container running in the Pod

Port value is the port that can be connected by the internal services in the cluster.

As per the above configuration, the container running in Pod is exposed on port 8085 which is mapped with nodeport and port values. The external traffic can connect through <NodeIp>:30070 to access the Pod, the internal traffic can connect through 8085 port to access the Pod.

The limitation of the NodePort service is when the node changes or port number changes, the client has to change to a new port or ip address.

LoadBalancer 

This service will use or dynamically create an external load balancer like a cloud load balancer when running in the cloud. This uses Network load balancer (Layer 4 load balancer).  This generates additional costs for additional load balancer components. The advantage of this service is external load balancer features can be leveraged.

The sample yaml configuration is as below.

apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-demo-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8085
  type: LoadBalancer

Ingress: This service allows the routing of HTTP(S) traffic according to defined rules like path-based routings. This can be associated with one or more service objects where these services are further associated with Pods. The ingress controller creates HTTP(S) load balancer Layer 7 load balancer which are configured automatically using the definition in the Ingress object.

The sample yaml configuration for Ingress is as given below.

apiVersion: v1
kind: Ingress
metadata:
  name: Ingress-demo-service
spec:
  rules:
  - http:
      paths:
      - path: /customer
        backend:
          service:
            name: customerservice
            port: 
              number: 8080
      - path: /product
        backend:
          service:
            name: productservice
            port: 
              number: 8085

In the above configuration, the ingress is configured where http(s) requests to /customer path are sent to the customer service running in port 8080, http(s) requests to /product path are sent to product service running in port 8085.