Kubernetes Load Balancing

Services (ClusterIP/NodePort/LoadBalancer), Ingress, and Gateway API.

8 min readNetworking for EngineersBuild

Kubernetes Service Types

Type	Scope	Use Case
ClusterIP	Cluster-internal	Service-to-service communication
NodePort	All cluster nodes	Development, non-cloud environments
LoadBalancer	Cloud provider LB	External traffic into cluster
ExternalName	DNS alias	Reference external services

Service definitions


apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service-external
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 443
    targetPort: 8080

ClusterIP is the default and most common type. It gives the service a stable internal IP and DNS name. LoadBalancer creates a cloud load balancer (ALB, NLB, Cloud Load Balancer) that routes to the service.

kube-proxy and IPVS

kube-proxy runs on every node and maintains network rules that route traffic from Service IPs to Pod IPs. It has three modes: iptables (default), IPVS (better performance), and eBPF (Cilium).

Check kube-proxy mode and rules


# Check kube-proxy mode
kubectl -n kube-system get configmap kube-proxy -o yaml | grep mode

# View iptables rules for services
sudo iptables -t nat -L KUBE-SERVICES | head -20

# Check IPVS rules (if using IPVS mode)
sudo ipvsadm -Ln

# Check service endpoints
kubectl get endpoints my-service

IPVS mode provides better performance than iptables for large numbers of services. iptables uses linear scanning of rules (O(n)), while IPVS uses hash tables (O(1)). For clusters with hundreds of services, IPVS is significantly faster.

Ingress Controllers

Ingress resource


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80

The Ingress controller (Nginx, Traefik, etc.) watches Ingress resources and configures itself accordingly. It handles TLS termination, path-based routing, and host-based routing. Each Ingress controller has its own annotation extensions.

Gateway API

Gateway API resource


apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: api-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80

Gateway API is the successor to Ingress. It provides more expressive routing, better separation of concerns (infrastructure vs application teams), and support for TCP, UDP, and gRPC. It is the future of Kubernetes networking.

Cloud Load Balancers

AWS NLB with LoadBalancer service


apiVersion: v1
kind: Service
metadata:
  name: my-nlb-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 443
    targetPort: 8443

Cloud load balancers are managed by the cloud provider. AWS supports NLB (L4, TCP) and ALB (L7, HTTP). GCP has Network Load Balancer and HTTP(S) Load Balancer. Azure has Azure Load Balancer and Application Gateway.

Cloud LB costs

Cloud load balancers are charged by hour + data processed. A single NLB costs ~$22/month plus $0.006/GB. For internal service-to-service traffic, use ClusterIP with kube-proxy instead of creating unnecessary load balancers.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 3 · Build

Load Balancing & Traffic Management