What Is a Service in Kubernetes? A Complete A-Z Guide to Service Types and Configuration

In the Kubernetes world, Pods have one defining characteristic: they are ephemeral. They are constantly created, terminated, and replaced. Each time this happens, a Pod’s IP address changes. This creates a challenging problem: How can A communicate with B if B’s IP address keeps changing? The answer is Kubernetes Service. Let’s explore it with Viettel IDC.

What Is a Service in Kubernetes?

In Kubernetes, a Service is an important entity that represents a group of Pods running an application or a specific functional component. A Service maintains network access policies and is responsible for enforcing these policies for every incoming request.

Simply put, if Pods are the “workers” that directly handle tasks, then a Kubernetes Service is the “manager” that coordinates traffic, ensuring that requests from clients always reach the right destination.

The introduction of Kubernetes Services stems from one of the most fundamental characteristics of Pods: their short and unstable lifecycle. In Kubernetes, Pods can be replaced at any time due to scaling, hardware failures, or software updates. Although Kubernetes ensures application availability through replicas, it does not guarantee the permanent existence of any particular individual Pod.

This leads to a major networking challenge:

- Each time a Pod is recreated, it receives an entirely new IP address.

- If an application attempts to connect directly to another Pod’s IP address, the connection will be lost as soon as that Pod is replaced.

- Pods that need to communicate with each other cannot rely on the individual IP addresses of the underlying Pods.

To solve this problem, Kubernetes Service acts as an intermediary:

- ClusterIP: When a Service is created, it is assigned a virtual IP address called a ClusterIP. This address remains stable throughout the Service’s lifecycle until the Service is explicitly deleted.

- Traffic Forwarding Mechanism: Instead of connecting directly to a Pod, application components connect to the Service’s address. The Kubernetes Service then acts as a traffic router, forwarding the request to a suitable and healthy Pod within the group it manages.

Thanks to this mechanism, a Kubernetes Service acts as a reliable endpoint, decoupling the dependency between communicating components.

In addition to using Kubernetes Services, applications specifically designed for the Kubernetes platform (Kubernetes-native applications) have an alternative approach: making requests directly through the Kubernetes API Server. The API Server can automatically expose and maintain endpoints for running Pods. However, this approach is generally more complex and is intended for advanced use cases, while Services remain the standard and most effective solution for most application architectures today.

Structure of a Kubernetes Service

Technically, a Kubernetes Service operates as an abstract entity that links a group of Pods through an identifying name and a stable IP address. This mechanism is the key to enabling Pods to discover each other and route requests accurately in a distributed environment.

To correctly connect applications, Kubernetes Services use the combination of Labels and Selectors to filter and identify the appropriate targets. A standard Kubernetes Service configuration typically includes the following key components:

- Label Selector: This is the most important component, acting as a filter to identify the list of target Pods to which the Service will route traffic.

- ClusterIP: An internal virtual IP address assigned to the Service, serving as a stable connection endpoint.

- Port Number: The port on which the Service listens for incoming requests.

- TargetPort: An optional port mapping that specifies the particular port on the Container to which traffic will be forwarded. (For example, the Service listens on port 80 but forwards traffic to port 8080 on the Container.)

How to Create a Service in Kubernetes

The standard and most professional way to configure a Kubernetes Service is by using a YAML Manifest. This file acts as a blueprint that defines how the Service operates and connects to Pods.

Basic YAML File Structure

apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

selector:

app: nginx

ports:

- protocol: TCP

port: 80

targetPort: 8080

To master Kubernetes Services, you need to clearly understand the three core components in the Manifest:

- metadata:name: This is the logical name of the Service. More importantly, it becomes the Service’s internal DNS name. Other applications within the Cluster can access this Service simply by using the name my-service.

- spec:selector: This is the membership “filter.” The Service searches for and routes traffic to all Pods whose labels match this declaration (in the example above, app: nginx).

- spec:ports: Defines the communication ports.

• port: The port that the Service opens to listen for incoming requests.

• targetPort: The actual port on which the application inside the Pod is running. The Service receives requests on the port and forwards them to the targetPort.

Deployment command: To deploy this Service object to the Cluster, use the familiar kubectl command:

kubectl apply -f /path/to/service-manifest.yaml

Types of Services in Kubernetes

1. ClusterIP

ClusterIP is the default type of Kubernetes Service. It assigns an internal IP address (Cluster-Internal IP) to the Service. Only objects within the Cluster can access this Service.

Example Manifest:

apiVersion: v1

kind: Service

metadata:

name: my-clusterip-service

spec:

type: ClusterIP

clusterIP: 10.10.5.10 (Optional) A specific IP can be set within the Cluster’s IP range

ports:

- name: http

protocol: TCP

port: 80

targetPort: 8080

2. NodePort

NodePort is an extension of ClusterIP. It allows a Service to be accessed from outside the Cluster by opening a specific port on all Nodes (servers). When you access IP_of_any_Node:NodePort, traffic is forwarded to the ClusterIP and then to the Pod.

Note:

- Default port range: 30000 - 32767.

- The kube-proxy component on each Node is responsible for listening and forwarding packets (NAT).

- Commonly used for manually configuring Load Balancers or in Dev/Test environments.

Example Manifest:

apiVersion: v1

kind: Service

metadata:

name: my-nodeport-service

spec:

type: NodePort

selector:

app: nginx

ports:

- name: http

protocol: TCP

port: 80

targetPort: 8080

nodePort: 30000 (Optional) Fixes the externally exposed port

3. LoadBalancer

LoadBalancer is the most common type of Kubernetes Service when operating on Cloud platforms (such as Viettel IDC, AWS, and GCP). It builds on top of NodePort while adding integration with the Cloud provider’s Load Balancer.

The LoadBalancer mechanism automatically requests the Cloud provider to allocate a Public IP. Traffic from the Internet follows the path:

External Load Balancer → NodePort → ClusterIP → Pod

This helps distribute traffic efficiently while providing a stable public IP address for end users.

Example Manifest:

apiVersion: v1

kind: Service

metadata:

name: my-loadbalancer-service

spec:

type: LoadBalancer

clusterIP: 10.0.160.135

loadBalancerIP: 168.196.90.10 (Requires the Cloud Provider to allocate this specific IP, if supported)

selector:

app: nginx

ports:

- name: http

protocol: TCP

port: 80

targetPort: 8080

4. ExternalName

The ExternalName Service type is quite special because it does not use Selectors and does not define any ports or IP addresses. Instead, it maps the Service to an external DNS domain name through a CNAME record.

Applications:

- Connecting a Pod to a Database located outside the Kubernetes Cluster (for example, my.database.domain.com).

- Allowing a Pod in one Namespace to access a Service in another Namespace as if it were a local service.

Example Manifest:

apiVersion: v1

kind: Service

metadata:

name: my-externalname-service

spec:

type: ExternalName

externalName: my.database.domain.com (The target domain name to point to)

Conclusion

Kubernetes Service is not merely a naming mechanism; it is the backbone that keeps communication within the Cluster operational. It completely solves the ephemeral nature of Pods, acting as an intelligent traffic router that ensures every connection request, whether originating internally or from the Internet, reaches the correct destination regardless of the continuous changes occurring to the underlying Pods.

However, there is a significant gap between theory and real-world operations. To simplify this process and focus resources on core application development, businesses can choose Viettel Open Kubernetes Service (vOKS). Built on Viettel IDC’s powerful Cloud infrastructure, vOKS provides built-in, internationally standardized Load Balancer integration, enabling your system to automatically distribute traffic and ensure high availability with just a few clicks.

Discover powerful and reliable Kubernetes infrastructure at: https://viettelidc.com.vn/en/viettel-kubernetes-service