Este contenido no está disponible en el idioma seleccionado.
Chapter 4. Introducing the Kubernetes Gateway API for custom image migration
Previously, the standard setup of JupyterLab and code-server leveraged OpenShift Routes and unique hostnames or subdomains for each workbench. Traffic was directed to the pod, and the application inside the pod usually served content from the root path (/). Red Hat OpenShift AI now leverages the Kubernetes Gateway API for request routing. This architecture replaces individual OpenShift Routes and Ingress resources with path-based routing through a single entry point.
4.1. Understanding path-based routing Copiar enlaceEnlace copiado en el portapapeles!
Path-based routing is a traffic management strategy where an API Gateway or load balancer sends requests to specific backend services based on the URL path provided by the client.
The Kubernetes Gateway API introduces path-based routing to your workbench image updating workflow.
Key architectural change
OpenShift Route (Previous)
External: /notebook/user/workbench/app/
Route strips prefix Container receives: /app/ Gateway API (New)
External: /notebook/user/workbench/app/
Gateway preserves full path (path-based routing) Container receives: /notebook/user/workbench/app/
If your application redirects to paths outside of the ${NB_PREFIX}, the Gateway cannot route those requests back to your application. The path-based matching at the Gateway level requires all traffic to stay within the configured prefix.
Your application (or reverse proxy) must handle the full path including the prefix and never redirect outside of it.
Any request from a browser to a different path will not be routed to the workbench container. This is because the routing, handled by the Gateway API uses the same value as the environment variable (NB_PREFIX) that is injected into the workbench at runtime.
4.2. Migrating your custom workbench images to the Kubernetes Gateway API Copiar enlaceEnlace copiado en el portapapeles!
To ensure that your workbench maintains compatibility with the latest versions of Red Hat OpenShift AI, update your custom workbench images to the Kubernetes Gateway API to support this path-based model.
Prerequisites
- You are a Red Hat OpenShift AI user with OpenShift AI administrator privileges.
- Your OpenShift cluster version is at least version 4.19.
- Your Red Hat OpenShift AI Operator version is at least version 3.0.
- Your system can build custom workbench images
Procedure
Implement required health check endpoints. The Gateway API requires a specific endpoint to verify workbench pod availability.
-
Configure the application to return an
HTTP 200status at:GET /{NB_PREFIX}/api.
-
Configure the application to return an
Configure culler support:
To support automatic idleness culling, the workbench must expose kernels and terminal status as JSON arrays. Ensure the application implements these endpoints:
-
GET /{NB_PREFIX}/api/kernels -
GET /{NB_PREFIX}/api/terminals
-
Use relative URLs throughout your application.
NoteAvoid hardcoded absolute paths such as
/static/app.jsor/api/data. These paths bypass the{NB_PREFIX}and cannot be routed by the Gateway. Instead, use relative paths likestatic/app.jsorapi/data, which resolve correctly within the prefixed context.If your application contains hardcoded absolute URLs that cannot be modified, you must use NGINX as a reverse proxy to handle path translation. See Migrating your custom workbench images to the Kubernetes Gateway API using NGINX for configuration details.
Configure your application’s base path.
If your framework supports a configurable base path or root path, set it to the value of the
NB_PREFIXenvironment variable. This ensures that generated URLs, redirects, and static asset references include the correct prefix.For example, in Python frameworks you can set
root_path(FastAPI) orAPPLICATION_ROOT(Flask). In JavaScript frameworks, configure the base URL or public path setting accordingly.
Verification
-
Click on your workbench through the Workbenches tab on the project details page. Verify that the page loads correctly. If the page displays without formatting or functional errors, the
${NB_PREFIX}variable is configured correctly. Use the OpenShift CLI to verify the gateway can reach the health endpoint:
oc exec <pod-name> -- curl -I http://localhost:8888/${NB_PREFIX}/apioc exec <pod-name> -- curl -I http://localhost:8888/${NB_PREFIX}/apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow The command should return an
HTTP/1.1 200 OKresponse.-
Monitor the Gateway Controller logs for
No route matchederrors. These errors indicate that the workbench is sending responses that lack the required path-based routing prefix.
4.3. Migrating your custom workbench images to the Kubernetes Gateway API using NGINX Copiar enlaceEnlace copiado en el portapapeles!
If your application does not support base path configuration, you will need NGINX to handle the path translation.
Prerequisites
- You are a Red Hat OpenShift AI user with OpenShift AI administrator privileges.
- Your OpenShift cluster version is at least version 4.19.
- Your Red Hat OpenShift AI Operator version is at least version 3.0.
- Your system can build custom workbench images.
Procedure
Update redirects to preserve
NB_PREFIX. All redirects must include${NB_PREFIX}to keep requests within the Gateway route:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add a prefix-aware proxy location that matches the full prefixed path, and strips the prefix before proxying.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update health check endpoints to preserve the prefix:
# Health check endpoint location = ${NB_PREFIX}/api { return 302 ${NB_PREFIX}/myapp/healthz/; access_log off; }# Health check endpoint location = ${NB_PREFIX}/api { return 302 ${NB_PREFIX}/myapp/healthz/; access_log off; }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
- Verify that the page loads correctly. If the page displays without formatting or functional errors, the ${NB_PREFIX} variable is configured correctly.
Use the OpenShift CLI to verify the gateway can reach the health endpoint:
oc exec <pod-name> -- curl -I http://localhost:8888/${NB_PREFIX}/apioc exec <pod-name> -- curl -I http://localhost:8888/${NB_PREFIX}/apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow The command should return an
HTTP/1.1 200 OKresponse.-
Monitor the Gateway Controller logs for
No route matchederrors. These errors indicate that the workbench is sending responses that lack the required path-based routing prefix.