Mastering Kubernetes Services: Types, Configurations, and Iptables Implementation

On May 29 an internal system suffered a large‑scale Service access failure where pods could not reach the ServiceIP:Port, lasting over 12 hours and leaving operators unable to pinpoint the cause.

Post‑mortem analysis revealed that many team members lacked a clear understanding of Kubernetes Service fundamentals, which slowed troubleshooting.

Service role and principle : A Service abstracts a set of Pods and provides load‑balanced access, eliminating the need for clients to know individual Pod IPs (e.g., front‑end to back‑end communication).

Typical Service configuration (with selector):

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

When a selector is defined, the Service controller automatically creates a matching Endpoint object.

Service without selector : No Endpoint is created automatically; a manual Endpoint must be defined, which can point to internal Pods or external services.

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

Service types :

ClusterIP – default internal virtual IP.

LoadBalancer – provisions an external load balancer.

NodePort – exposes the Service on a static port on each node.

ExternalName – maps to a DNS CNAME.

Headless (clusterIP: None) – no virtual IP, DNS returns Pod IPs directly.

Examples:

# ClusterIP example
apiVersion: v1
kind: Service
metadata:
  name: ng-svc
spec:
  selector:
    name: nginx
  clusterIP: 11.254.0.2
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 1234
  type: ClusterIP

# LoadBalancer example
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

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

Implementation methods :

User‑space proxy (kube‑proxy opens a local port and forwards to Pods – now deprecated due to performance).

Iptables mode – kube‑proxy programs iptables rules to DNAT traffic to Pod IPs.

IPVS mode – uses the Linux IP Virtual Server for higher performance.

Iptables implementation : Traffic is redirected from PREROUTING and OUTPUT chains to the KUBE‑SERVICES chain. Example rules:

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A KUBE-SERVICES -d 10.100.160.92/32 -p tcp -m comment --comment "default/ccs-gateway-clusterip:http" -m tcp --dport 30080 -j KUBE-SVC-76GERFBRR2RGHNBJ

For a ClusterIP Service, iptables creates a chain hierarchy KUBE‑SERVICES → KUBE‑SVC‑… → KUBE‑SEP‑…; multiple endpoints are handled with random‑mode statistics (e.g., probabilities 0.25, 0.33, 0.5, 1) to achieve round‑robin distribution.

NodePort adds additional KUBE‑NODEPORTS rules and the node port is listened to by kube‑proxy (e.g., netstat shows tcp 0.0.0.0:30081 LISTEN kube‑proxy).

Services without endpoints generate REJECT rules, while Services with external endpoints forward traffic directly to the external address via DNAT.

Summary : ClusterIP Services rely on iptables DNAT to Pod IPs with probabilistic load‑balancing; NodePort adds extra listening and routing rules; LoadBalancer and ExternalName behave according to their specific configurations.

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/