Mastering Kubernetes Service & Ingress with Traefik and LVS for High‑Availability Load Balancing

Kubernetes Service Overview

Kubernetes provides a Service abstraction that groups Pods offering the same functionality and exposes them via a stable virtual IP. Services enable service discovery, load balancing, and zero‑downtime upgrades, typically selected by labels and used together with Deployments or ReplicationControllers.

There are three main ways to expose a Service:

LoadBalancer Service – creates a cloud‑provider load balancer (e.g., GCE, DigitalOcean, Alibaba Cloud, OpenStack).

NodePort Service – opens a port on every node (default range 30000‑32767) and forwards traffic to the Service.

Ingress – uses an external reverse‑proxy (Nginx, HAProxy, etc.) to route HTTP/HTTPS traffic based on host and path rules.

Ingress Fundamentals

An Ingress is a collection of routing rules that map external HTTP(S) requests to internal Services. The Ingress controller watches the Kubernetes API, detects changes to Services and Pods, and dynamically updates the underlying proxy configuration.

Typical Ingress components:

Reverse‑proxy load balancer (e.g., Nginx, HAProxy).

Ingress Controller that syncs Kubernetes resources with the proxy.

The Ingress resource that defines host‑to‑service mappings.

Traefik as an Ingress Controller

Traefik is a modern HTTP reverse‑proxy and load balancer written in Go. It supports automatic configuration from multiple back‑ends (Docker, Swarm, Kubernetes, Marathon, Consul, etcd) and offers features such as hot‑reloading, SSL termination, Let’s Encrypt integration, and a built‑in dashboard.

Traefik watches the Kubernetes API; whenever an Ingress is added, removed, or updated, it generates the corresponding configuration and applies it to the proxy without requiring a restart.

High‑Availability Architecture with LVS + Traefik

The front‑end consists of two LVS servers providing a virtual IP via keepalived for four‑layer (L4) load balancing. Traffic arriving at the virtual IP is forwarded to three Kubernetes nodes, each running a Traefik container listening on port 80.

Traefik then performs seven‑layer (L7) routing based on domain names or URL paths, forwarding requests to the appropriate Kubernetes Service, which in turn load‑balances to the target Pods.

Deployment Manifest (WordPress Example)

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: wordpress-svc
  labels:
    app: wordpress-svc
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress-svc
        tier: frontend
    spec:
      containers:
      - image: "192.168.18.250:5002/library/wordpress:4.4-apache"
        name: wordpress-svc
        ports:
        - containerPort: 80

Service Manifest

apiVersion: v1
kind: Service
metadata:
  name: wordpress-svc
  labels:
    app: wordpress-svc
spec:
  ports:
  - port: 8912
    targetPort: 80
    selector:
      app: wordpress-svc

Ingress Manifest

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: wordpress-ing
spec:
  rules:
  - host: wordpress.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: wordpress-svc
          servicePort: 8912

Advantages

Domain‑based access replaces IP+port, improving usability and maintainability.

Application publishing is simplified: defining an Ingress and adding a DNS record automatically updates routing, reducing operational steps.

Limitations

Internal service forwarding may become a performance bottleneck under massive traffic.

Current setup does not support automatic scaling of LVS or Traefik instances.