Infrastructure & Engineering

Migration Log: Ingress Nginx to Traefik Gateway

Otama
3 min read
Progress 10 / 18
Table of Contents

This article records the migration process from Ingress Nginx to Traefik v3 in my Homelab Kubernetes cluster. It was time for some “spring cleaning” of the network stack.

1. Motivation: A Change of Pace and Middleware

One of the triggers for this migration was the news about the End of Life (EOL) for Ingress Nginx. While migrating from Authentik to Pocket ID, I remembered the EOL announcement and decided to address it while I was at it. Since this is a homelab, I don’t need to be strictly paranoid about security, but I thought it was a good opportunity to start fresh and migrate to a new environment. It felt a bit like “spring cleaning”.

Another reason is my interest in Traefik’s “Middleware” feature. In Ingress Nginx, configuring additional features like authentication often meant dealing with slightly complex setups. With Traefik, I felt that using Middleware resources would make extending functionality much easier.

Actually, I was enthusiastic about throwing in the authentication infrastructure “tinyauth” as well, but setting up IngressRoute and migrating to Gateway API consumed more energy than expected, so I’ll save that fun for next time.

2. Installation & Configuration: Quick Deploy with Helm

I used the official Helm Chart for deploying Traefik. Here are the key points:

  • Gateway API Enabled: Enabled gateway and kubernetesGateway to allow the use of HTTPRoute resources.
  • LoadBalancer: Fixed the Traefik service to my usual static IP (192.168.100.202).
  • Auto-Redirection: Forced a setting to redirect HTTP traffic to HTTPS (web -> websecure).

A snippet of the configuration file (apps/traefik/values.yaml) looks like this:

traefik:
  gateway:
    enabled: true
  listeners:
    websecure:
      mode: Terminate
  ports:
    web:
      http:
        redirections:
          entryPoint:
            to: websecure

3. Resource Migration: From Ingress to HTTPRoute

I said goodbye to my old Ingress resources and made my Kubernetes Gateway API debut. For example, the ArgoCD configuration was reborn from ingress.yaml to httproute.yaml like this:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: argocd-route
  namespace: traefik
spec:
  parentRefs:
    - name: traefik-gateway
  hostnames:
    - "argocd.homelab.otama-playground.com"
  rules:
    - backendRefs:
        - name: argocd-server
          port: 80

4. Why Gateway API? How It Happened

A Little Stumble with IngressRoute

Initially, I intended to use Traefik’s native IngressRoute. However, when I tried it, I ran into a minor issue where the LoadBalancer IP wasn’t being reflected in the status correctly, preventing smooth integration with ExternalDNS. I could have made it work by manually adding an Annotation, but doing that every time seemed a bit tedious.

Switch to Gateway API

So, I decided to switch gears and hop on the Kubernetes Gateway API, which is the new standard for Kubernetes. It’s touted as the successor to Ingress, so it seems to have a good future ahead.

Using it in practice, the writing style isn’t that different from Ingress, so the migration was smooth. For now, I’m only doing basic routing, but I’d like to try out more advanced features eventually.

Thanks to stumbling with IngressRoute, I ended up touching the latest standard, so all’s well that ends well.

5. Summary

And so, the move from Ingress Nginx to Traefik is complete, and the Gateway API environment is ready. From now on, I’ll be linking new apps to the traefik-gateway.

Replacing the old system has left me feeling somewhat refreshed. Next, I plan to leisurely work on the authentication setup that I put off this time.

Related Posts