Mastering Kubernetes Service: Discovery, Load Balancing, and External Access

Why Service Discovery Is Needed

In a Kubernetes cluster, Pods are created and destroyed dynamically, causing their IP addresses to change; therefore traditional static IP‑based communication cannot be used. A unified entry point and load‑balancing mechanism are required to expose applications consistently across test, pre‑release, and production environments.

Kubernetes Service Overview

Kubernetes Service abstracts a set of Pods that provide the same functionality and offers a stable virtual IP (ClusterIP) and DNS name for service discovery and load balancing.

Service Syntax

A typical Service manifest includes fields such as apiVersion, kind, metadata.name, spec.selector, spec.ports, and optionally spec.clusterIP. The example defines a Service named my-service that selects Pods with label app: MyApp and maps port 80 to targetPort 9376 using TCP.

Creating and Viewing a Service

kubectl apply -f service.yaml

kubectl create -f service.yaml

After applying the manifest, the Service can be inspected with: kubectl describe service my-service The output shows the Service name, Namespace, Labels, Selector, assigned ClusterIP, and the list of backend Pod IPs.

Accessing Service Inside the Cluster

Pods can reach a Service in three ways:

Directly using the Service’s virtual ClusterIP and port.

Using the Service name (DNS resolution) within the same Namespace, e.g., my-service:80.

Via environment variables injected into the Pod, such as MY_SERVICE_SERVICE_HOST and MY_SERVICE_SERVICE_PORT.

Headless Service

Setting clusterIP: None creates a headless Service that does not allocate a virtual IP. DNS returns the individual Pod IPs, and the client must choose an endpoint itself.

Exposing Service Outside the Cluster

Two Service types enable external access:

NodePort : Opens a port on each node; traffic is forwarded to the Service’s ClusterIP.

LoadBalancer : In cloud environments, the Cloud Controller Manager provisions an external load balancer (e.g., Alibaba Cloud SLB) that forwards traffic to NodePorts.

Demo Operations on Alibaba Cloud Container Service

The following steps illustrate a complete workflow:

Connect to the Alibaba Cloud Kubernetes cluster ( kubectl get cs).

Create a Deployment that runs two nginx Pods with label run=nginx.

Apply the Service manifest ( kubectl apply -f service.yaml) and verify the Service with kubectl get svc -o wide and kubectl describe svc.

Create a client Pod, exec into it, and test the three internal access methods (ClusterIP, Service name, environment variables) using wget or curl.

Modify the Service to type LoadBalancer, re‑apply, and observe the new EXTERNAL-IP assigned.

Delete one backend Pod; the Deployment automatically creates a replacement, and the Service continues to route traffic without interruption.

Key commands used:

kubectl get pod -o wide -l run=nginx

kubectl delete pod <em>pod-name</em>

Images throughout the demo show the cluster state, Service details, and external IP access.

Kubernetes Service Architecture

The Service mechanism relies on several core components:

API Server : Central store for all cluster objects.

Cloud Controller Manager : Provisions external load balancers for LoadBalancer Services.

CoreDNS : Provides DNS records for Services and resolves headless Service endpoints.

kube-proxy (running on each node): Listens to Service and Pod changes and programs iptables/IPVS rules to route traffic.

Summary

Service discovery and load balancing are essential for cloud‑native workloads where Pods are short‑lived.

Kubernetes Service provides a stable ClusterIP, DNS name, and optional external exposure via NodePort or LoadBalancer.

Headless Services enable direct Pod IP discovery for custom client‑side load balancing.

The underlying architecture (API Server, CoreDNS, kube‑proxy, Cloud Controller Manager) ensures seamless routing and automatic updates as Pods appear or disappear.