重大升级：3.* 至 4.*

zero-to-jupyterhub 4.0 是一次重大升级，可能需要对您的配置进行一些更改，具体取决于您使用的功能。这主要体现在一些升级的软件包上，如下所述。

另请参阅

• 每次进行图表重大更新时都需要执行的升级步骤，请参阅常规升级文档

• 有关升级软件包的详细信息，请参阅变更日志

JupyterHub 5

zero-to-jupyterhub 4.0 将 JupyterHub 版本从 4.1.6 升级到 5.2.1。

另请参阅

有关 JupyterHub 更详细的变更，请参阅 JupyterHub 自己的关于升级到版本 5 的文档。

特别是如果您使用诸如每个用户的子域名或自定义页面模板等功能。

• jupyterhub 变更日志

• 升级到 JupyterHub 5

允许用户

JupyterHub 5 将 OAuthenticator 上使用的 allow_all 和 allow_existing_users 配置推广到所有其他 Authenticator。如果您没有明确允许用户，默认设置是不允许任何用户（如果您使用 OAuth，这已经是默认设置）。如果您使用的 Authenticator 允许所有能成功认证的用户访问，请设置

hub:
  config:
    Authenticator:
      allow_all: true

以明确选择加入此行为，该行为以前是某些 authenticator 的默认行为。

KubeSpawner 7

zero-to-jupyterhub 4.0 将 KubeSpawner 版本从 6 升级到 7。这里的主要相关变更是用于计算资源名称（如 pod 和 PVC（用户存储））的“slug 方案”发生了变化。

新方案称为“safe”，是默认方案，而旧方案称为“escape”。如果您没有任何自定义模板字段，那么您很可能不需要做任何更改，一切都应该能正常工作。但是，如果您指定了自定义模板字段，例如卷挂载或环境变量，特别是那些包含 {username} 或 {servername} 字段的，这些值在新方案下对于某些用户名可能会改变。特别地，有一些新字段应该能让事情变得更简单：

• {user_server} 结合了用户名和服务器名，等同于旧 escape 方案中的 {username}{servername}。当一个字符串应该对于每个命名的服务器是唯一的，而不是对于每个用户是唯一的时候，这是推荐的值。

• {pod_name}、{pvc_name}现在可用于引用这些对象的完全解析名称，并可用于避免重复模板。

您可以通过以下配置全局选择保留 kubespawner 6 的行为：

hub:
  config:
    KubeSpawner:
      slug_scheme: escape

这应该能使您的行为与之前版本没有任何变化。

如果您正在使用以下配置，那么有一个面向用户的地方，默认模板可能需要管理员操作：

singleuser:
  storage:
    type: static

subPath 的默认值是 {username}，对于某些用户名，这可能会解析为不同的值，这可能看起来像主目录“丢失”了，因为挂载路径改变了。数据没有丢失，但挂载位置已更改。为确保此值不变，您可以使用：

singleuser:
  storage:
    type: static
    static:
      subPath: "{escaped_username}"

这将对 subPath 应用之前的“escape”方案。或者，您可以保留新方案，并执行一次性迁移，为受影响的用户名移动文件。

另请参阅

• KubeSpawner 变更日志

• KubeSpawner 关于模板字段的文档