In Kubernetes, a Service is a method for exposing a network application as a single or multiple pods in our cluster. We can run code in Pods, whether this is a cloud-native code, or a traditional code we have containerized. We use a Service to make that group of Pods available on the network so that clients app can interact with it.
In Kubernetes environment we usually use a Deployment to run our application, Pods dynamically can create and destroy with that deployment. We don’t know how many of these pods are healthy and working during a timeframe; We might not even know the names of the healthy Pods. In simple terms, Kubernetes Pods are instantiated and terminated as needed to match the intended configuration of our cluster.
Each Pod gets its own IP address. Pods are ephemeral resources, which means we should not expect that a Pod is reliable and durable.
For a given Deployment in our cluster, the group of Pods running in one point in time could be different from the group of Pods running that application a moment later.
This leads to a problematic situation: if some group of Pods (call them " upstream") provides functionality to other Pods (call them "downstream") inside our cluster, how do the downstream realize and keep track of which IP address to link to, so that the downstream can use the upstream part of the job?
In Kubernetes, the Service API acts like a virtual bridge, connecting groups of Pods (containers) across the network. Think of it as a stable address that represents a collection of Pods, even as those Pods change or move. It's like having a single phone number for a whole team, even if the individual members take turns answering calls.
Here's how it works:
Example: Imagine a website with a frontend and a backend image-processing service. The frontend can simply communicate with the backend Service, without worrying about which specific Pod is handling the request. This makes it easy to scale the backend service up or down as needed, without affecting the frontend.
When we want to make certain parts of our application, like frontends, available to the outside world, Kubernetes offers flexible ways to control how they're exposed. This is where different Service types come in, each providing a unique way to connect our application to the external world.
Think of Service types as different doors we can choose for our application:
Kubernetes gives us control over which door we use for each part of our application, ensuring that the right services are accessible to the right users, while keeping sensitive components protected.
There are 4 types of Kubernetes services:
ClusterIP creates a private service that’s only accessible within our Kubernetes cluster.
NodePort creates a way to access our Kubernetes services outside the cluster. When we define a service as type NodePort, Kubernetes assigns a static port number.
This port is than opened on every node in our cluster, acting as a gateway to the service and evenly distributed the load on the pods (you need to configure external DNS or load balancing to distribute traffic across the nodes).
This exposes the Service externally using an external load balancer. Kubernetes does not provide a load balancer; you must integrate your Kubernetes cluster with an external or cloud load balancer.
ExternalName is a unique type of Service that acts as a virtual pointer to a service running outside your Kubernetes cluster. It's like establishing a shortcut within your cluster to an external resource, without managing that resource directly.