Kubernetes service types

Overview On Kubernetes

In Kubernetes, a service is an abstraction which denotes a set of conceptual pods where the application executes and an access policy for such pods types. A pod must first determine its IP address before it may connect to another pod. A means to locate certain pods is also provided by the Kubernetes services. In the Kubernetes networking concept, pod IP addresses are abstract; if a pod is destroyed or broken, a new pod would acquire the new IP address. In Kubernetes, a service frequently allows a pod or collection of pods access to the network. Then Services will select pods based on their names, and if a network request is given to these services, it will detect all of the cluster's pods that match the service's label, select one among them, and then send the request to it.

Kubernetes service types are the building blocks of service definitions. Each service type is defined by a set of properties that control how the services interact with each other and the resources they consume. The Kubernetes API uses these properties to create, update, and delete objects within the cluster. You can also combine different types of workloads by using multiple services from multiple service types.

Become a Kubernetes Certified professional by learning this Kubernetes Training!

Kubernetes Certification Training

• Master Your Craft
• Lifetime LMS & Faculty Access
• 24/7 online expert support
• Real-world & Project Based Learning

Explore Curriculum

ClusterIP

ClusterIP is a Kubernetes Service Type that allows the pods and services in a cluster to connect using IP addresses or hostnames. It's used primarily to provide external access to your Kubernetes cluster, but it can also be used to expose services on your cluster through a public IP address or DNS name.

• ClusterIP is the natural and default service type.
• The ClusterIP Service will get a cluster IP address from Kubernetes. As a result, the Service can only be accessed from within the cluster.
• Can’t make appeal to Service (pods) from the exterior cluster.
• You can alternatively set group IP in the assistance definition document.

Use Cases

l Cluster-wide inter-service communication Consider communication between your app's back & front-end components.

NodePort

NodePort is the default service type for Kubernetes. It maps to a port on a routable IP address. A nodePort is typically used for services that are not ephemeral but instead need to be bound to a set of ports for which you have control over the availability of those ports on your network (i.e., you can ensure that these services are always available from the same IP address).

• NodePort is an addition of Cluster-IP service. A ClusterIP Service has automatically created the Service routes of NodePort.
• It reveals the outside cluster service by adding a bunch of wide port on top of ClusterIP.
• NodePort uncovered the service on every Node's IP at a static port (the NodePort). (the NodePort).So, outer traffic approaches a decent port on every Node. Any requests to your cluster on the Nodeport are routed to the Service.
• You can contact the NodePort Administration, from outside the cluster, by mentioning :.
• The node port should be between 30000 and 32767. It is optional to manually assign a port to the Service. If it is not defined, Kubernetes will appoint one for you.
• If you select node port clearly, ensure that another service did not already use the port.

Use Cases

At the point when you need to enable the outer network to your service. Utilizing a NodePort allows you to set up your load-adjusting solution and configure environments not fully carry by Kubernetes.

If you want to Explore more about Kubernetes? then read our updated article - KubernetesTutorial!

Subscribe to our youtube channel to get new updates..!

Subscribe

LoadBalancer

A load balancer (LB) distributes incoming requests to multiple servers. An LB is typically deployed in front of a set of Kubernetes pods and can be used to direct traffic to the pods. It provides transparent access control, allowing you to specify different rules for different types of traffic. The LB can also scale out in several instances, which helps with high-traffic situations.

• It incorporates cloud-based load balancers with NodePort.
• It uncovers the external service using a cloud provider's load balancer.
• Every cloud provider (Azure, GCP, and AWS, so on) has its load balancer solution. The load balancer that the cloud supplier will set up will automatically redirect calls to Kubernetes Service.
• The outside load balancer routes traffic to the back-end Pods and the cloud supplier decides the technique for load adjusting.
• The genuine making of the load balancer happens nonconcurrent.
• Each time you need to open a support of the general public, you must build a new load balancer & get an IP address.

Use Cases

When a cloud provider hosts the Kubernetes cluster.

ExternalName

ExternalName is a Kubernetes resource that can represent the name of a service within a pod. This is usually used to create a DNS record for the pod's name, but it can also be used as a key-value store by other Kubernetes resources.

In this example, we will create a service with an external name of "example-service". The external name must start with "example-" and end with ".service".

• Services of type Outer Name map a Help of a DNS name, not to a customary selector..
• You define these Services with the `spec.externalName`.
• No proxying of any sort is laid out.

Use Cases

• This is typically used to construct a service inside Kubernetes to address an outside data store, such as a database that operates independently of Kubernetes.
• You can utilize that ExternalName service when Cases from one namespace converse with a help in another namespace.

Conclusion

In this post, we've discussed Kubernetes service types and their use case.

Kubernetes service types are helpful in differentiating between different kinds of Kubernetes resources. In particular, they help you distinguish between stateless and stateful services. Stateful services have more states than stateless ones; for example, a web server might store session information on each request, whereas a database service would not.

Related Articles :

• Docker Swarm Vs Kubernetes
• ElasticSearch On Kubernetes
• Kubernetes Certifications
• Kubernetes Ingress
• What Is Kubernetes?