实战，在Kubeflow中启动Jupyter notebook

写了一篇本篇的续，可以自动创建PV:https://blog.csdn.net/pushme_pli/article/details/88561261

今天装好了Kubeflow，准备玩一个E2E的case。按照Kubeflow的设计，它拥有全生命周期的ML/DL的开发和部署，也就是说囊括了

模型编写 --- 模型训练 — 超参搜索 — infrerence部署等全流程的支持，我决定试一试，当然从第一部开始，代码编写，现在看起来，这个开端并不容易！

在kubeflow中对于代码编写提供了业内最为著名的在线类IDE：Jupyter Nodebook的多用户版本Jupyter Hub，使用随便一个名字登录后见下图：

看起来是要求Spawn一个盖用户自己使用的Server，事实上也是如此, 会在k8s中新建一个名为jupyter-${username}的pod。

我选择了默认配置，直接点击Spawn，糟糕的事情发生了，页面一直卡着如下图：

别等了，放任不管的话会卡30min，别问我怎么知道的。

这时候我们查看k8s中的pod：

可以看到新建的pod状态为pending

用describe看看：

看起来跟PVC有关系哈，查查PVC

确实有一个pvc在pending状态，也能理解，Jupyter Nodebook是需要存储用户代码的，所以建立pvc应该是再正常不过了，可是为啥penging呢，

用describe

得到的错误是没有pv并且没设storageclasses，按照k8s的定义，如果pvc没有设置storageclass，那么将按照dynamic provision的设置对待，具体来说是寻找default storageclass。

那么坏了，我的k8s环境压根没default storageclass，赶紧建个：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

光有Storageclass没有响应的PV也不成啊，再建个PV

kind: PersistentVolume
apiVersion: v1
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: local
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

搞好了这一切我们重新换个用户重新Spawn

这次看起来蛮好，但是pod仍然是pending，查了查原因，居然说”jovyan”这个用户没有权限！jovyan是个什么鬼，赶紧查了查，在Spawn前的高级选线中发现了玄机：

感情这是个内置的用户啊，在我新建的PV中没权限啊，赶紧把PV的路径/mnt/data付了777权限，发现，成了！

下面是我解决问题参考的页面：

https://github.com/kubeflow/kubeflow/issues/2076

https://github.com/kubeflow/kubeflow/pull/469

https://github.com/kubeflow/kubeflow/issues/365