从 Jupyter Kernel Gateway 到 Enterprise Gateway一篇文章看懂演进之路【免费下载链接】enterprise_gatewayA lightweight, multi-tenant, scalable and secure gateway that enables Jupyter Notebooks to share resources across distributed clusters such as Apache Spark, Kubernetes and others.项目地址: https://gitcode.com/gh_mirrors/en/enterprise_gateway在 Jupyter 生态的演进史上Jupyter Enterprise Gateway是一道分水岭它把内核只能跑在服务器本地的旧模式升级为内核可被调度到分布式集群的新范式。本文将带你从 Jupyter Kernel Gateway 的起点出发一步步看懂 Enterprise Gateway 为什么诞生、解决了什么问题、又是如何实现的——即使你刚接触分布式内核网关也能轻松读懂这条演进之路。起点Jupyter Kernel Gateway 的三大瓶颈Jupyter Kernel Gateway 是 Jupyter 官方推出的轻量级 Web 服务器它把 Notebook 的 HTTP 请求转发给本机内核。但在企业级、集群化场景下这种本地进程模式很快暴露出三个问题扩展性差所有内核都作为本地进程运行资源受限于单台服务器。下图直观展示了内核全部挤在单节点的典型形态随着集群规模扩大可同时运行的内核数量提升极其有限。安全性弱用户共享相同权限任何用户都可能通过内核命令查看、干扰他人进程缺乏隔离。多租户缺失内核与服务器强绑定无法为不同用户提供独立的资源与权限边界。这些瓶颈正是 Jupyter Enterprise Gateway 出现的直接动因。演进核心从本地内核到托管资源作为 Jupyter Kernel Gateway 的后续项目Jupyter Enterprise Gateway用一句话概括其定位一个轻量、多租户、可扩展且安全的网关让 Jupyter Notebook 可以跨 Apache Spark、Kubernetes 等分布式集群共享资源。它不再是一个服务器上跑内核而是把内核变成托管资源由底层资源管理器如 Hadoop YARN、Kubernetes、Docker Swarm、IBM Spectrum Conductor统一调度到集群任意节点。对比下面这张图可以看到演进后内核不再局限于单节点而是跨节点分配可同时运行的内核数量随集群规模显著增长此外Enterprise Gateway 还带来了三项关键升级端到端安全通信客户端到网关、网关到内核的通道均加密支持 SSL 与 Kerberos 用户模拟多用户支持通过用户模拟实现沙箱隔离不同用户拥有独立权限边界持久化会话内核会话可持久保存支持故障恢复场景。架构剖析Enterprise Gateway 如何做到这一切Enterprise Gateway 的分布式能力建立在三个核心抽象之上相关代码位于enterprise_gateway/services/目录进程代理Process Proxy抽象了内核进程的生命周期管理。默认情况下 Jupyter 假设内核是本地进程而 Enterprise Gateway 通过process_proxy机制把内核进程替换为进程代理从而支持远程内核的启动、探测与销毁。所有代理类都定义在 enterprise_gateway/services/processproxies/ 中其类层级清晰易懂LocalProcessProxy用于本地内核RemoteProcessProxy及其子类如YarnClusterProcessProxy、KubernetesProcessProxy用于各类集群。远程内核管理器Remote Kernel ManagerRemoteMappingKernelManager与RemoteKernelManager重写了 Jupyter 框架的内核启动逻辑见 remotemanager.py。内核启动器Kernel Launcher负责在远端创建连接信息、加密回传、启动内核并监听中断请求样例启动器位于 etc/kernel-launchers/。值得一提的是Enterprise Gateway 的进程代理架构是可插拔的——支持自带进程代理bring your own process proxy这意味着你完全可以为新的资源管理器编写自定义代理。整个部署架构可以用下面这张图来理解客户端通过 HTTPS/WSS 连接网关网关再通过 ZeroMQ 与各工作节点上的内核通信一张表看懂支持的资源管理平台资源平台对应进程代理典型场景Hadoop YARNYarnClusterProcessProxySpark 作业集群调度见 deploy-yarn-cluster.mdKubernetesKubernetesProcessProxy容器化内核与弹性伸缩见 deploy-kubernetes.mdDocker Swarm / DockerDockerSwarmProcessProxy/DockerProcessProxy轻量容器集群IBM Spectrum ConductorConductorClusterProcessProxy企业级资源管理Spark OperatorSparkOperatorProcessProxyKubernetes 上以 SparkApplication 方式运行此外DistributedProcessProxy提供基于 SSH 与轮询算法round-robin的远程主机分发能力。你可以在 etc/kernelspecs/ 中看到大量开箱即用的内核规格样例例如spark_python_yarn_cluster、python_kubernetes、spark_scala_kubernetes等它们展示了不同平台的内核配置写法。快速上手从单机到 Kubernetes 的最小路径对于新手最快的体验方式是单机部署安装 Enterprise Gateway 后把内核规格中的process_proxy指向LocalProcessProxy不写该字段时默认也是本地模式详见 deploy-single.md。如果你的目标是集群化最主流的路径是 Kubernetes准备kubectl与helm3创建命名空间使用项目自带的 Helm Chart 安装模板位于 etc/kubernetes/helm/enterprise-gateway/部署后即可选用python_kubernetes、spark_scala_kubernetes等内核规格启动远程内核。 小提示集群部署前请确保已安装 Kubernetes Operator for Apache Spark否则 Spark 相关内核无法正常调度。未来演进Kernel Provisioners 时代演进之路并未止步。根据项目路线图见 roadmap.mdEnterprise Gateway 的 4.0 版本将用Kernel Provisioners取代进程代理从而解除对旧版jupyter_client与jupyter_server的版本限制并支持参数化内核可交互式配置参数的内核。社区还计划实现高可用HA、管理面板等能力让分布式内核网关更加成熟易用。结语从 Jupyter Kernel Gateway 到 Jupyter Enterprise Gateway演进的本质是把内核从服务器的附属进程升级为可被集群统一调度的第一等公民。如果你正面临多用户共享计算集群、Spark/Kubernetes 资源调度、或者企业级安全隔离的需求Enterprise Gateway 就是那条被反复验证过的演进路径。想深入源码不妨从enterprise_gateway/services/processproxies/processproxy.py读起你会发现一条清晰的抽象之路。【免费下载链接】enterprise_gatewayA lightweight, multi-tenant, scalable and secure gateway that enables Jupyter Notebooks to share resources across distributed clusters such as Apache Spark, Kubernetes and others.项目地址: https://gitcode.com/gh_mirrors/en/enterprise_gateway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考