听闻 kubernetes，快速了解一番

 

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

 

一.名称趣闻

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

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

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

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

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

 

 

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

“”“

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

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

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

”“”

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

   

  

传统的应用部署方式是经过插件或脚原本安装应用。这样作的缺点是应用的运行、配置、管理、全部生存周期将与当前操做系统绑定，这样作并不利于应用的升级更新/回滚等操做，固然也能够经过建立虚拟机的方式来实现某些功能，可是虚拟机很是重，并不利于可移植性。

新的方式是经过部署容器方式实现，每一个容器之间互相隔离，每一个容器有本身的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，因为容器与底层设施、机器文件系统解耦的，因此它能在不一样云、不一样版本操做系统间进行迁移。

容器占用资源少、部署快，每一个应用能够被打包成一个容器镜像，每一个应用与容器间成一对一关系也使容器有更大优点，使用容器能够在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 训练任务的效果。

 

 

  

 

 4、继续了解一下 

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 a mirror 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