/k8s_basics/ingress/index.html Generally, Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Gateway, HTTPRoute and GRPCRoute Resources. The older generation of Kubernetes Ingress uses the Ingress Resource. A Kubernetes Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting, among other things. An Ingress or Gateway Controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. Hugo en-US /k8s_basics/ingress/gatewayapi/index.html Mon, 01 Jan 0001 00:00:00 +0000 /k8s_basics/ingress/gatewayapi/index.html Setup instructions Stated here just for reference, so don’t execute any of these by yourselves. Besides, so far you haven’t been granted the permissions to do so anyways … :-) Source: [Kubernetes Gateway API][k8s-gateway-api] and [Kubernetes Traefik][k8s-traefik] Traefik supports the Kubernetes Gateway API, meaning it can install the Gateway API’s Custom Resource Definitions. As we are running Traefik for some of the exercises, we have already installed the Gateway API CRDs. /k8s_basics/ingress/ingress-api/index.html Mon, 01 Jan 0001 00:00:00 +0000 /k8s_basics/ingress/ingress-api/index.html Ingress is Kubernetes’ original HTTP and HTTPS entry point. It is still supported and still useful, but Kubernetes now recommends Gateway API for new work. The Ingress API is stable and not planned for removal, but it is frozen and no longer receives new features. The reason is simple: Ingress solved the common case well, but implementations quickly diverged. Anything beyond basic host and path routing often depended on controller-specific annotations or custom resources, so the same manifest could behave differently on NGINX, Traefik, cloud load balancers, or other controllers. Gateway API keeps the same purpose, but splits the model into role-oriented resources such as GatewayClass, Gateway, and HTTPRoute. That gives controllers a shared vocabulary and makes common routing configuration more portable, while still leaving room for implementation-specific extensions.