Install Kong from the Rancher Catalog and Route a Workload
Rancher's Apps catalog is where a platform team installs and manages shared tooling on a cluster. In this challenge you will use it for a real task: add a third-party Helm repository, install the Kong ingress controller from it, and route a workload through the Kong gateway.
The playground is a multi-node K3s cluster with Rancher already installed. K3s ships Traefik as the default ingress controller; Kong will join it as a second controller that workloads opt into per-Ingress. Work from the dev-machine terminal (its kubectl and helm are already pointed at the cluster), or drive the same steps through the Rancher UI's Apps screens.
Step 1: Install Kong from the Catalog
Add Kong's Helm repository and install its ingress controller into a kong namespace. The Kong gateway's proxy must be reachable on NodePort 30081 (this cluster has no external load balancer, so a fixed NodePort is how you reach the gateway).
Hint 1 - adding the repo and installing
Kong is not a built-in Rancher chart, so register its Helm repository first (charts.konghq.com), then install its ingress chart into a new kong namespace. The recommended chart runs Kong in DB-less mode, so there is no database to set up.
Hint 2 - pinning the proxy port
The gateway's proxy Service wants a LoadBalancer address it will never get here, so it stays <pending>. Configure the proxy as a NodePort instead and pin its HTTP port to 30081 - the chart exposes values for the proxy service type and its HTTP node port. This is what makes the gateway reachable at 172.16.0.2:30081.
Step 2: Route a Workload Through Kong
Run any HTTP workload in a demo namespace, put a Service in front of it, and create an Ingress that uses the kong ingress class so Kong handles its traffic. When it works, a request to the Kong gateway returns HTTP 200.
You can watch it in the browser through the Kong tab once the route is live.
Hint 3 - the one field that picks Kong
An Ingress goes through Kong instead of the default Traefik when its spec.ingressClassName is set to kong. Make sure the Ingress backend points at your Service and that the Service has endpoints (its selector matches running pods).