大家好，我叫张鑫，来自才云科技。我们创始团队从卡耐基梅隆大学一直到谷歌，谷歌其实从2001年就开始使用容器，我当时和我们CTO在集群管理的团队，通过容器集群这样一个系统，去管理当时80多个数据中心，超过一百万台服务器的体量。
这个调研数据是美国做容器监控公司针对目前容器常用的编排工具做的一个使用调研，我们看到为什么今天这么多的Kubernetes的演讲，也是有它的必然原因在这里面。从传统IAAS到PAAS层划分，我们看到基于底层的硬件软件水电煤的服务，Kubernetes提供了对于微服务、业务等进行支持的一整套功能点。
今天跟大家分享三块内容，第一块就是Kubernetes跟谷歌内部管理有什么不同。第二块Kubernetes作为面对现代微服务框架在传统行业怎么落地。第三块我们一直说容器更多支持无状态的应用，这块非常不直观的，容器其实也可以很好支持数据的应用。
第一个模块当时是在谷歌做集群管理系统整个的生态。其中黄色的是berg，这是Kubernetes的前身，对其进行管理。真的在集群管理体系里面，其实集群管理远远大于容器管理，除了要管理容器以外，我们还有很多怎么样做机器层面管理，怎么做安全方面的把控?怎么保证我业务系统的SIA，有很多技术模块在我们容器之外的，首先容器管理不等同于集群管理的。
这里举一个具体例子，以当时在谷歌上线一个新业务系统为例，当我们硬件从QA投入我这个业务系统以后，在集成管理内部有点像CNDB，有一个机器的数据库，不光存放我硬件信息，还存放我机器未来承载什么任务，装一些mysql节点还是存储节点。我存到数据库在集群还有一个非常重要的组件，就是工作流管理，工作流管理每隔15分钟察看这个数据库是不是有新表象参加，当有新信息来了，根据表现记录我这个机器装什么软件，触发其他模块API调用，对这个机器进行反映。
Kubernetes对上层应用进行生命周期生老病死的管理，我们大型系统里面也会出现很多问题，这些问题谁管理，我们有一个节点医生的模块。每个有全局节点医生的设置，这两个系统负责管理机器或者硬件层面的问题，当发现问题以后，把这个问题不是直接修复，还是把一个问题添加到机器数据库里，这时候工作流管理系统每15分钟去看这个数据库，当发现新问题以后会触发修复的流程。当时做到了60%所谓硬件的故障，都是通过这种软件的方法修复，这个可能不是那么直观，觉得硬件坏了就坏了，怎么可能软件修复，发现硬件故障表彰由驱动层面软得原因造成的，当体量达到百万服务器以后，当我们60%的情况都不需要人工的时候就是巨大效率的提升。
开发者这端我提一下，我们所有应用在berg，什么东西量大以后变成大问题，当我这么大的代码量，我怎么短时间完成测试，当时用了一套系统，这套系统首先自动识别出我们每一个可能触发哪些测试级，其他大量的测试级无关，我就不会测试，同时测试的borgcli本身也运行在berg平台上，从开发端到整个管理的全貌。容器管理在整个管理体系里面是其中一环，并不是全部。
这些东西都是谷歌内部所有的，作为我们外部企业怎么尽量补全这样一些功能，今天PPT我提一些小工具。第一个我们镜像仓库的管理，作为容器来讲，我首先第一个要有镜像仓库，镜像仓库由中国研究院主打一个非常好的项目叫做Harbor，可以支持多个镜像之间复制，去做审计与健全这样的工作。我们才云自己对它进行了功能上的扩充，包括对镜像进行安全扫描，实时的扫描镜像中的漏洞，包括对镜像可以添加标签，去实现更灵活的管理，以及支持多种的存储方案，这些都是我们做的工作。
提到发布，我们发布一直说做CICD，大家有一个体会，我们把一个传统应用切割成微服务架构以后，其实发布反而一定程度上更复杂，我原来发布一个二进制，现在我要拆分成很多模块，如果后端更新话，前端也要更新，我们去年联合发布了这样一个系统，叫做Seco，支持微服务之间的拓扑依赖关系支持发布，发布过程当中也会实时进行镜像仓库扫描，大家看到截屏中的文字就是扫描出来镜像的漏洞。
和发布相关就是另外一个概念就是灰度发布，我一个新版本的上线，我不希望新版本2.0一下替换1.0，对于基础设计型的软件我们按照一个数据中心一个数据中心更新。对于面向用户的产品，谷歌的购物，它的搜索等等，我们按照流量，先把15%的流量引到我新版本里面，基于Kubernetes我们怎么样也做到灰度发布系统，其实也是可以利用它里面标签的特性，以及它对服务的构建特性来实现一个灰度发布，时间关系我这里细节不说了。
我们用过Kubernetes的一线工程师，我们都知道，往KPS我非常容易的部署这样一个服务，我构建一整套复杂的业务系统的时候，类似于Docker里面一样，我如何快速构建一个复杂的系统，后来Kubernetes有一个开源解决方案，叫做Helm，我们推出一个辅助的工具叫做Heim-Registry，快速推出模板，把模板放到云应用商店里面，提供共享，以及快速构建。
我们监控报警系统，如果我们自己用过Kubernetes的时候话会知道，Kubernetes管理跑在它上面的应用，对里面应用进行监控和管理，但是Kubernetes自身也是非常复杂的软件系统，利用Kubernetes也知道，Kubernetes也要实时监控管理它的系统，在这个世界里面我们也需要有一个系统管理和维护Kubernetes自身。存储替换成OPDMDB，把更多K8S系统的指标曝露出来，实现不同层级的报警策略。
刚才讲完了Kubernetes跟谷歌的区别，以及我们演化和推进，怎么用一个新技术用到相对老的行业里面，从我们落地经验来看，其实落地遇到不少的挑战，怎么做离线部署，怎么与私有云IAAS对接，对有状态、单体应用的无缝迁移。线上系统升级，多租户管理与安全把控。我们有很多的open Stack的用户，我们怎么保证不掉线的运营，线上升级系统、多租户的管理与安全把控，都是Kubernetes在传统行业中遇到的问题，也是我们实践中需要解决的问题。
第一个我们服务对外的曝露，这部分内容有点专业，我们都知道Kubernetes里面有一个服务的概念，集群内部的服务之间可以很轻便访问，当我把一个服务曝露给集群以外的事件，我把京东云曝露在外面，外部怎么访问我的容器，我把对应服务对应起一个端口，在集群所有节点上，我web访问这个服务，要记住这三万多的端口把服务打过来，第一个端口我们要做记忆，其次我们很难做负载均衡。这里头有比较简单的解决方案，我们还是先把服务在每台机器上曝露出三万多的端口，为了避免用户每次要把流量绑定在一台服务器的三万端口，我们可以在外面设一个负载均衡器，可以解决一部分的问题，同时还是解决不了我怎么从七层做负载均衡，我根据用户ID等去做，我现在需要在机器上开哪些端口，只不过没有曝露给用户。
在Kubernetes首先解决七层的负载均衡，这个黑的我主要对系统做简单的配置就可以把这个东西用起来，这个解决七层负载均衡的问题。没有解决我这个ingress系统部署在哪台机器上，会不会存在单点失效的问题。
我们的解决方案本质上把Ingress做成一种资源，可调度的资源。我们一个容器是一个可以被调动的资源，我们把Ingress也做成类似的调度资源，也实现了专门对Ingress的调动器，我在一个机器里面自动部署一些Ingress的，同时Ingress不同之间，通过(英文)的方式，服务不同的应用。内容比较多，今天只能蜻蜓点水的把意思传达一下。我现在快速跳到下面一个主题，就是日志。
Docker对于日志有自己一套管理办法，但是落地传统企业过程当中有两个问题，第一个很多已有的应用采用写文件的方式，我们是不是为了上这个系统我应用都要重写，另外我写不同文件还有额外的好处，我通过日志类型写到不同的文件里面，所以我很难实现细粒度的把控，用户有时候希望这类日志写到一个名字，A里、另外一个文件写到B里，还是遇到一些需求，我们更改了Kubernetes的组件，使得Kubernetes或者Docker其实可以把存在本地的文件收集起来，发送到我们用的ELK里面。第一种方法通过(英文)的方式，每一个块里面除了我的(英文)应用，我还部署(英文)，这个监听我文件名和路径，收集起来发送到(英文)里面。另外一种模式我们直接对EPI进行扩充，支持了一个东西，当我们部署的时候，我们写YML文件可以指明这个POD写在这个文件下你可以收集。经过这样一些修改，我们成功落地在一些相对来说比较传统的企业。
第一个全国大的连锁酒店之一，通过我们刚才做的适配最小化他们需要对应用所做的修改，上线至今目前运行到了七千多个容器，跑在数百台的主机上。另外一个例子，中国大卡的联合组织，也是非常传统的架构，底层用虚拟化来做的，上面通过我们采用的这样一些方法，使得它可以非常轻便适配到传统的行业。
第三大块我们一直说容器和数据有状态是天生的天敌，虽然我们可以挂载磁盘，用网络存储，不是容器的先天优势，我们反而利用容器更好的做大数据的应用。
Docker和Kubernetes落地一个企业，大家最直观的感觉，它解决我计算的问题，可以让我计算更加轻便，可以让我更高效去进行很多的计算。对于数据支持非常少，已有数据怎么利用更加快速的计算挖掘这个数据的价值，尤其是现阶段我们数据变动体量越来越大，还有很多非结构化的数据，这是容器本身技术，或者我们看到产品很难解决的问题。当然我们也知道最近从去年开始比较流行的就是我们AI，或者我们的深度学习，深度学习是一个很好实现AI的方法。它相比于传统的数据分析的方案更能提取一些复杂的特征，更能分析一些非结构化的数据，同时从精度上来讲对于传统的算法我可能很容易达到一个天花板，对于深度学习，随着我数据量增加，我精度往往可以被持续的提升的，这是深度学习。
在深度学习这个领域里面由谷歌开源的一个方案叫做Tensorflow，社区活跃度来讲跟Kubernetes非常相比，远远超过其他设计方案，获得了大社区的热度。Tensorflow可能大部分人听过，Tensorflow有很大的优势，它大问题就是计算量，以做一个图像分类为例，这是IMGENET的图像分类，我们深度学习IMGENET提供很好方法，另外就是一个数据平台，我们怎么解决这个问题，利用容器和Kubernetes，利用他们分布式大规模计算的特性，实现极速深度学习的体验。除了跑搜索、广告、购物等等以外，其他业务和大数据业务都混跑在这个容器之上。
我们核心的解决方案把Tensorflow的算法容器化，同时跟Kubernetes做分布式的调度，我增加机器实现我的吞吐量。这是我们简单提供的解决方案和原生的Tensorflow相比很多的优势。当实现这个功能以后在同样的一个Kubernetes集群里面，不光我们运行A服务应用，可以应用我们CI、CD的功能，可以在我同个机器上进行深度学习。
目前在安防、金融等等领域实现自动从摄像头监控有着火，在电商领域实现了穿衣风格的搭配。最后例子就是用深度学习做一个实际预测取得落地的效果。有问题我们可以随时交流。谢谢。
热门专题
