Kubernetes Services & Load Balancing - Complete Guide to Service Types

Comprehensive guide to Kubernetes Services covering ClusterIP, NodePort, LoadBalancer, and Ingress service types. Learn service discovery, load balancing strategies (L4 vs L7), production architecture patterns, and best practices for Kubernetes networking

Kubernetes Services Overview

Kubernetes Services provide stable network endpoints to access your applications running in Pods. Since Pods are ephemeral (they can be created, destroyed, and rescheduled), Services provide a consistent way to access your application regardless of the underlying Pod instances.

ClusterIP

Internal cluster communication

Default

NodePort

External access via node IPs

Ports 30000-32767

LoadBalancer

Cloud provider integration

L4 Load Balancing

Ingress

HTTP/HTTPS routing

L7 Load Balancing

Key Concept: Services act as an abstraction layer that decouples frontend clients from backend Pods, providing stable networking, load balancing, and service discovery.

Service Types Comparison

Service Type Access Scope Use Case Load Balancing Configuration
ClusterIP Cluster Internal Microservices communication, internal APIs Round-robin within cluster
type: ClusterIP
NodePort External via Node IP Development, testing, on-premise Manual across nodes
type: NodePort
LoadBalancer External via Cloud LB Production web services, cloud environments L4 - Cloud provider
type: LoadBalancer
Ingress External HTTP/HTTPS Web applications, API gateways, SSL termination L7 - Application aware
apiVersion: networking.k8s.io/v1

LoadBalancer Service Example

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  # Cloud provider specific annotations
  # annotations:
  #   service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

Cloud providers automatically create an external load balancer

Ingress Resource Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Requires an Ingress Controller to be installed in the cluster

Load Balancing Strategies

Layer 4 Load Balancing

Transport Level
  • Operating at the transport level (TCP/UDP)
  • Unable to make decisions based on content
  • Simple algorithms such as round-robin routing
  • Faster processing - less overhead
  • Works with any TCP/UDP protocol

Kubernetes Implementation

  • LoadBalancer Service: Cloud provider L4 load balancers
  • kube-proxy: iptables or IPVS load balancing
  • NodePort: Basic port-based distribution

Layer 7 Load Balancing

Application Level
  • Operates at the application level (HTTP, SMTP, etc)
  • Able to make decisions based on the actual content of each message
  • More intelligent load balancing decisions
  • Content-based routing and optimizations
  • SSL termination, compression, caching

Kubernetes Implementation

  • Ingress Controllers: Nginx, Traefik, HAProxy
  • Service Mesh: Istio, Linkerd (advanced L7 features)
  • API Gateways: Kong, Ambassador

LoadBalancer vs Ingress

LoadBalancer (L4)

  • One LoadBalancer IP per service
  • Cloud provider managed
  • TCP/UDP protocols
  • Simple configuration
  • Higher cost (multiple LBs)
  • Limited to cloud environments

Ingress (L7)

  • One LoadBalancer IP for multiple services
  • Self-managed Ingress Controller
  • HTTP/HTTPS protocols
  • Advanced routing rules
  • Cost effective
  • Works anywhere

Service Architecture

External User
→
LoadBalancer
Service
L4
→
Ingress
Controller
L7
→
ClusterIP
Service
→
Pod
Pod
Pod

Typical Production Architecture

  1. External Load Balancer (L4)

    Cloud provider load balancer distributes traffic to cluster nodes

  2. Ingress Controller (L7)

    Routes HTTP/HTTPS traffic based on hostnames and paths

  3. ClusterIP Services

    Internal service discovery and load balancing

  4. Application Pods

    Actual application containers running your services

Service Evolution

Development

NodePort → Direct node access for testing

Staging

LoadBalancer → External access with cloud LB

Production

Ingress + LoadBalancer → Full L4/L7 capabilities

Complete Example: Production Web Application

# LoadBalancer Service for Ingress Controller
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

---

# Ingress Resource
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80

---

# ClusterIP Service for Application
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080

Best Practices

Service Selection

  • Use ClusterIP for internal microservices communication
  • Use NodePort for development and on-premise clusters
  • Use LoadBalancer for simple external services in cloud
  • Use Ingress for HTTP/HTTPS web applications
  • Combine LoadBalancer + Ingress for production web apps

Performance & Cost

  • Use L4 load balancing for non-HTTP services
  • Use L7 load balancing for HTTP-based applications
  • Minimize LoadBalancer services to reduce cloud costs
  • Use Ingress for multiple services behind one LoadBalancer
  • Implement proper health checks and timeouts

Summary

L4 Load Balancing: Simple, fast, protocol-agnostic

Use Cases: Database connections, custom TCP services

L7 Load Balancing: Intelligent, content-aware, feature-rich

Use Cases: Web applications, APIs, microservices