kubeflow

作者 | 王庆璨（阿里云技术专家）、张凯（阿里云高级技术专家） **导读：**阿里云容器服务团队结合多年 Kubernetes 产品与客户支持经验，对 Kube-scheduler 进行了大量优化和扩展，逐步使其在不同场景下依然能稳定、高效地调度各种类型的复杂工作负载。《进击的 Kubernetes 调度系统》系列文章将把我们的经验、技术思考和实现细节全面地展现给 Kubernetes 用户和开发者，期望帮助大家更好地了解 Kubernetes 调度系统的强大能力和未来发展方向。本文为该系列文章的第二篇。 前言 什么是 Coscheduling 和 Gang scheduling。Wikipedia 对 Coscheduling 的定义是“在并发系统中将多个相关联的进程调度到不同处理器上同时运行的策略”。在 Coscheduling 的场景中，最主要的原则是保证所有相关联的进程能够同时启动。防止部分进程的异常，导致整个关联进程组的阻塞。这种导致阻塞的部分异常进程，称之为“碎片（fragement）”。 在 Coscheduling 的具体实现过程中，根据是否允许“碎片”存在，可以细分为 Explicit Coscheduling，Local Coscheduling 和 Implicit Coscheduling。 其中 Explicit Coscheduling 就是大家常听到的

本文转载自公众号“读芯术”(ID：AI_Discovery)。 机器学习(ML)被称为技术债务的高利率信用卡。对于特定的业务问题，使用适用的模型会相对容易一些，但是要使该模型在可伸缩的生产环境中运行，并能够处理不断变化的混乱数据语义和关系，以及以可靠的自动化方式演进模式，则完全是另一回事。 对于机器学习生产系统而言，只有5%的实际代码是模型本身。将一组机器学习解决方案转变为端到端的机器学习平台的，是一种运用了加速建模、自动化部署和确保生产中的可伸缩性和可靠性的技术的架构。 笔者此前讲过lean D/MLOps，数据和机器学习操作，因为没有数据的机器学习操作是没有意义的，所以端到端机器学习平台需要进行整体构建。CI/CD基金会启动了一个MLOps特别兴趣小组(SIG)。其端到端机器学习平台确定的步骤如下图所示： 不过，其中掩盖了一些不太重要的细节。例如，服务可能需要不同的技术取决于它是否是实时完成的。可伸缩的解决方案通常将模型放在一个负载均衡器后的服务集群的多个机器上的容器内运行。因此，上述图表中的单个框并不意味着实际平台的单个步骤、容器或组件。 这并不是对图中步骤进行批评，而是一个警示：看似简单的事情在实践中可能并不那么容易。 图表中没有模型(配置)管理。可以考虑诸如版本控制、实验管理、运行时统计、用于培训、测试和验证数据集的数据沿袭跟踪，从头开始或从模型快照、超参数值

github 官方地址 https://github.com/kubeflow/kfserving kfserving 内部使用的是knative。 封装了一层InferenceService的k8s自定义资源，来实现knative中serving的services,route,configurations,revision knative 创建管理网络部分 certificates kcert networking.internal.knative.dev true Certificate ingresses ing networking.internal.knative.dev true Ingress serverlessservices sks networking.internal.knative.dev true ServerlessService 同时创建管理自动化部署部分 configurations config,cfg serving.knative.dev true Configuration revisions rev serving.knative.dev true Revision routes rt serving.knative.dev true Route services kservice,ksvc serving. 来源： oschina 链接

随着机器学习领域不断发展，对于处理机器学习的团队来说，在1台机器上训练1个模型已经有些难以为继，并且现在业界的共识是机器学习已经不仅仅是简单的模型训练。 在模型训练之前、过程中和之后，需要进行许多活动，对于要生成自己的ML模型的团队来说尤其如此。下图常常被引用来说明此类情况： 对于许多团队来说，将机器学习的模型从研究环境应用到生产环境这一过程困难重重，背负很大的压力。糟糕的是，市面上处理每类问题的工具都数量惊人，而这些海量工具都有望解决你所有的机器学习难题。 但是整个团队学习新工具通常很耗时，并且将这些工具集成到你当前的工作流程中也并不容易。这时，或许可以考虑Kubeflow，这是为需要建立机器学习流水线的团队而打造的一个机器学习平台，它包括许多其他工具，可以用于服务模型和调整超参数。Kubeflow尝试做的是将同类最好用的ML工具整合在一起，并将它们集成到一个平台中。 来源： https://www.kubeflow.org/docs/started/kubeflow-overview/ 顾名思义，Kubeflow应该部署在Kubernetes上，既然你是通过Rancher的平台阅读到这篇文章，那么你大概率已经在某个地方部署了Kubernetes集群。 值得注意的是，Kubeflow中的“flow”并不是表示Tensorflow。Kubeflow也能够与PyTorch一起使用

Argo是一个开源原生容器工作流引擎用于在Kubernetes上开发和运行应用程序。Argo Workflow流程引擎，可以编排容器流程来执行业务逻辑，在20年4月8日进入CNCF孵化器组。 而KubeFlow的Pipeline子项目，由Google开源，其全面依赖Argo作为底层实现，并增强持久层来补充流程管理能力，同时通过Python-SDK来简化流程的编写。 一. Argo流程引擎 Argo的步骤间可以传递信息，即下一步（容器）可以获取上一步（容器）的结果。结果传递有2种： 1. 文件：上一步容器新生成的文件，会直接出现在下一步容器里面。 2. 信息：上一步的执行结果信息（如某文件内容），下一步也可以拿到。 下面我们就来解读一下，Argo怎么实现“信息”在容器间的传递的，以及它和其他的流程引擎实现传递的区别。 1.1文件怎么从上一个容器跑到下一个容器里的？ Argo流程，可以指定2个步骤之间，传递结果文件（Artifact）。即假设流程为：A->B，那么A容器跑完，B容器可以取得上一个容器的输出文件。 如下：A容器生成一个 /tmp/hello_world.txt 文件，Argo将这个文件，放到了B容器里面，并重命名为 /tmp/message文件。 注意：流程上的每个步骤，都对应执行一个容器。 在A跑完后容器就退出了，然后才跑的B（这时候已经没有A容器在运行了）。

Kubeflow（ https://www.kubeflow.org/docs ）支持 Microk8s 部署（目前仅支持1.15.9以下版本）， Microk8s 是一个集成化的容器管理平台，与Kubernetes完全兼容，主要面向工作站、边缘计算和IoT等领域建立容器计算平台。 在官方版Kubernetes部署，参考 https://www.kubeflow.org/docs/started/k8s/kfctl-k8s-istio/ 。 KubeFlow进展研究（v0.7.1，2020年02月） Kubernetes集群的NVIDIA设备支持插件 Kubernetes-管理和调度GPUs资源 拉取镜像 原始的kubernetes镜像文件在gcr上，不能直接下载。我给镜像到了阿里云的杭州机房的容器仓库里，拉取还是比较快的。 echo "" echo "==========================================================" echo "Pull Kubernetes v1.15.9 Images from aliyuncs.com ......" echo "==========================================================" echo "" MY_REGISTRY=registry