Interactive guide to GatewayClass, Gateway, and HTTPRoute with a focus on portable routing and traffic policy composition.
Gateway API evolves the ingress model by separating infrastructure ownership from routing ownership and by providing richer, more portable network APIs.
Core Model
Understand the Concept First
GatewayClass
Selects the implementation or controller that will realize the Gateway behavior.
Gateway
Represents listeners and the network entry point into the cluster.
HTTPRoute
Declares host, path, match, filter, and backend routing rules that attach to a Gateway.
Interactive Flow Diagrams
Gateway API Request Flow
Resource Relationship Architecture
Gateway API separates infrastructure concerns (GatewayClass, Gateway) from application routing (HTTPRoute), enabling clearer ownership boundaries and more expressive traffic policies.
YAML and Commands
Examples You Can Recognize Quickly
Resource Chain
GatewayClass -> Gateway -> HTTPRoute -> Service
Useful Commands
kubectl get gatewayclass kubectl get gateways kubectl get httproutes
Decision Guide
Ingress vs Gateway API
Topic
Ingress
Gateway API
Model
Single ingress object
Role-oriented resource model
Expressiveness
More limited
Richer routing and policy structure
Ownership split
Less explicit
Clearer platform/app separation
Portability
Often annotation-heavy
Designed for stronger portable semantics
Gateway API shines when teams want a cleaner contract between platform networking and application routing configuration.
Use It Well
Practice and Real-World Thinking
Canary routing
Traffic splitting and richer routing policies fit naturally into Gateway API.
Shared platform ownership
Platform teams can own Gateways while app teams own HTTPRoutes.
Modern HTTP routing labs
Use it when teaching the next generation of ingress-style control.