A service is a logical collection of pods. It can be characterized as an abstraction on top of the pod that gives users access to pods via a single IP address and DNS name. It is quite simple to manage load balancing settings with Service. It also makes scaling for pods relatively simple.
Using a single endpoint and a Kubernetes service, it is simple to expose an application running across a number of pods. A service is both a REST object and an abstraction that defines:
- A set of pods
- A policy to access them
In a Kubernetes deployment, pods are frequently created and deleted, resulting in continual IP address changes. The deployed application will experience discoverability problems, making it challenging for the application frontend to decide which pods to connect to. The benefits of Kubernetes services become apparent in this situation. Services monitor any changes to the pods IP addresses and DNS names, and they present such changes to the end user as a single IP address or DNS.
Kubernetes services utilize selectors to target a set of pods.
Types of Kubernetes services -
There are four types of Kubernetes services:
1. ClusterIP
This is the default type that exposes the service on an internal IP of the cluster. These services are only accessible within the cluster. Therefore, in order to expose a ClusterIP to a larger influx of traffic, users must implement port forwarding or a proxy.
2. NodePort
A NodePort service exposes the service on the IP of each node at a static port. A ClusterIP service is created automatically to route the traffic to the NordPort service. Users can communicate with the service from the outside by requesting <NodeIP>:<NodePort>
The required node port range is 30000–32767. It's not necessary to manually assign a port to the service. If it isn't defined, Kubernetes will choose one for you. Make sure the port is not already in use by another service if you choose the node port explicitly.
3. LoadBalancer
This is the preferred solution to expose the cluster to the wider internet. The LoadBalancer type of service will create a load balancer (load balancer type depends on the cloud provider) and expose the service externally. It integrates NodePort with cloud-based load balancers.
It will also automatically create ClusterIP and NodePort services and route traffic accordingly.
Each cloud provider (AWS, Azure, GCP, etc) has its own native load balancer implementation. The load balancer that the cloud provider builds will automatically direct requests to your Kubernetes Service.
The load balancer is actually created asynchronously. You must create a new LoadBalancer each time you want to expose a service to the public and obtain an IP address.
4. ExternalName
This type of service maps the service to the contents of the externalName field (Ex: build.test.com). It does this by returning a value for the CNAME record.
Discovering Kubernetes services
A service can be discovered using either a DNS query or an environment variable.
1. DNS
For service discovery, this is a preferred approach. The DNS server that keeps an eye on the Kubernetes API and produces DNS records for each new service is now added to the Kubernetes cluster. All Pods inside the cluster will be able to perform service name resolution once the DNS is activated.
2. Environment Variables
For each active service, the kubelet adds environment variables to Pods using this technique. When using this method, the desired service must be created before creating the Pods which will use that service. Otherwise, the Pods would not get the necessary environment variables for the desired service.
We've now covered the fundamentals of Kubernetes services. We will take a look at deploying services in next blog post.
Thank you for reading!
*** Explore | Share | Grow ***
댓글