HAProxy in Kubernetes: the high-performance Ingress Controller

1. Introduction and fundamental concepts #

In the cloud native ecosystem, routing external traffic requires millisecond-level responsiveness. For beginner administrators, it is crucial not to confuse the different Kubernetes network components.

Distinguishing roles: Ingress resource vs Ingress Controller #

Here is a summary of each component's responsibilities within the cluster:

The modern IngressClass #

Today, Kubernetes standardizes traffic routing through the spec.ingressClassName field rather than the old, obsolete annotations (kubernetes.io/ingress.class). The IngressClass lets several distinct controllers (HAProxy, NGINX, Traefik) coexist in the same cluster, offering full flexibility per application.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: haproxy
spec:
  controller: haproxy.org/ingress-controller

2. Why choose HAProxy? A decision-making comparison #

The choice of network entry point is structural for the performance and robustness of a production infrastructure.

Comparison table: HAProxy vs NGINX vs Traefik #

Specific advantages of the HAProxy architecture #

Architects favor HAProxy for several major technical reasons:

• Direct-to-pod mode: HAProxy bypasses the kube-proxy component. It queries the Endpoints API to route packets directly to the Pods' private IP addresses, removing a network hop.
• Stick tables & rate limiting: native in-memory features that block denial-of-service (DDoS) attacks or track application sessions with surgical precision.
• Modern protocol support: seamless integration of TLS termination, mutual TLS (mTLS) and HTTP/2 / HTTP/3 (QUIC).

3. High availability architecture in production #

To ensure resilience to failures, the Ingress Controller must never be a SPOF (single point of failure).

Redundancy and resilience #

In production, HAProxy is deployed with at least 3 replicas spread across different cluster nodes using anti-affinity rules. The Kubernetes LoadBalancer service (provided by your cloud provider or by an on-premises solution such as MetalLB) distributes incoming traffic evenly between these instances.

# Extrait de configuration values.yaml pour Helm
controller:
  replicaCount: 3
  antiAffinity:
    type: hard

4. Practical demonstration and advanced routing #

Deploying a multi-host, multi-path infrastructure rule.

Concrete case: isolating the API and the web interface #

The following manifest shows how HAProxy simultaneously handles separation by subdomain (api.rousseltm.fr vs app.rousseltm.fr) and contextual path routing (/admin), all protected by a global SSL redirect.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: infrastructure-globale-ingress
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/balance: "leastconn"
spec:
  ingressClassName: haproxy
  rules:
  - host: app.rousseltm.fr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
      - path: /admin
        pathType: Strict
        backend:
          service:
            name: admin-service
            port:
              number: 80
  - host: api.rousseltm.fr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

5. The future of K8s networking: Gateway API integration #

As the Ingress specification shows its limits for complex topologies, the community is moving to the Gateway API ecosystem.

Support for HTTPRoute resources #

HAProxy Ingress Controller natively follows Kubernetes' evolution. It fully supports the Gateway API specifications. Instead of concentrating all the logic in a single Ingress, responsibilities are split: administrators manage the Gateway object, while developers autonomously deploy HTTPRoute or TCPRoute resources to expose their applications.

6. Advanced observability and the OpenTelemetry revolution #

Real-time monitoring and distributed tracing of incoming network flows using the latest open standards.

The native OpenTelemetry turning point (v3.4+) #

A major milestone was reached with the release of version 3.4 of the HAProxy Ingress Controller, which now includes full native support for OpenTelemetry (OTel). This native compatibility lets you export layer 7 distributed traces directly, without burdening the infrastructure with complex sidecar agents.

When a request goes through HAProxy to enter the cluster, the controller can inject or propagate the trace context (W3C Trace Context). This links the initial network latency observed at the cluster edge with the internal traces generated further downstream by your microservices (for example in Jaeger, Tempo or Dynatrace), providing the end-to-end visibility that is essential for performance diagnosis.

Prometheus metrics collection and Grafana dashboards #

Alongside traces, HAProxy keeps exposing its metrics endpoint in the standard Prometheus format. The unified monitoring architecture breaks down as follows:

HAProxy Ingress ──(metrics + OTel traces)──> Prometheus / OpenTelemetry Collector ──> Grafana / Tempo

This hybrid approach lets you instantly correlate a spike in HTTP errors (4xx/5xx) or a drop in requests per second (RPS) seen in Grafana with the specific OpenTelemetry traces to identify the bottleneck.

Conclusion #

Summary for the CKA & CKAD certifications #

To pass your CKA/CKAD certification exams, remember these fundamental principles:

• The Ingress resource is only a set of theoretical rules.
• The IngressClass selects the technology implementation.
• The Ingress Controller is the physical engine that translates and applies the configuration.
• HAProxy Ingress provides L4/L7 power and modern observability (OpenTelemetry, Prometheus) essential for industrial environments.