Cloud Native 12 min read

Demystifying Kubernetes Service: Types, Usage, and Implementation

This article explains the fundamentals of Kubernetes Service, walks through a real‑world failure case, details how to configure different Service types (ClusterIP, NodePort, LoadBalancer, ExternalName, Headless), and explores the underlying implementation mechanisms such as user‑space proxy, iptables, and IPVS.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
Demystifying Kubernetes Service: Types, Usage, and Implementation

Introduction This article discusses the basic concepts, usage patterns, and implementation principles of Kubernetes (K8s) Service.

Failure Story On May 29 an internal system experienced a large‑scale Service outage where pods could not reach ServiceIP:Port, lasting over 12 hours. The root cause was identified as insufficient understanding of Service internals.

What is a Service?

A Service abstracts a set of Pods and provides load‑balanced network access. It decouples client pods from the dynamic IPs of backend pods, enabling stable communication (e.g., front‑end to back‑end) even as pod IPs change.

Service Usage

1. Typical Service Configuration

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

2. Service without selector

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
- addresses:
  - ip: 192.0.2.42
  ports:
  - port: 9376

3. LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  type: LoadBalancer

4. NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30007

5. ExternalName

Creates a CNAME DNS record that points to an external service.

6. Headless Service

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    run: curl
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80

For a headless Service with a selector, the Endpoint controller creates Endpoints records and DNS returns A records that resolve directly to pod IPs.

When no selector is defined, DNS still resolves the Service name but without automatic Endpoint creation.

Service Implementation Methods

1. User‑Space Proxy kube‑proxy opens a random local port on each node; iptables redirects traffic to this proxy, which then forwards to the pod. This incurs two context switches (kernel→user and back) and is rarely used today.

2. iptables Mode

iptables mode diagram
iptables mode diagram

Traffic is redirected from PREROUTING and OUTPUT chains to the KUBE‑SERVICES chain, which then selects the appropriate KUBE‑SVC‑… and KUBE‑SEP‑… chains for DNAT.

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE‑SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE‑SERVICES

Examples of iptables rules for different Service types are shown (ClusterIP, NodePort, LoadBalancer, services without Endpoints, services with external Endpoints).

3. IPVS Mode

IPVS mode diagram
IPVS mode diagram

IPVS provides higher‑performance load balancing by handling traffic in the kernel.

Behavior of Different Service Types under iptables

ClusterIP – iptables creates KUBE‑SVC‑… chains that DNAT to pod IPs; load‑balancing is achieved via probabilistic statistic matches.

NodePort – additional KUBE‑NODEPORTS rules listen on the node port and forward to the corresponding ClusterIP rules.

LoadBalancer – external IP is allocated; iptables forwards to the ClusterIP chain similarly.

Service without Endpoints – iptables rule rejects traffic with icmp‑port‑unreachable.

Service with external Endpoints – iptables DNAT directly to the external IP address.

Summary

ClusterIP services rely on kube‑proxy iptables rules that DNAT traffic to pod IPs; when multiple endpoints exist, iptables uses probabilistic matching (default round‑robin) to distribute traffic.

NodePort adds extra iptables listeners to ensure the node port is reserved and forwards traffic to the underlying ClusterIP rules.

References

iptables – https://en.wikipedia.org/wiki/Iptables

IPVS – https://en.wikipedia.org/wiki/IP_Virtual_Server

Kubernetes Service – https://kubernetes.io/docs/concepts/services-networking/service/

Link: https://www.talkwithtrend.com/Article/256823

(© Original author, all rights reserved)

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeKubernetesNetworkingServiceiptablesheadlessloadbalancer
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.