使用 Dask Gateway 保护 Pangeo

在过去几周中，我们对 Pangeo 的云部署进行了一些激动人心的更改。这些更改将使用户更轻松地使用 Pangeo 的集群，同时使部署对管理员而言更加安全和可维护。

从 最初的原型 开始，Pangeo 的云部署一直将类似 Jupyterlab 的用户界面与可扩展计算相结合。直到最近，Pangeo 还在使用 Dask Kubernetes 在 Kubernetes 集群上启动 Dask 集群。这在几年内运作良好，但存在一些缺点。

1. 自定义计算环境通常需要一些 Kubernetes 知识
2. Dask Kubernetes 需要更广泛的权限才能与 Kubernetes API 交互，包括创建和删除 Pod 和服务的能力

为了解决这些问题，我们在 Pangeo 的 Helm Chart 中包含了 Dask Gateway，这是一个安全的多租户服务器，用于管理 Dask 集群。Pangeo 的 Binder 和 Jupyterhub 现在启用了 Dask Gateway，这有利于用户和集群管理员（他们通常只是戴着不同帽子的用户）。

对用户的好处

以前，希望自定义 Dask 集群的用户通常需要直接与 Kubernetes API 交互，而 Kubernetes API 非常庞大。例如，假设我们有一个工作负载，该工作负载比较占用内存：我们加载了大量数据，但进行了一些非常简单的转换。因此，我们希望调整 CPU 内核与内存的比例，以获得更多内存。Pangeo 管理员在配置文件中提供了一些默认值。

# file: dask_config.yaml
kubernetes:
  worker-template:
    spec:
      containers:
      - args:
          - dask-worker
          - --nthreads
          - '2'
          - --memory-limit
          - "7GB"
        resources:
          limits:
            cpu: 2
            memory: "7G"
          requests:
            cpu: 1
            memory: "7G"

创建 dask_kubernetes.KubeCluster 时，这些值会自动使用。对于我们的“高内存”工作负载，我们需要调整几个地方才能获得 CPU 内核与内存的所需比例。

containers = [
    {
        "args": [
            "dask-worker", "--nthreads", "1",
            "--memory-limit", "14GB",
        ],
        "resources": {
            "limits": {"cpu": 1, "memory": "14G"},
            "requests": {"cpu": 1, "memory": "14G"},
        },
    }
]

dask.config.set(**{"kubernetes.worker-template.spec.containers": containers})

对于这个“给我更少的内核和更多内存”的相对简单的请求，我们需要大量的专业知识。

将此与 Dask Gateway 解决相同问题的方法进行比较。集群管理员可以 向用户公开选项。用户可以使用图形小部件或通过代码从这些选项中进行选择。

这是在整个 Jupyter 生态系统中使用的相同技术的扩展，因此使用 ipywidgets 等库的用户会发现界面很熟悉。

对管理员的好处

Dask-Kubernetes 要求在 Kubernetes Pod 上具有 更广泛的权限，这对某些组来说可能存在问题。使用 Dask Gateway，只有管理员部署的服务需要直接与 Kubernetes 集群交互。用户完全隔离。

Pangeo 管理员现在可以更好地控制集群的使用方式。我们可以设置服务器端限制，例如集群的最大大小和每个用户同时使用的集群数量。以前，用户可以创建巨大的 Dask 集群，这些集群会淹没我们的 Kubernetes 集群，降低任何其他使用该集群的人的体验，并给 Pangeo 带来经济损失。

迁移到 Dask Gateway

现在，Dask Gateway 默认在所有 Pangeo 云部署中可用，我们希望帮助熟悉 Dask-Kubernetes 的用户迁移到 Dask Gateway。幸运的是，在两者之间进行迁移非常简单。

Dask-Kubernetes 集群的典型用法

from dask.distributed import Client
from dask_kubernetes import KubeCluster


cluster = KubeCluster()  # create cluster
cluster.scale(...)  # scale cluster

client = Client(cluster)  # connect Client to Cluster

现在，要使用 Dask Gateway 创建 Dask 客户端

from dask.distributed import Client
from dask_gateway import Gateway


gateway = Gateway()  # connect to Gateway

cluster = gateway.new_cluster()  # create cluster
cluster.scale(...)  # scale cluster

client = Client(cluster)  # connect Client to Cluster

Dask Gateway 提供了一些关于如何使用其 API 的 很棒的文档，但我们还是会解释一下其中的一些区别

• gateway = Gateway()：连接到 Dask Gateway 部署。此网关将管理 Dask 集群并代理对 Kubernetes API 的访问。
• cluster = gateway.new_cluster()：我们没有实例化 KubeCluster，而是要求 Gateway 为我们创建一个新集群。这将返回一个行为与其他 Dask Cluster 对象非常相似的对象。
• cluster.scale()：这里没有变化。使用 .scale() 或 .adapt() 对集群进行扩展和缩减。请注意，Dask Gateway 可能会对 CPU 或内存使用等方面实施每个用户或每个集群的限制。
• client = Client(cluster)：这里也没有变化。将客户端连接到集群可确保在所有将来的计算中使用该集群。

就这样！主要的变化是，我们正在与 Gateway 交互，而不是直接与 Kubernetes 集群交互。其他所有内容（包括集群持久性和扩展）将与以前相同。

此 Binder 包含一个在 Pangeo Binder 上使用 Dask Gateway 的可运行示例。

如果您使用的是 Pangeo 的 Binder 部署之一（在 Google 上 或 在 AWS 上），您现在需要在环境中包含 Dask Gateway，而不是 dask-kubernetes。有关更多信息，请参阅 pangeo-binder 文档。

总结

我们希望这篇关于 Dask Gateway 的简要介绍以及 Pangeo 为什么采用它对您有所帮助。有关更多详细信息，请关注 此 GitHub 问题 和链接的拉取请求。虽然我们预计在 Pangeo 的部署中继续支持 Dask-Kubernetes 一段时间，但我们最终会 关闭 此集成。