Octet

What are ClusterIP, NodePort and LoadBalancer Services, and how are they implemented?

Show the answer

Say this first

A Service gives a stable virtual IP and DNS name to a changing set of pods. ClusterIP is the default and is reachable only inside the cluster. NodePort also opens a port, from 30000 to 32767 by default, on every node. LoadBalancer asks the cloud for an external load balancer that sends traffic to the nodes or straight to pods. kube-proxy, or an eBPF data plane like Cilium, programs the translation from the virtual IP to the pod IPs listed in the EndpointSlices.

Go deeper

Types

TypeReachable fromNotes
ClusterIPInside the clusterVirtual IP from the service CIDR
NodePortAny node IP on a high portBuilds on ClusterIP
LoadBalancerOutside, through a cloud LBBuilds on NodePort unless the controller targets pods directly
ExternalNameInside, as a DNS CNAMENo proxying, just DNS
Headless (clusterIP: None)InsideDNS returns pod IPs; used by StatefulSets

Data path

  1. Pods matching the selector and passing readiness probes are listed in EndpointSlices.
  2. kube-proxy watches them and writes rules: iptables DNAT chains, IPVS virtual servers, or nftables in newer releases. Cilium can replace kube-proxy with eBPF.
  3. A packet to 10.96.40.12:80 is translated to a chosen pod, for example 10.244.3.17:8080.
  4. CoreDNS answers web.shop.svc.cluster.local with the ClusterIP.
YAML
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: shop
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Traps

  • Saying a Service is a pod or a process. It is a virtual IP plus rules.
  • Exposing many services with one cloud load balancer each, which gets expensive. That is what ingress is for.
How did you do?