Mastering Kubernetes Services: Types, Usage, and Iptables Implementation

The article introduces the basic concepts, usage patterns, and implementation principles of Kubernetes Services, using a real production incident where pods could not reach a Service IP for over 12 hours as a starting point.

Service Usage

After defining a selector, the Service controller automatically creates matching Endpoints, enabling load‑balanced access to a group of Pods without requiring callers to know individual Pod IPs. A typical Service manifest is shown below:

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

When a Service is defined without a selector, the user must create an Endpoints object manually, which can point to internal Pods or external services.

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

Service Types

The four main Service types are demonstrated with kubectl commands and YAML snippets.

ClusterIP

kubectl expose pod nginx --type=ClusterIP --port=80 --name=ng-svc

LoadBalancer

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

NodePort

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

ExternalName

Maps the Service to a DNS CNAME record.

Headless (ClusterIP: None)

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

For headless Services with a selector, the Endpoint controller creates Endpoints and updates DNS A records so that the Service name resolves directly to the backend Pods.

Service Implementation

1. User‑Space Proxy

kube‑proxy opens a random local port on each node and forwards traffic to Pods via iptables rules. This method incurs two context switches (kernel→user→kernel) and is rarely used due to performance overhead.

2. Iptables Mode

kube‑proxy programs iptables chains (KUBE‑SERVICES, KUBE‑SVC‑…, KUBE‑SEP‑…) to DNAT traffic from Service IP:Port to the selected Pod IP:Port.

3. IPVS Mode

IPVS provides a more scalable load‑balancing implementation but the article focuses on iptables rules.

Iptables Rules for Different Service Types

Examples of iptables rules generated by kube‑proxy for ClusterIP, NodePort, and services without Endpoints are shown below.

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES</code><code>-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES</code><code>-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</code><code>-A KUBE-SVC-76GERFBRR2RGHNBJ -m comment --comment "default/ccs-gateway-clusterip:http" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-GBVECAZBIC3ZKMXB</code><code>-A KUBE-NODEPORTS -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp --dport 30081 -j KUBE-MARK-MASQ</code><code>-A KUBE-NODEPORTS -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp --dport 30081 -j KUBE-SVC-QYHRFFHL5VINYT2K

For services without Endpoints, kube‑proxy inserts a REJECT rule to return an ICMP port‑unreachable message.

-A KUBE-SERVICES -d 10.101.117.0/32 -p tcp -m comment --comment "default/fake-endpoint:80 has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

Summary

ClusterIP services rely on KUBE‑SERVICES and KUBE‑SEP chains to DNAT traffic to Pods, using round‑robin or other iptables‑based load‑balancing strategies.

NodePort adds additional KUBE‑NODEPORT rules on top of the ClusterIP handling, exposing the Service on a node‑wide port.