Kubernetes Service Types
There are various services types involved in Kubernetes that help group pods into a single end point to be attached to services for stable IP addresses.
Join the DZone community and get the full member experience.Join For Free
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
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.
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.
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.
Opinions expressed by DZone contributors are their own.