第2章环境准备与部署

2、环境准备与部署：在Kubernetes上部署Kubeflow、配置Notebook Server、资源配额管理

说实话，很多同学学 Kubeflow Notebook 卡住，不是因为 Notebook 本身难，而是环境没搭好。我见过太多人花了两三天折腾部署，结果连个 Jupyter 页面都打不开。嗯，这一章咱们就把地基打牢。

我会带你走一遍完整的流程：从 Kubernetes 集群准备，到 Kubeflow 部署，再到 Notebook Server 的配置和资源配额管理。每一步我都会穿插一些我踩过的坑，帮你省点时间。

2.1 部署前的准备工作

先别急着敲命令。你得先确认几件事：

Kubernetes 集群：版本建议 1.22 到 1.25。太老或太新都可能跟 Kubeflow 不兼容。我去年用 1.26 试过一次，结果某个 CRD 死活起不来，最后降级才搞定。
硬件资源：至少 4 核 CPU、16GB 内存、50GB 磁盘。如果你要跑 GPU 任务，记得提前装好 NVIDIA 驱动和 nvidia-docker。
存储类（StorageClass）：Kubeflow 需要动态卷供应。检查一下你的集群有没有默认 StorageClass，没有的话得先配一个。

我的小建议： 如果你只是本地测试，用 kind 或 minikube 都行。但生产环境我强烈推荐用托管的 K8s 服务，比如 EKS、AKS、GKE。省心太多。

2.2 部署 Kubeflow

部署方式有好几种，我个人最常用的是 Kubeflow Manifests 方式。它比较灵活，也方便后续升级。

大致步骤是这样的：

下载 Kubeflow 的 manifest 仓库
按需修改配置（比如存储类、域名）
一键部署

来，看代码：

# 下载 manifests
git clone https://github.com/kubeflow/manifests.git
cd manifests

# 部署（根据你的 K8s 版本选择分支）
git checkout v1.7.0

# 一键安装
while ! kustomize build example | kubectl apply -f -; do
  echo "Retrying to apply resources..."
  sleep 10
done

这里有个坑——网络问题。很多镜像在 gcr.io 上，国内拉不下来。我曾经被这个卡了一整天。解决办法是提前把镜像拉到本地仓库，或者用代理。

注意： 部署过程中如果遇到 CRD 冲突，别慌。先 kubectl delete 掉冲突的资源，再重新 apply。我遇到过两次，都是因为之前残留的旧版本 CRD 没清干净。

部署完成后，检查一下所有 Pod 是否 Running：

kubectl get pods -n kubeflow

看到所有 Pod 状态都是 Running 或 Completed，就说明部署成功了。

2.3 配置 Notebook Server

Kubeflow 部署好之后，你就能在 Dashboard 里看到 "Notebooks" 菜单了。点进去，创建一个新的 Notebook Server。

配置的时候，有几个关键选项：

配置项	说明	我的建议
镜像	选择 Jupyter 或 RStudio 镜像	新手先用官方的 `kubeflownotebookswg/jupyter`
CPU / 内存	给 Notebook 分配的资源	开发环境 2 核 4G 起步，别贪多
GPU	如果需要 GPU 加速	确认节点有 GPU，且装了驱动
Workspace Volume	持久化存储，代码和数据放这里	建议至少 10GB，用默认 StorageClass

配置好之后，点 "Launch"。等一两分钟，Notebook 状态变成 "Ready"，就能点进去用了。

核心逻辑： Notebook Server 本质上是一个 K8s Pod，跑着 Jupyter 服务。你配的 CPU、内存、GPU，都会直接映射到 Pod 的 resource request 和 limit 上。

2.4 资源配额管理

团队里好几个人一起用 Kubeflow，资源怎么分？这就是 ResourceQuota 和 LimitRange 的用武之地了。

我习惯给每个团队或项目建一个独立的 Namespace，然后在里面设置配额。举个例子：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    count/notebooks.kubeflow.org: "10"

这个配额的意思是：team-alpha 这个命名空间下，所有 Notebook 加起来最多用 4 核 CPU 请求、8Gi 内存请求，上限是 8 核和 16Gi。同时最多只能创建 10 个 Notebook。

你可能会问：「那单个 Notebook 能占多少？」这就得靠 LimitRange 来限制了：

apiVersion: v1
kind: LimitRange
metadata:
  name: notebook-limits
  namespace: team-alpha
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "0.5"
      memory: "1Gi"
    default:
      cpu: "1"
      memory: "2Gi"
    type: Container

这样每个 Notebook 容器最少 0.5 核、1Gi，最多 2 核、4Gi。默认值是 1 核 2Gi。嗯，这个设计挺合理的——既防止有人独占资源，又保证每个 Notebook 有基本保障。

避坑指南： 我曾经给一个团队设了很严格的配额，结果他们的 Notebook 一直 Pending。查了半天才发现是 LimitRange 的 min 设得太高，而用户申请的资源比 min 还小。记住：配额是硬约束，设之前最好跟团队沟通一下实际需求。

2.5 本章知识体系

下面这张图帮你理清本章的核心逻辑：

从图里能看出来，整个流程是自上而下的：先有 K8s 集群，再部署 Kubeflow，然后配置 Notebook Server 和资源配额。这两条腿缺一不可——没有配额管理，团队资源容易打架；没有 Notebook Server 配置，你连开发环境都进不去。

好了，环境准备这块就聊到这儿。下一章咱们会深入 Notebook 的日常操作，包括怎么装包、怎么挂载数据、怎么调试。到时候见。

公众号:蓝海资料掘金营，微信 deep3321

📚 课程目录

2、环境准备与部署：在Kubernetes上部署Kubeflow、配置Notebook Server、资源配额管理

2.1 部署前的准备工作

2.2 部署 Kubeflow

2.3 配置 Notebook Server

2.4 资源配额管理

2.5 本章知识体系