Exposing Apps with Services

In Kubernetes, Pods are the smallest deployable units. They are designed to be temporary and can be created, destroyed, or moved by Kubernetes at any time.

This flexibility is great for resilience, but it creates a challenge: How do other applications reliably find and communicate with these ever-changing Pods?

Every Pod gets its own IP address. When a Pod restarts or scales, it often gets a new IP address. Directly connecting to a Pod's IP is like trying to hit a moving target!

Imagine a web application with multiple Pods. If one Pod restarts, its IP changes, breaking connections from other services or users.

This is where Kubernetes Services come in! A Service provides a stable, fixed network endpoint for a set of Pods.

Think of it as a permanent address for your application, even if the Pods behind it are constantly changing their individual addresses.

A Service acts as an abstraction layer over a group of Pods. It gives them a single, consistent IP address and DNS name.

• Other applications use this stable Service IP/name.
• The Service then routes traffic to the healthy Pods it manages.
• This decouples clients from individual Pod IPs.

How does a Service know which Pods to route traffic to? It uses labels and selectors!

When you define a Service, you specify a selector. Any Pod matching these labels will automatically become part of that Service's group.

This dynamic association means new Pods are automatically added, and unhealthy Pods are removed.

Services manage how network traffic flows. They define ports to map incoming requests to the correct ports on your Pods.

Key port concepts:

• port: The port the Service itself listens on.
• targetPort: The port on the Pod that the Service forwards traffic to.

Like most Kubernetes resources, Services are defined using YAML files. Let's look at the basic structure:

• apiVersion: v1
• kind: Service
• metadata: Name, labels
• spec: Contains the core definition, including selector and ports.

The most common Service type for internal communication is ClusterIP. It exposes the Service on an internal IP address within the cluster.

Here's an example for a simple web application:

Once you have your Service YAML, you can deploy it to your cluster using kubectl, just like with Pods or Deployments.

This command tells Kubernetes to create the Service based on your definition:

After deployment, your Service gets a stable IP and DNS name within the cluster. Other Pods can now reach your application using this name.

For example, another Pod could connect to my-web-service:80, and the Service would handle routing to the correct my-webapp Pods.

You've learned how Kubernetes Services provide stable network access to dynamic Pods.

Which of the following best describes the primary role of a Kubernetes Service?

Great job! In this lesson, we explored Kubernetes Services.

• Pods are ephemeral and have dynamic IPs.
• Services provide stable network endpoints for Pods.
• They use selectors to find target Pods.
• Services map external port to internal targetPort.
• ClusterIP is a common type for internal communication.

Next, we'll dive deeper into different Service types and their uses!