What are Services in K8s?

Introduction to Service Types in K8s — Types of Kubernetes Services.

There are four types of Kubernetes services — ClusterIP, NodePort, LoadBalancer and ExternalName. The type property in the Service's spec determines how the service is exposed to the network.

1. ClusterIP

• ClusterIP is the default and most common service type.

• Kubernetes will assign a cluster-internal IP address to the ClusterIP service. This makes the service only reachable within the cluster.

• You cannot make requests to service (pods) from outside the cluster.

• You can optionally set cluster IP in the service definition file.

Use Cases

• Inter-service communication within the cluster. For example, communication between the front-end and back-end components of your app.

2. NodePort

• NodePort service is an extension of ClusterIP service. A ClusterIP Service, to which the NodePort Service routes, is automatically created.

• It exposes the service outside of the cluster by adding a cluster-wide port on top of ClusterIP.

• NodePort exposes the service on each Node’s IP at a static port (the NodePort). Each node proxies that port into your Service. So, external traffic has access to a fixed port on each Node. It means any request to your cluster on that port gets forwarded to the service.

• You can contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.

• The node port must be in the range of 30000–32767. Manually allocating a port to the service is optional. If it is undefined, Kubernetes will automatically assign one.

• If you are going to choose node port explicitly, ensure that the port was not already used by another service.

Use Cases

• When you want to enable external connectivity to your service.

• Using a NodePort gives you the freedom to set up your load-balancing solution, configure environments that are not fully supported by Kubernetes, or even expose one or more nodes’ IPs directly.

• Prefer to place a load balancer above your nodes to avoid node failure.

3. LoadBalancer

• LoadBalancer service is an extension of the NodePort service. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.

• It integrates NodePort with cloud-based load balancers.

• It exposes the Service externally using a cloud provider’s load balancer.

• Each cloud provider (AWS, Azure, GCP, etc) has its own native load balancer implementation. The cloud provider will create a load balancer, which then automatically routes requests to your Kubernetes Service.

• Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.

• The actual creation of the load balancer happens asynchronously.

• Every time you want to expose a service to the outside world, you have to create a new LoadBalancer and get an IP address.

Use Cases

• When you are using a cloud provider to host your Kubernetes cluster.

This type of service is typically heavily dependent on the cloud provider.

4. ExternalName

• Services of type ExternalName map a Service to a DNS name, not to a typical selector such as my-service.

• You specify these Services with the spec.externalName parameter.

• It maps the Service to the contents of the external name field (e.g. foo.bar.example.com), by returning a CNAME record with its value.

• No proxying of any kind is established.

Use Cases

• This is commonly used to create a service within Kubernetes to represent an external datastore like a database that runs externally to Kubernetes.

• You can use that ExternalName service (as a local service) when Pods from one namespace talk to a service in another namespace.

Task-1:

Create a Service for your Django-todo Deployment from Day-32.

Create a Service definition for your Django-todo Deployment in a YAML file.

In this example, the Service type is set to NodePort, and a nodePort is defined as 30080. This will make the Service accessible from outside the cluster by using the IP address of any node in the cluster and the nodePort defined in the Service.

**apiVersion: v1:**This section defines the API version to use, in this case, v1.

Kind: Service: This section specifies the type of resource you are creating, in this case, a Service.

metadata: name: Django-todo: This section gives the Service a name, in this case, Django-todo

spec: selector: app: Django-todo: This section defines the selector for the pods that the Service should target. In this case, it will target pods with the app label set to Django-todo.

type: NodePort: This section specifies the type of Service you want to create, in this case, NodePort.

ports: - protocol: TCP port: 8001 targetPort: 8000 nodePort: 30080:

This section defines the port mapping for the Service. The Service will listen on port 8000 and forward traffic to the target port 8000 on the pods. Additionally, a nodePort is defined as 30080, which will make the Service accessible from outside the cluster by using the IP address of any node in the cluster and the nodePort defined in the Service.

Apply the Service definition to your K8s (kubeadm) cluster using the below command

 kubectl apply -f service.yml -n <namespace-name>

The kubectl get svc command is used to list Services in a Kubernetes cluster.

The -n option is used to specify the namespace where the Service is located.

kubectl get svc -n <namespace>

need to open the 30080 port on a worker node.

Task-2:

Create a ClusterIP Service for accessing the Django-todo from within the cluster

Create a ClusterIP Service definition for your Django-todo Deployment in a YAML file.

In the above example, the Service is named Django-todo and is of type ClusterIP. The selector app: Django-todo is used to determine which Pods to associate with the Service. The Service has a single port, 8000, which is mapped to the target port 8000 on the Pods.

Apply the ClusterIP Service definition to your K8s (kuebadm) cluster using the kubectl apply -f service.yml -n <namespace-name> command.

Verify that the ClusterIP Service is working by accessing the Django-todo from another Pod in the cluster in your Namespace.

Task-3:

Create a LoadBalancer Service for accessing the Django-todo from outside the cluster

Create a LoadBalancer Service definition for your Django-todo Deployment in a YAML file.

In this example, the Service is named Django-todo and is of type LoadBalancer. The selector app: Django-todo is used to determine which Pods to associate with the Service.

Apply the LoadBalancer Service definition to your K8s (kubeadm) cluster using the kubectl apply -f service.yml -n <namespace-name> command.

Verify that the LoadBalancer Service is working by accessing the todo-app from outside the cluster in your Namespace.

Note: - This type of service is typically heavily dependent on the cloud provider.

Thank you for reading!! I hope you find this article helpful......