听闻 kubernetes，快速了解一番

 

看到 各位 大厂都在用这个，  而本人最多是用yarn 做些ML的事情，   赶快了解一下， 先扫盲记录一下。

 

一.名称趣闻

kubernetes缩写为k8s， 阿哈 ，原来是：k8s，意思就是k后面跳过8个字母后到s，就变成了k8s。  kubernetes /kubə'netis/，重音在第三个音节，读音：库伯耐踢死

不免说这些硅谷的人呀，起名有一套！

它是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
 

 

二、为啥会出现这个东西？

“”“

  在建设分布式训练平台的过程中，我们和机器学习的各个业务方，包括搜索推荐、图像算法、交易风控反作弊等，进行了深入沟通。

   那么，对算法工程师是如何的？ 从调查中发现，算法业务方往往专注于模型和调参，而工程领域是他们相对薄弱的一个环节。

   建设一个强大的分布式平台，整合各个资源池，提供统一的机器学习框架，将能大大加快训练速度，提升效率，带来更多的可能性，此外还有助于提升资源利用率。

”“”

   方便人的工具才是好东西！

   

  

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。
新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。
 
 
说的是不是太书面了 ？ 看看其他人如何说的:

痛点一：对算力的需求问题

  1. 公司目前的 Yarn 不支持 GPU 资源管理，虽然近期版本已支持该特性，但存在稳定性风险。

  2. 缺乏资源隔离和限制，同节点的任务容易出现资源冲突。

  3. 监控信息不完善。在发生资源抢占时，往往无法定位根本原因。

  4. 缺少弹性能力，目前资源池是静态的，如果能借助公有云的弹性能力，在业务高峰期提供更大的算力，将能更快的满足业务需求。

痛点二：人肉管理的成本很高

        人肉化的管理主要包含了部署和训练任务管理两大方面，越多的人肉管理就是越多的成本呀。

        部署：

             不同的训练任务对 Python 的版本和依赖完全不同，比如有些模型使用 Python 2.7，有些使用 Python 3.3，有些使用 TensorFlow 1.8，有些使用 TensorFlow 1.11 等等，非常容易出现依赖包冲突的问题。虽然沙箱能在一定程度上解决这问题，但是也带来了额外的管理负担。还有， 不同 GPU 机型依赖的 Nvidia 驱动也不同，较新的卡，比如 V100 所依赖的版本更高。人肉部署还需要管理和维护多个不同的驱动版本。  等等

       管理：

            启动训练任务时，  需要手动查看 / 评估资源的剩余可用情况，手动指定 PS 和 Worker 的数量，管理配置并进行服务发现。这些都给业务方带来了很大的负担。而，Kubernetes 提供了生命周期管理的 API，用户基于 API 即可一键式完成训练任务的增删改查，避免人工 ssh 的各种繁琐操作，可以大幅提升用户体验和效率。

 

 

痛点三：监控的缺失

         监控也是分布式训练重要的一环，它是性能调优的重要依据。

        例如如下的描述：    

“”“”

比如在 PS-Worker 的训练框架下，我们需要为每个 PS/Worker 配置合适的 GPU/CPU/Memory，并设置合适的 PS 和 Worker 数量。如果某个参数配置不当，往往容易造成性能瓶颈，影响整体资源的利用率。比如当 PS 的网络很大时，我们需要增加 PS 节点，并对大参数进行 partition；当 worker CPU 负载过高时，我们应该增加 Worker 的核数。

早期版本的 Hadoop 和 Yarn 并不支持 GPU 的资源可视化监控，而 Kubernetes 已拥有非常成熟监控方案 Prometheus，它能周期采集 CPU，内存，网络和 GPU 的监控数据，即每个 PS/Worker 的资源使用率都能得到详细的展示，为优化资源配置提供了依据。事实上，我们也是通过监控信息为不同的训练任务分配合适的资源配置，使得在训练速度和整体的吞吐率上达到一个较好的效果。

“”

 

痛点四：资源隔离较弱

        早期的机器学习平台基于 Yarn 的 Angel 和 XLearning，由于 Yarn 缺乏对实例之间的资源隔离，我们在内存，网络，磁盘等均遇到不同程度的问题。

        由于 Yarn 没有对任务的内存进行隔离，所以，业务方常常因对内存资源估计不准而导致 worker 的进程 OOM。由于所有的进程都共用宿主机的 IP，很容易造成端口冲突，此外磁盘 IO 和网络 IO 也很容易被打爆。

 

 三. kubernetes作为机器学习基础平台

        Kubeflow 旨在支持多种机器学习框架运行在 Kubernetes 之上，比如 Tensorflow, Pytorch, Caffe 等常见框架。它包含了 operator、pipeline、超参数调优、serving 等诸多模块。它通过提供对应的 operator，基于 Kubernetes 的 Pod/headless Service 等基础资源为框架提供与之相配的更高层次的资源。比如 tf-operator 为 Tensorflow 提供了 job 维度的生命周期管理能力，以满足 Tensorflow 分布式训练的资源和拓扑需求，达到了一键式部署 Tensorflow 训练任务的效果。

 

 

  

 

 四、继续了解一下 

Kubernetes 组件

  • 1Master 组件
    • 1.1kube-apiserver
    • 1.2ETCD
    • 1.3kube-controller-manager
    • 1.4cloud-controller-manager
    • 1.5kube-scheduler
    • 1.6插件 addons
    • 1.6.1DNS
    • 1.6.2用户界面
    • 1.6.3容器资源监测
    • 1.6.4Cluster-level Logging
  • 2节点（Node）组件
    • 2.1kubelet
    • 2.2kube-proxy
    • 2.3docker
    • 2.4RKT
    • 2.5supervisord
    • 2.6fluentd

 

Master 组件

Master组件提供集群的管理控制中心。
Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器。请参考构建高可用群集以来构建multi-master-VM。
kube-apiserver
kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。请参阅构建高可用群集。
ETCD
etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划。
kube-controller-manager
kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。
这些控制器包括：
  • 节点（Node）控制器。
  • 副本（Replication）控制器：负责维护系统中每个副本中的pod。
  • 端点（Endpoints）控制器：填充Endpoints对象（即连接Services&Pods）。
  • Service Account和Token控制器：为新的Namespace创建默认帐户访问API Token。
cloud-controller-manager
云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，目前还是Alpha的功能。
云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。可以通过将--cloud-providerflag设置为external启动kube-controller-manager ，来禁用控制器循环。
cloud-controller-manager 具体功能：
  • 节点（Node）控制器
  • 路由（Route）控制器
  • Service控制器
  • 卷（Volume）控制器
kube-scheduler
kube-scheduler监视新创建没有分配到Node的Pod，为Pod选择一个Node。
插件 addons
插件（addon）是实现集群pod和Services功能的。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。
DNS
虽然不严格要求使用插件，但Kubernetes集群都应该具有集群 DNS。
群集 DNS是一个DNS服务器，能够为 Kubernetes services提供 DNS记录。
由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。
用户界面
kube-ui提供集群状态基础信息查看。
容器资源监测
容器资源监控提供一个UI浏览监控数据。
Cluster-level Logging
Cluster-level logging，负责保存容器日志，搜索/查看日志。

节点（Node）组件

节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。
kubelet
kubelet是主要的节点代理，它会监视已分配给节点的pod，具体功能：
  • 安装Pod所需的volume。
  • 下载Pod的Secrets。
  • Pod中运行的 docker（或experimentally，rkt）容器。
  • 定期执行容器健康检查。
  • Reports the status of the pod back to the rest of the system, by creating amirror podif necessary.
  • Reports the status of the node back to the rest of the system.
kube-proxy
kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。
docker
docker用于运行容器。
RKT
rkt运行容器，作为docker工具的替代方案。
supervisord
supervisord是一个轻量级的监控系统，用于保障kubelet和docker运行。
fluentd
fluentd是一个守护进程，可提供cluster-level logging.。

 

 ha , 好复杂， 那么 如何将其玩转起来， 额， 这比较多了， 还是看这位老兄的吧， 写的挺多的，

   http://baijiahao.baidu.com/s?id=1602795888204860650&wfr=spider&for=pc

 

 

 参考：

https://mp.weixin.qq.com/s/cQNZnswSiKa8O0SkAiuRkQ

 

posted @ 2019-01-24 10:52  dy9776  阅读(724)  评论(0)  编辑  收藏  举报