@
dcoder 我只想說, 沒必要把 k8s 說到一無是處。我看還是很多團隊在用 k8s 堆 GPU, 因為我也是其中之一。
隨便 Google 一下"gpu cluster management"看到不少方案都是 k8s 的, 這沒有甚麼不好吧。
因為直接在現有 k8s cluster 上堆 GPU node pool, 改動很少但就是可以解決問題, Dev 直接用 CUDA runtime docker image 打包過來就能 Deploy, 也不用花時間自行分配哪台 node 多少 GPU, 需求無論是 1 台 GPU 還是 100 台都是一樣的, 才不會跟你慢慢在查系統驅動配置或對齊 Run-time 的, 直接加一句 "
nvidia.com/gpu" , 然後 Failover/Scaling 都依照既有的方法去做, 學過的都會。
k8s 的 CNI 才沒很古老好嗎? SDN 的都有相應 CNI plugin 啊, Multus 用過了嗎? Calico 用過了嗎? SR-IOV 用過了嗎? 哪裡慢了? 哪裡 SDN 不能用了? 就是有 CNI 插件設計才能讓各種專業的網絡方案都套進 k8s 啊。
快速 join cluster 的問題其實要處理的是 VM creation 的時間, 然後是 kubeadm join 前的環境安裝, 如果 kubelet/kubeadm/container engine 等等東西都預先打包準備好, 那不可能要 10 分鐘的, 但是在 Cloud Managed k8s 上能調整的東西不多, 例如有些 Cloud k8s 是在 VM 開機時才用 script 安裝 kubeadm/kubelet/containerd 的, 因為這麼做會比直接用包好的 node images 更乾淨也易於更新。有開機時間追求的話請自建 k8s, 只是大部分公司也沒有那種需要, 也沒能力, 才有 Cloud Managed k8s 產品出現。
DevOps/SRE 弄得好, 其他小問題就可以丟給當值的 Junior ops 處理, 而 Devs 也不必參與突發事件, 最後大家也輕鬆一點才是理想的狀態。