Lab 15 - Ingress with Traefik (legacy)

Goal: publish two applications by host name with the old API - enough to read the Ingress objects you will meet in existing clusters. Chapter: Ingress (legacy)

Requires Traefik from Lab 14.

# 1 - two applications, ClusterIP only
cd ~
kubectl create ns web
kubectl create deploy shop --image nginx:1.27 -n web
kubectl create deploy wiki --image httpd:2.4 -n web
kubectl expose deploy shop --port 80 -n web
kubectl expose deploy wiki --port 80 -n web

# 2 - one Ingress, two hosts
kubectl create ingress web -n web --class traefik \
  --rule='shop.k8s.lab/*=shop:80' \
  --rule='wiki.k8s.lab/*=wiki:80' \
  --dry-run=client -o yaml > ingress.yaml
cat ingress.yaml
kubectl apply -f ingress.yaml
kubectl get ingress -n web

# 3 - test through Traefik's NodePort
curl -s -H 'Host: shop.k8s.lab' http://worker01:30080 | grep -o '<title>.*</title>'
curl -s -H 'Host: wiki.k8s.lab' http://worker01:30080
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: other.k8s.lab' http://worker01:30080

One port, two applications, and a 404 from Traefik for an unknown host.

# 4 - who serves it?
kubectl get ingressclass
kubectl describe ingress web -n web | grep -A6 Rules

ingressClassName: traefik ties the object to the controller. Without a running controller the Ingress would be accepted by the API - and do nothing.

Note

Anything beyond host and path - rewrites, redirects, canaries - needs Traefik annotations or Traefik’s own Middleware CRD. The same Ingress would not work on another controller. That is why the next lab uses Gateway API.

Clean up

# 5 - keep the apps, Lab 16 reuses them
kubectl delete -f ingress.yaml