Baremetal OpenStack上的Kubeflow

最新推荐文章于 2024-09-19 10:29:53 发布

新钛云服

最新推荐文章于 2024-09-19 10:29:53 发布

阅读量489

点赞数

本文链接：https://blog.csdn.net/NewTyun/article/details/106010241

版权

Kubeflow是Kubernetes的机器学习工具包。它的目的是将流行的工具和库归为一类，以使用户能够：

生成具有持久容量的Jupyter notebooks，用于进行探索性工作。
在最初对TensorFlow 生态系统的支持下，构建，部署和管理机器学习pipelines，但此后扩展到包括最近在研究界越来越受欢迎的其他库（例如PyTorch）。
调整hyperparameters, serve models, etc.等

为了不断证明OpenStack管理的裸机基础设施是执行前沿技术的合适平台，我们着手将这种流行的机器学习框架部署在以OpenStack Magnum为基础部署的Kubernetes容器编排层之上。裸机OpenStack云的控制平面则由使用Kayobe部署的Kolla容器组成，该容器将容器化的OpenStack 部署到裸机，这也是我们如何管理绝大多数部署到客户站点的方式。运行裸机实例的理由是最大程度地降低虚拟化的性能开销。

版本与实例

除了OpenStack Magnum（出于各种原因，它必须至少是Stein8.1.0）之外，裸金属OpenStack云（最低Rocky版本）将在后面详细说明，但为了支持Fedora Atomic 29，它将解决早期Docker版本中的CVE。
一些备用的裸机实例（1个主实例和1个工作实例最少2个）。

部署步骤

使用OpenStack Magnum提供Kubernetes集群。对于此步骤，我们建议使用Terraform或ansible。自ansibe2.8以来，os_coe_cluster_template和os_coe_cluster modules可以支持Magnum集群模板和集群创建，我们选择了用户体验更好的Terraform，因为它理解集群模板和集群之间的相互依赖关系，因此可以自动确定创建和更新它们的顺序。确切地说，我们使用在这个repose中定义的Terraform模板创建集群，其中README.md详细介绍了如何设置Terraform、上载images和引导Ansible，以便部署Kubeflow。我们传递到群集模板的密钥标签如下：

cgroup_driver="cgroupfs"ingress_controller="traefik"tiller_enabled="true"tiller_tag="v2.14.3"monitoring_enabled="true"kube_tag="v1.14.6"cloud_provider_tag="v1.14.0"heat_container_agent_tag="train-dev"

运行./terraform init && ./terraform apply创建集群。
集群准备就绪后，请使用magnum-tiller.sh来使用Magnum启用的分er，并运行我们的Ansible Playbooks以将Kubeflow连同入口部署到所有服务（编辑变量 /example.yml 以适合您的OpenStack环境）：

ansible-playbook k8s.yml -e @variables/example.yml

此时，我们应该会看到一个入口列表，在运行kubectl get ingress -a时默认使用 * -minion-0作为入口节点。我们使用基于anip.io的通配符DNS服务，以便从不同子域生成的流量映射到我们部署的各种服务。例如，Kubeflow仪表板部署为ambassador-ingress，而Tensorboard仪表板部署为tensorboard-ingress。类似地，通过设置monitoring_enabled = True标签部署的Grafana仪表板也部署为monitoring-ingress。该 mnist-ingress Ingress目前正在充当下一部分的占位符，在下一部分中，我们将使用Kubeflow ML管道来训练和提供模型。

$ kubectl get ingress -ANAMESPACE    NAME                  HOSTS                           ADDRESS   PORTS   AGEkubeflow     ambassador-ingress    kubeflow.10.145.0.8.nip.io                80      35hkubeflow     mnist-ingress         mnist.10.145.0.8.nip.io                   80      35hkubeflow     tensorboard-ingress   tensorboard.10.145.0.8.nip.io             80      35hmonitoring   monitoring-ingress    grafana.10.145.0.8.nip.io                 80      35h

下一步是将ML工作流部署到Kubeflow。我们自己在Kubeflow示例上逐步阅读了MNIST的自述文件中的说明，我们自己和kustomize使用的最小定制，成功地训练了模型，并通过一个漂亮的前端为其服务。Web界面应该可以通过NIST入口发送点访问。

git clone https://github.com/stackhpc/kubeflow-examples examples -b dellcd examples/mnist && bash deploy-kustomizations.sh

监控注意事项

Kubeflow带有Tensorboard服务，该服务使用户可以通过在模型分类之前减少最后一层权重的潜在空间来可视化机器学习模型训练日志，模型架构以及模型本身的有效性。

OpenStack Monasca服务的可扩展性也非常适合集成到机器学习模型训练循环中，因为已将代理配置为接受工作人员上的非本地流量，这可以通过在/etc/monasca//agent.yaml中设置以下值来完成并重新启动monasca-agent.target服务：

monasca_statsd_port: 8125non_local_traffic: true

在运行机器模型示例的客户端，现在可以将感兴趣的监控指标发布到monasca-agent。例如，我们可以为FastAI提供一个回调函数，FastAI是一个机器学习包装库，使用下面的PyTorch原语，着重于传递学习（可以在Kubeflow上作为GPU flavored notebook container启动）来执行诸如图像和自然语言之类的任务处理。库的训练循环挂接到封装在PostMetrics类中的回调函数中，这些回调函数在模型训练过程的每个阶段结束时定义如下：

# Import the module.from fastai.callbacks.loss_metrics import *import monascastatsd as mstatsdconn = mstatsd.Connection(host='openhpc-login-0', port=8125)# Create the client with optional dimensionsclient = mstatsd.Client(connection=conn, dimensions={'env': 'fastai'})# Create a gauge called fastaigauge = client.get_gauge('fastai', dimensions={'env': 'fastai'})class PostMetrics(LearnerCallback):    def __init__(self):        self.stop = False    def on_batch_end(self, last_loss, **kwargs:Any)->None:        if self.stop: return True #to skip validation after stopping during training        # Record a gauge 50% of the time.        gauge.send('trn_loss', float(last_loss), sample_rate=1.0)    def on_epoch_end(self, last_loss, epoch, smooth_loss, last_metrics, **kwargs:Any):        val_loss, error_rate = last_metrics        gauge.send('val_loss', float(val_loss), sample_rate=1.0)        gauge.send('error_rate', float(error_rate), sample_rate=1.0)        gauge.send('smooth_loss', float(smooth_loss), sample_rate=1.0)        gauge.send('trn_loss', float(last_loss), sample_rate=1.0)        gauge.send('epoch', int(epoch), sample_rate=1.0)  # Pass PostMetrics() callback function to cnn_learner's training loop  learn = cnn_learner(data, models.resnet34, metrics=error_rate, bn_final=True, callbacks=[PostMetrics()])

这些指标将发送到OpenStack Monasca API，然后可以在Grafana仪表板上针对GPU功耗进行可视化，然后可以让用户确定对模型精度的权衡，如下图所示：

另外，一般资源使用情况监视也可能是令人感兴趣的。 Magnum上有两个基于Prometheus的监视选项：

首先，基于非安全性的方法使用prometheus_monitoring标签，该标签在设置为True时会部署由节点导出程序的Prometheus服务，Grafana服务和DaemonSet（Kubernetes术语，转换为集群中每个节点的服务）组成的node exporter。但是，由于Grafana的最新版本中默认仪表板的加载方式发生了变化，因此已部署的Grafana服务没有提供任何有用的仪表板作为与收集的指标的接口。仪表板可以手动安装，但不允许用户进一步深入查看可见指标并以平面方式显示信息。
其次，基于Helm的方法（推荐）需要将 monitoring_enabled和tiller_enabled标签设置为 True。它部署了与上述类似的监控堆栈，但由于它基于helm，因此也可以升级。在这种情况下，Grafana服务预装了几个仪表板，这些仪表板以有意义的方式显示了节点导出器收集的指标，允许用户深入查看各种级别的详细信息和分组类型，例如按集群，名称空间，pod，节点，等等

当然，也可以在不由Magnum管理的情况下部署基于Prometheus的监视堆栈。此外，我们已经证明，部署在容器内部运行的Monasca agent也可以选择将度量标准发布到Monasca API，如果将其配置为监视控制平面度量标准的方式，则可能可用。

我们建议将Magnum升级到Stein（8.1.0版）

OpenStack Magnum (Rocky)最多支持Fedora Atomic 27，即EOL。对Fedora Atomic 29（具有前面提到的CVE的修复程序）的支持需要从master分支向后移植各种修复程序，以恢复对Magnum支持的两种网络插件类型（即Calico和Flannel）的支持。
此外，对Kubernetes API所做的更改超出了Magnum项目的控制范围。Rocky仅支持高达v1.13.x的Kubernetes版本，而Kubernetes项目维护者仅积极维护开发分支和3个稳定版本。当前的开发版本是v1.17.x，这意味着v1.16.x，v1.15.x和1.14.x可以期待更新和重要补丁的反向移植。Train发布对v1.15.x和v1.16.x的支持，但是升级到Stein将使我们能够支持最高v1.14.x。
magnum部署的traefik ingress controller在Rocky版本中不再生效，因为以前的行为是始终部署 最新标签。但是，已经发布了新的主要版本（2.0.0），其中包含对API的重大更改，这些更改不可避免地会失败。Stein 8.1.0有必要的修复，此外，还支持更流行的基于nginx的ingress controller。