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 the client's 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 at 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:

1. Define a Service: Create a Service object to specify which Pods you want to group together and how they should be accessed (e.g., using a specific port).
2. Kubernetes handles the rest: The Kubernetes system automatically keeps track of the Pods in the group and routes traffic to them accordingly.

👉Certified Kubernetes Administrator (CKA) Training

• Decoupling: Downstream components don't need to know or care about the individual upstream Pods they're interacting with. This makes your system more flexible and resilient to changes.
• Load balancing: Traffic can be distributed across multiple Pods, improving performance and scalability.
• Network abstraction: Services provide a consistent way to access Pods, even if their IP addresses or locations change.

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:

• Some doors lead to internal rooms within our cluster, where only other services can interact.
• Other doors open directly to the outside, allowing anyone to access our application from the internet.

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:

• Cluster IP
• Node Port
• Load Balancer
• External Name

👉Docker with Kubernetes Certification Training

ClusterIP creates a private service that’s only accessible within our Kubernetes cluster.

Key Points:

• ClusterIP service is ideal for components that don’t need to be directly exposed to the outside world.
• ClusterIP is the default service type, Kubernetes automatically creates a ClusterIP service.
• It can be exposed publicly also with the use of Ingress or Gateway resources to create a controlled entry point.

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.