Challengekubernetes
From Ingress to Gateway API — Challenge
Express the same routing twice — as an Ingress and as a Gateway — and see what the newer model actually fixes.
- Time
- 25 min
- Level
- Intermediate
- Objectives
- 4 objectives
- Cost
- Free
Before you start
You will need
- kind or minikube
- kubectl 1.28+
- A Gateway API controller (Envoy Gateway or NGINX Gateway Fabric)
You will be able to
- Write a Gateway and an HTTPRoute for an existing Service
- Explain the role split Gateway API introduces
- Do a weighted traffic split without controller-specific annotations
You are done when
0 of 4
The goal#
Achieve the same outcome as From Ingress to Gateway API, from an empty starting point, without the steps.
Ingress is stable, everywhere, and feature-frozen. Everything it cannot express — header matching, traffic splitting, timeouts — moved into vendor annotations that mean different things on different controllers.
Gateway API is the replacement. Learn Ingress first, because it is what existing clusters run; learn this, because new ones will not.
What must be true when you are done#
- The same application is reachable through an Ingress and through an HTTPRoute.
- A weighted split sends traffic to two Services, with no annotations.
- You can name two things Gateway API expresses that Ingress cannot.
- You can explain who owns a Gateway versus who owns an HTTPRoute.
Rules#
- Do not open the guided lab until you are finished, or until the same problem has held you up for 20 minutes.
- Documentation is allowed and encouraged.
- Verify every criterion with a command whose output you can read.
If you get stuck#
- What did you expect, exactly?
- What happened instead — the error text, not a paraphrase?
- Which layer is that error from?
- What is the smallest command that proves the layer below is fine?
The concept behind it
Next up
Lab 38 of 58 on the project path