杭州是一座极有包容性的城市，古韵清雅的街道景点随处可见，现代建筑群设计感十足，传统底蕴与现代科技被这座古城兼容并蓄，***融合。HDG华为开发者汇，就将杭州作为第四站，5位讲师***揭秘华为的CloudOpera、PaaS、融合视频3个生态圈，技术干货无私分享，听众疑问现场解答，思想的小火花一直在碰撞，参会的开发者大呼过瘾。
华为PaaS开发部高级工程师钟成对黄玉奇的发言也做了补充。他表示，华为***次尝试去构筑PaaS生态圈，希望能有更多的开发者关注这个平台。在钟成的演讲中，他主要与众开发者探讨了围绕Kubernetes的核心设计实现的多个技术细节，如怎么落地、在网络和存储环节如何操作、华为针对做哪些内容做了改动。社区应用的亲和性和反亲和性这些内容都是***对外披露。
现场实录如下：
我废话也不多说，直接开始讲了，我也没有什么特别可介绍的，我叫钟成，也是华为的，2012实验室的。
刚才黄玉奇已经把Kubernetes主要的背景都介绍了，它有什么够能或者怎么做，我这里稍微再展开一些，讲一些关于它底层设计的事。从大的方向来讲，k8s这个东西是应运而生的，它出现在现在这个时代是因为很多很多企业发现自己有很多计算机，有很多集群在机房里面，但是并没有非常好的手段管理它。传统的软件开发是一种单体式的开发，这些软件力度非常粗，比较大，而且要的东西比较长。换成现在这个时代会变成一种互联网式的开发，就是我会把我的过多软件都微服务化，把这个逻辑打的比较碎，打的比较散，发布的周期可以变短。以前可能是做一个软件，做一个系统，你要做一两年。现在一个功能可能一天或者一周就会生成一次，这方面就会有一些优点和缺点，这里都会讲，就不详细说了。
这个是国外的一个组织对PaaS的定义，主要是完成这么几个功能，一个是资源获取自动化，语言跟框架的自动化，以及运维管理的自动化。从解决集群管理这个角度来说，业界是有好几个方案，对于集群管理来说主要就是调度器的设计，当你把这个下完之后，你怎么决定这个应用到底跑在这个集群的什么地方。这里面列了有五种比较典型的方案，***种方案就是所谓的单体调度器的方案，就是我在这个系统中有一个调度器，由它来决定我这个应用部署到什么地方。这种方案像目前为止Kubernetes就在采用这种方案。
第二种方案是我去采用两层式的调度框架，下面这一层我只管资源，管到资源之后往上去报。比如说当上面请求资源的时候，我会给它挑出来往上报，上面的几个东西去挑，上面的几个调度器去选。如果上面的调度器觉得这台机器合适，那就拿去用。这就是myDOS的一个思路，myDOS就是Kubernetes。
第三个则是一个共享状态的调度方案，这个方案是我把所有集群的状态全部都同步到各个调度器里面去，由各个调度器进行决策，决策完了之后我往下试图进行部署。由于上面我看到的这些东西都是一样的，你***合下来的就需要有一个冲突解决，避免多个角度器之间互相打架，这也是一种方案。
还有一种方案是所谓的分布式调度，这种分布式调度我没有一个中央的调度器，只是我在中间任何一点都可以调度一些东西，我任何一台机器上都可以决定我是不是要接受这个应用，是不是要跑这个服务。这个调度其看起来可能比较散，是它其实是很有用的。现在在亚马逊的(03：57)里面就采用这种调度方案，对于非常短的一个任务，它的本身生命周期只有三四秒，如果你再通过一个比较复杂的调度器，花个十秒钟去调度的话，就比较得不偿失了。
第五种是一种混合式的方案，我把***种跟第四种混合在一起。
这个是我后面列的表，各个系统调度方案的对应表。包括它的一些调度的力度，多调度器，以及重调度的机器。
这个是k8s的一些优势，已经讲过。然后讲一下k8s的一些设计理念，它是一个全功能的，该了网络、服务发现、负载均衡和资源管理这些东西。你可以认为它是一个集成商的操作系统，有了这个操作系统以后，用心就不用操心这些底层的应用到底怎么被调度，怎么被运行，你只要向它提交任务就可以了。这个我觉得是k8s比较大的思路，包括网络，包括下面的这些资源调度，全部都是它进行管理的。而且它没有任何绑定，可以支持多种IaaS提供商。
这个我也不怎么讲了，这里有一个简单的动画，当你创建一个IS的时候会选择一个节点，然后把它布起来。如果这个节点上的容器或者(06：21)死掉的话，会它进行迁移，迁移到另外一台机器上面去。
这个是k8s的网络模型，这里稍微复杂一点，但是也是可以看得出来。当我在Pods部署了一组应用之后，我怎么从外部去访问它。我会定义一个Frontend Service这么一个东西，这个Service会对应下面的这些容器。这里有三个容器，这三个容器可以进行访问。第二个Service则是一个Redis Service，这个Service是给内部使用的，不是对外使用的。内部可能又有三个容器Pods的实例进行互相之间的访问。
目前k8s的网络访问方式有四种，一个是ClusterIP，就是我在集群内部定义一个跟我现在网站完全不一样的IP，这个IP只有在内部可以访问，它是通过IP(07：31)，你可以认为它造出一个IP，这个IP内部会进行合适的路由。第二个是Nodport，就是说我在集群的每个物理机上，每个部署的节点上面我去开一个端口，这个端口是由我的k8s的(07：44)进行管理，当你外部有流量访问这个节点上的端口的时候，会把这个节点上的流量进行转发，转发到运营的Pods上面去，这是第二种网络方式。第三种是我结合Dodeport的这种功能，我在上面再放一层loadBalancer，类似于像ELB，我通过这个ELB访问所有节点上的某个具体的端口，再去访问具体的Service。
接下来我会谈一下k8s的一些核心机制，这个会稍微偏向于代码一些。这张大家在上面也看到过，就是list-watch目的。前面大黄那边有一张图，就是k8s是一个典型的中心式的架构，所有的数据都是存在中心的API Service上面，API Service后面存了ETCD。这个架构在分布式集群里面是比较少见的，一般的分布式集群的做法是什么呢，我会写很多个进程在很多机器上面，我这些进程之间互相通过消息队列。连接完了之后，A进程做一件事情，做完之后把这个结果扔到队列里面去，然后用B进程进行这个操作，***再到C进程。你可以认为是一环扣一环，是消息队列的模式。但是Kubernetes的做法有点不一样，它的核心思想是我把所有的数据都放到ETCD里面去，由一个强的分布式数据库来进行存储，保证这个数据的强一致性，这是***个。
第二个我这些组建之间互相怎么通信呢?我通过中心的API Service进行通信。这个通信方式和一般的生产者、消费者也不大一样，前面我讲的是生产者、消费者模型，就是A生产，B消费。A处理了这个消息之后，我把它存到数据库里面去，就是下面的ETCD，ETCD会通知所有关注这个消息的人，把这个消息发给他，让这些人去处理。我们可以从这里面看到，当我从U客户端创建一个pods之后，可能是创建一个Replicaset之后，它就会收到Replicaset创建的消息，然后它就会再去创建一个pods，你创建这个pods之后，这些pod其实是没有被调度的。这时候由于一些变化，就会知道这些pods没有调度，对它进行处理，处理完之后去改变pod的状态，后面再这样分拉下去。这种方式list-watch跟那个不是很一样，理论上这个数据面比较广，如果是消息队列的话，A生产什么B就必须得消费什么。但是list-watch的方式是，我所有的客户端都可以关心自己想关心的东西，我可以通过watch这种方式去找到自己关心的那一部分，我可以关心node或者关心pods，我有选择权，所有的客户端都有选择权。
这里会稍微涉及到一些代码，大家看代码有问题吗，简单讲一点。这个代码也很简单，我在客户端就是起了一个函数，这个函数就是给它提供一组，你可以认为这就是一个http发起请求的一个函数。当你收到这个apiService这边发生变化的事件之后，就会调度你这里的三个函数，就是我发生这个事件是增加事件，还是更新事件，还是删除事件。也就是说当我发起list-watch之后，apiService会不停的把事件发过来，这是在同一条http连接上面，它会不停的把事件发过来。发过来之后，我Client不需要捕捉每一条事件，我只要把我的处理函数挂在这个钩子上面，这个就是它的一个框架，挂在这个钩子上面，当有新的事件过来之后，我这里会做相应的处理。同时我会在底层保存一份数据的全样数据的副本。这个是客户端的代码。
服务端的机制也是比较类似，我会在底层也存储一个store，当有http数据过来的时候，它会在本地保存一个滑动窗口，类似于CCD那个滑动窗口，每次事件发生了，就会给每个Client做一个相应通知。
前面一个过程就是整个k8s list-watch的一个机制，这个我认为是它跟传统分布式集群软件***的区别，就是它底层的通信机制不一样。后面则是一些具体调度器的机制，k8s的调度器我这里大致的讲了一下当你有一个pods要被调度的时候它会怎么做。它***步就会辨认这个集群中所有的节点，先去找哪些节点是不是合适。合适的意思就是说它的资源足不足够，能不能够有足够的网络，足够的带宽，先把我实在没有办法布的机器都过滤掉。第二步则是进行打分，如果我有一千台机器，里面有一百台我这个应用都可以布，我***给这一百个中间选一个。我怎么选呢?就是我给这一百个节点进行打分。打分的依据包括了一些亲和性或者反亲和性的算法，也包括一些资源算法。也就是说k8s现在调度器的机制是先进行过滤，然后进行排序打分的模式。
这个就是过滤跟排序的一些算法，这些算法其实都是千差变化的，就是说你要想做的话，也可以实现一个k8s的调度器。就是你可以自己中间插入一些函数，我想检查哪些端口，或者有些什么条件之类的。其实很多业务逻辑都是写在这个地方的，就是你可以自己去选择这个集群怎么进行部署。
这个就是讲高可靠，这个就是那个社区的方案，接上面的那个问题，就是k8s怎么实现自己的高可靠。它的想法比较简单，就是我把apiService分成多份，每一份都可以进行独立的访问。前面会挂一个为load balancer，就是我所有的工作节点都经过这个load balancer来访问apiService。底层的ETCD，自身采用(14：56)的协议进行数据同步。就是你的APIService从本质上来说是无状态的，而调度器和控制器目前还没有办法做到真正的多调度，或者是多控制。这个也是受制于前面的list-watch的机制，因为它本质上是所有的调度器或者是资源管理器得到的这个消费者数据是一样的，所以目前来说暂时还没有能够进行拆分。最近我在社区里面跟ETCD的开发者进行讨论，我们能不能改善这个机制，让我们这个集群把所有真正的调度和控制全部可以多副本。现在只能通过分布式锁，我是有单调度器和单控制器，就是每种类型的控制器只能有一个。
后面过一下社区的方向，这方面联邦我就不讲了，前面大黄讲过了，这是联邦的一个创建过程，这个也不讲了。应用亲和和反亲和，大家知道这个意思就可以了，这是一个需求，这个有好几个层级。包括是集群联邦层级，包括集群内部的层级，其实都会有。
这里讲了一个我对不同pods进行亲和和反亲和，这里是一些具体的案例，这个也不展开了，回头可以具体去看。
这个是我们后面会投入的一些东西，华为这边会做，也是我们在社区里面会做的，主要是集群的规模和性能，还有调度和重调度，以及集群联邦，主要是三大块。
后面我也做一个小小的广告，左边的是我们的微信号，后面是一个微信群，华为的微信群，大家可以在里面聊聊天，这个群是长期开设的。
