平台架构 云原生依赖 - tencentmusic/cube-studio GitHub Wiki
rancher/kubernetes
cube-studio利用Kubernetes的优势:
- 原生的环境隔离
- 集群化自动化管理
- 计算资源(CPU/GPU)自动调度
- 成熟的生态体系
- crd/operator便捷的api方式管理
机器环境配置好以后，我们就可以来部署k8s机器了。下面是k8s的一个架构。
CRD
除了需要了解k8s官方资源，例如pod，service，sa，rbac，sts，deployment外，另外我们需要特别了解k8s的自定义资源CustomResourceDefinition。简称CRD。这个在机器学习平台中使用非常频繁，下面列举用到的常用的部分crd。
| Kubeflow自定义资源类型 | 组 | 是否命名空间内 | kind | 说明 |
|---|---|---|---|---|
| pytorchjobs | kubeflow.org | TRUE | PyTorchJob | pytorch分布式训练 |
| tfjobs | kubeflow.org | TRUE | TFJob | tf分布式训练 |
| mpijobs | kubeflow.org | TRUE | MPIJob | mpi分布式训练 |
| mxnetjobs | kubeflow.org | TRUE | MxnetJob | mxnet分布式训练 |
| sparkapplications | sparkoperator.k8s.io | TRUE | SparkJob | spark分布式任务 |
| Argo自定义资源类型： | 组 | 是否命名空间内 | kind | 说明 |
|---|---|---|---|---|
| workflows | argoproj.io | TRUE | Workflow | argo的workflow |
| prometheus自定义资源类型： | 组 | 是否命名空间内 | kind | 说明 |
|---|---|---|---|---|
| alertmanagers | monitoring.coreos.com | TRUE | Alertmanager | prometheus监控k8s的报警机制 |
| prometheuses | monitoring.coreos.com | TRUE | Prometheuse | prometheus部署实例 |
| prometheusrules | monitoring.coreos.com | TRUE | Prometheusrule | prometheus拉取配置 |
| servicemonitors | monitoring.coreos.com | TRUE | Servicemonitor | prometheus拉取某个服务下的所有pod指标 |
| istio自定义资源类型： | 组 | 是否命名空间内 | kind | 说明 |
|---|---|---|---|---|
| gateways | networking.istio.io | TRUE | Gateway | istio 网关 |
| virtualservices | networking.istio.io | TRUE | Virtualservice | istio 虚拟服务 |
| volcano自定义资源类型： | 组 | 是否命名空间内 | kind | 说明 |
|---|---|---|---|---|
| jobs | batch.volcano.sh | TRUE | Gateway | 批处理任务 |
| queues | scheduling.volcano.sh | TRUE | Queue | 批优先级队列 |
scheduler
k8s的调度包含很多方面，有节点选择，亲密度，污点，还有其他过滤打分的环节。下面是cube种使用到的调度机制
其中scheduler-policy-config的配置可以参考如下。
主要使用场景是在不同pipeline的任务同时发起时，希望每台机器都能被均匀的使用，而不是过度集中在其中数台服务器上。
如果在rancher使用使用还需要将文件挂载到调度器中
coredns
往往内网部署，在pod中会有内网域名的使用，往往需要在pod配置内网的dns解析服务器，配置参考如何，可以修改kube-system命名空间的对应configmap，然后重启coredns 配置地址