What are Services?
Services are a fundamental part of the Kubernetes networking model and are used to expose pods and deployments to the network, allowing them to communicate with each other and with external clients by enabling network access to a set of Pods in the Kubernetes cluster, by defining a logical set of the Pods and a policy to access them such as IP, ports, protocol, etc.
In Kubernetes, a Service is an abstraction that defines a logical set of pods and a policy by which to access them. It provides a stable IP address and DNS name, and can load balance traffic between pods and are a key component of Kubernetes networking and is used to expose applications running in a cluster to the network.
It is important to know that the lifecycle of a pod and service are not connected, so even if the pod dies the IP address and service will be running.
Basic Configuration of a Kubernetes Service
Services can be configured in two ways, With a selector or without a selector;
without selector:
apiVersion: v1
kind: Service
metadata:
name: My_Service_without_selector
spec:
ports:
- port: 8080
targetPort: 31060
Service With Selector:
A Service in Kubernetes can be configured with a selector to specify which pods it should expose to the network. A selector is a key-value pair that is used to identify pods in the cluster. The selector is defined in the Service's YAML file and is used by the Service to find the pods that it should expose to the network.
Here is an example of how to define a Service with a selector:
apiVersion: v1
kind: Service
metadata:
name: My_Service_with_selector
spec:
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080
type: ClusterIP
In this example, the Service has a selector with the key "app" and the value "my-app". The Service will expose all pods that have a label with the key "app" and the value "my-app". The Service is also configured to listen on port 80 and forward traffic to port 8080 on the target pods. The Service type is set to ClusterIP, meaning that the Service will be accessible only within the cluster.
Difference between Kubernetes Service and Deployment
A deployment is responsible for keeping a set of pods running, while a service is responsible for allowing a set of pods to access the network. We could use a no-service deployment to keep a set of identical pods running in the Kubernetes cluster, where the deployment could be scaled up and down and the pods replicated. Each pod can be accessed individually via direct network requests (rather than abstracting them behind a service), but the downside is that this is difficult to track for many pods.
You could also use a service without deploying it, but we would have to build each pod individually (instead of "all at once" like a deployment), which is extremely complex, especially for a large application. Our service could then forward network requests to these pods by selecting them based on their labels.
Types of Services
There are different ways to route the internet from services to your Kubernetes cluster.
ClusterIP
Cluster IP is a virtual IP, which is technically a fake IP network it is only accessible from within the cluster and is not exposed to the internet. Service can provide a unified entry address for a group of container applications with the same function, and distribute the request load to each container application in the backend through the ClusterIP.
Cluster IP is Kubernetes's internal IP and is only allocated to the service which is the entry point of the cluster. ClusterIP is more flexible than NodePort but less flexible than LoadBalancer and is commonly used for communication between services or pods within a cluster, for example, to allow one microservice to communicate with another, it also has the additional function of providing a load-balanced IP address.
Basic Yaml Configuration of a ClusterIP
apiVersion: v1
kind: Service
metadata:
labels:
k8s-app: first-dashboard
name: first-dashboard
namespace: first-dashboard
specs:
ports:
- port: 443
targetPort: 8443
selector:
k8s-app: first-dashboard
targetPort: is the port that containers are listening on.
namespace: serves as a virtual wall between multiple clusters.
kubectl describe service <YourserviceName>
The ClusterIP method is not suitable to expose production services to clients.
NodePort
This is the most primitive way of exposing services to the Internet, it is a way to expose a service to the internet by assigning it a specific port on each node in the Kubernetes cluster. This port can be accessed from outside the cluster, allowing external traffic to reach the service. The traffic is then forwarded to one of the pods backing the service.
NodePort is the simplest type of service, but it is less flexible than ClusterIP or LoadBalancer. It is usually used for development and testing purposes, or for simple use cases where external traffic only needs to reach a single service.
Basic Yaml Configuration of a NodePort
apiVersion: v1
kind: Service
metadata:
name: service-hostname
namespace: default
spec:
selector:
app: echo-hostname
type: NodePort # Type is specified as NodePort
ports:
- name: http
port: 80
targetPort: 80
nodeport: 31060 # Nodeport is specified
protocol: TCP
spec: Exposes the service on a static port on each node so that we can access the service from outside the cluster.
selector: selects pods with the label "app" set to "echo-hostname"
type: NodePort - makes service available to network requests from an external client
- name: HTTP - forwards requests to pods with the label of their value.
targetPort: this is the port that containers are listening on.
nodeport: this is the port number exposed internally in the cluster.
Note: We need to specify the port that we want to open for the traffic in the NodePort or Kubernetes will assign it randomly.
Downsides of a Nodeport:
You can only expose only one single server per port
You can only use ports in the range 30000-32767
NodePort is not recommended to be used in production to expose services
Load Balancer:
Load Balancing is the method by which we can distribute network traffic or client’s request to multiple servers as the name specifies, to balance the load. It is a critical strategy and should be accurately and properly set up otherwise, clients cannot access the servers even when all servers are working fine.
A Load balancer is the standard way of exposing services to the internet, It sits in between the user, or ‘client’, and the server cluster and distributes all the requests from users (like video, text, application data, or image) across all servers.
In simple words, here’s what happens:
Traffic comes to your application or site
A load balancer distributes the traffic across appropriate server nodes
The node receives the request and delivers a response to the user.
Basic Yaml Configuration of a Load Balancer
apiVersion: v1
kind: Service
metadata:
name: api
spec:
type: LoadBalancer # Type is declared as a load balancer
ports:
- protocol: TCP
port: 80
targetPort: 9376
selector:
app: api
type: LoadBalancer - this tells the cloud service to create a load balancer service for your Kubernetes cluster.
targetPort: this is the port that containers are listening on.
- protocol: TCP: This specifies the pattern in which the clusters communicate with one another.
When you've declared the service type in your YAML file as a load balancer and uploaded it to the cloud where you deployed your Kubernetes, the cloud controller manager creates a Load balancer for your applications.
When to use a load balancer when you want;
to expose service directly
to send any type of traffic, like, HTTP, TCP, UDP, Websockets etc.
What are the downsides of a Load balancer
- It can be very expensive because you need to create a service of the type Load balancer for each service you want to expose.