ghcr.io/kserve/models-web-app:sha-0e94887

模型Web应用

此Web应用负责允许用户在Kubeflow集群中管理KServe推理资源。它提供了一种用户友好的方式来处理InferenceService和InferenceGraph自定义资源的生命周期。

支持的资源

• serving.kserve.io/v1beta1版本的InferenceService资源
• serving.kserve.io/v1alpha1版本的InferenceGraph资源

当前范围

InferenceService和InferenceGraph均为应用中的一等资源，但目前它们并未共享完全相同的UI界面。

• InferenceService仍是主要的模型服务器管理流程，包括主要的列表/详情体验和服务特定的操作视图。
• InferenceGraph可通过专用的列表、创建、编辑和详情路由访问。
• InferenceGraph详情目前侧重于图概述、事件和YAML，而非InferenceService的完整操作视图集。

文档

• 测试指南 - 使用Jest和Cypress进行单元测试和端到端测试的综合指南

连接到应用

Web应用与其他KServe组件一同安装，位于kserve命名空间或kubeflow命名空间中。存在一个VirtualService通过Istio Ingress Gateway暴露应用。根据安装环境，将使用以下Ingress Gateway：

要访问应用，需在浏览器中导航至：

${INGRESS_IP}/models/

或者，可通过kubectl port-forward访问应用。在此情况下，需将应用配置为：

• 不执行任何授权检查，因为没有登录用户
• 在/前缀下工作
• 禁用安全Cookie，因为应用将通过纯HTTP暴露

可通过以下命令应用上述配置：

# 编辑配置映射
# CONFIG=manifests/kustomize/overlays/kubeflow/kustomization.yaml
CONFIG=manifests/kustomize/base/kustomization.yaml
vim ${CONFIG}

# 向configMapGenerator的literals添加以下环境变量
# 针对kserve-models-web-app-config
- APP_PREFIX=/
- APP_DISABLE_AUTH="True"
- APP_SECURE_COOKIES="False"

# 重新应用kustomization
# kustomize build manifests/kustomize/overlays/kubeflow | kubectl apply -f -
kustomize build manifests/kustomize/base | kubectl apply -f -

配置

以下是可为此基础应用所构建的任何Web应用设置的环境变量列表：

命名空间过滤配置

对于独立部署，使用ALLOWED_NAMESPACES配置用户可访问的命名空间：

• 空值/未设置（默认）：可访问所有集群命名空间
• 单个命名空间：ALLOWED_NAMESPACES="kubeflow-user" - 自动选择，隐藏下拉菜单
• 多个命名空间：ALLOWED_NAMESPACES="ns1,ns2,ns3" - 过滤下拉菜单

无效命名空间将被忽略；若没有有效命名空间，将回退到所有命名空间。

示例

# 仅允许访问一个命名空间（自动选择，隐藏下拉菜单）
export ALLOWED_NAMESPACES="kubeflow-user"

# 允许访问多个特定命名空间
export ALLOWED_NAMESPACES="kubeflow-user,kubeflow-admin,ml-team"

# 默认行为 - 可访问所有命名空间
unset ALLOWED_NAMESPACES

Kubernetes部署

将环境变量添加到部署配置中：

apiVersion: apps/v1
kind: Deployment
metadata:
name: kserve-models-web-application
spec:
template:
spec:
containers:
- name: kserve-models-web-application
env:
- name: ALLOWED_NAMESPACES
value: "kubeflow-user,kubeflow-admin"

Grafana配置

应用支持Grafana端点和仪表板名称的运行时配置，允许使用自定义Grafana实例和仪表板配置，无需重新构建应用。

若使用Kustomize在Kubernetes上部署，可通过编辑manifests/kustomize/base/kustomization.yaml（或您的覆盖层）中kserve-models-web-app-config的configMapGenerator来设置这些值。根据需要更新以下文字值：

• GRAFANA_PREFIX（例如，/grafana或/custom-grafana）
• GRAFANA_CPU_MEMORY_DB（例如，db/custom-cpu-memory-dashboard）
• GRAFANA_HTTP_REQUESTS_DB（例如，db/custom-http-requests-dashboard）

编辑后，重新应用清单，例如：

kustomize build manifests/kustomize/base | kubectl apply -f -

配置API

可通过访问/api/config端点验证Grafana配置：

curl http://your-app-url/api/config

预期响应：

{
"grafanaPrefix": "/custom-grafana",
"grafanaCpuMemoryDb": "db/custom-cpu-memory-dashboard",
"grafanaHttpRequestsDb": "db/custom-http-requests-dashboard"
}

开发

前端使用Angular构建，后端使用Python Flask框架编写。

此Web应用利用kubeflow/notebooks仓库中的通用代码。我们希望在不同的Kubeflow Web应用中保持相同的用户体验，并使它们处于相同的开发状态。为此，应用将使用此共享通用代码。

这要求在本地构建应用或构建OCI容器镜像时获取此通用代码。

要在本地运行应用，需：

• 以监视模式构建前端
• 运行后端

npm run build:watch命令会将前端制品构建到后端的static文件夹中以进行服务。因此，要查看应用，需启动后端并连接到localhost:5000。

要求

• node 22.0.0
• python 3.12

前端

选项1：使用Makefile（推荐）

cd $KSERVE_MODELS_WEB_APPLICATION_REPOSITORY/frontend

# 设置依赖并构建通用库
make setup

# 可选：指定自定义Kubeflow仓库路径。默认：`../../notebooks`（相对于frontend目录）
# make setup KF_REPO=/path/to/notebooks
# 清理命令：提供make clean目标以移除node_modules
# make clean

# 构建并监视更改
npm run build:watch

选项2：手动设置

# 构建通用库
COMMIT=$(cat ./frontend/COMMIT)
cd $KUBEFLOW_REPOSITORY/components/crud-web-apps/common/frontend/kubeflow-common-lib
git checkout $COMMIT

npm i
npm run build
cd dist/kubeflow
npm link

# 运行应用前端
cd $KSERVE_MODELS_WEB_APPLICATION_REPOSITORY/frontend
npm i
npm link kubeflow
npm run build:watch

后端

本地运行

# 创建虚拟环境并安装依赖
# https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/
cd $KSERVE_MODELS_WEB_APPLICATION_REPOSITORY/backend
python3.12 -m pip install --user virtualenv
python3.12 -m venv web-application-development
source web-application-development/bin/activate

# 在激活的虚拟环境中安装依赖
KUBEFLOW_REPOSITORY="/path/to/kubeflow/notebooks" make -C backend install-deps

# 运行后端
make -C backend run-dev

已知问题

使用oauth2-proxy的大型JWT令牌

具有大型JWT令牌的用户（常见于Azure AD和广泛的组成员身份）可能会遇到请求失败。部署包含Gunicorn配置（GUNICORN_CMD_ARGS=--limit-request-field_size 32000）以处理更大的头部。

有关更多详细信息，请参阅oauth2-proxy已知问题。