此内容没有您所选择的语言版本。

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

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.

Important

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.

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

  1. Implement required health check endpoints. The Gateway API requires a specific endpoint to verify workbench pod availability.

    • Configure the application to return an HTTP 200 status at: GET /{NB_PREFIX}/api.
  2. 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
  3. Use relative URLs throughout your application.

    Note

    Avoid hardcoded absolute paths such as /static/app.js or /api/data. These paths bypass the {NB_PREFIX} and cannot be routed by the Gateway. Instead, use relative paths like static/app.js or api/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.

  4. 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_PREFIX environment 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) or APPLICATION_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}/api
    Copy to Clipboard Toggle word wrap

    The command should return an HTTP/1.1 200 OK response.

  • Monitor the Gateway Controller logs for No route matched errors. These errors indicate that the workbench is sending responses that lack the required path-based routing prefix.

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

  1. Update redirects to preserve NB_PREFIX. All redirects must include ${NB_PREFIX} to keep requests within the Gateway route:

    # ❌ BAD - Strips prefix
    location = ${NB_PREFIX} {
        return 302 $custom_scheme://$http_host/myapp/;
    }
    
    # ✅ GOOD - Preserves prefix
    location ${NB_PREFIX} {
        return 302 $custom_scheme://$http_host${NB_PREFIX}/myapp/;
    }
    Copy to Clipboard Toggle word wrap
  2. Add a prefix-aware proxy location that matches the full prefixed path, and strips the prefix before proxying.

    location ${NB_PREFIX}/myapp/ {
        # Strip the prefix before proxying to backend
        rewrite ^${NB_PREFIX}/myapp/(.*)$ /$1 break;
    
        # Proxy to your application
        proxy_pass http://localhost:8080/;
        proxy_http_version 1.1;
    
        # Essential for WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    
        # Long timeout for interactive sessions
        proxy_read_timeout 20d;
    
        # Pass through important headers
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $custom_scheme;
    }
    Copy to Clipboard Toggle word wrap
  3. Update health check endpoints to preserve the prefix:

    # Health check endpoint
    location = ${NB_PREFIX}/api {
        return 302 ${NB_PREFIX}/myapp/healthz/;
        access_log off;
    }
    Copy to Clipboard Toggle word wrap

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}/api
    Copy to Clipboard Toggle word wrap

    The command should return an HTTP/1.1 200 OK response.

  • Monitor the Gateway Controller logs for No route matched errors. These errors indicate that the workbench is sending responses that lack the required path-based routing prefix.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部