杭州是一座极有包容性的城市，古韵清雅的街道景点随处可见，现代建筑群设计感十足，传统底蕴与现代科技被这座古城兼容并蓄，***融合。HDG华为开发者汇，就将杭州作为第四站，5位讲师***揭秘华为的CloudOpera、PaaS、融合视频3个生态圈，技术干货无私分享，听众疑问现场解答，思想的小火花一直在碰撞，参会的开发者大呼过瘾。
“一谈到容器，很多友谊的小船说翻就翻了。”华为PaaS开发部高级工程师黄玉奇幽默地开了场。他着重向开发者介绍了Kubernetes在混合云、大规模场景下的集群管理诉求。
现场实录如下：
这么热的天，大家能赶到华为的开发者会，特别感谢大家。同时也感谢活动各位组织的伙伴们。我是华为CCE的黄玉奇，现在主要做华为CCE的设计开发的工作，同时也是Kubernetes社区小小的贡献。华为CCE的全称就是云、容器、引擎，简单给大家介绍一下。今天跟大家一起分享的题目是华为CCE在混合云大规模场景下的一个技术探索。
分享主要从四块说起，首先跟大家温习一下什么是容器，什么是容器服务。第二个我们看一下现在有一个开源容器的明星，Kubernetes一些经典的应用模型，包括它的架构。第三块是我们CEE在华为IT系统里面的实践，以及面临的一些挑战。***会跟大家分享一下我们在Kubernetes社区里面贡献的集群联邦的技术细节。
大家看这幅图有点蒙了，现在在我们小圈子里有一句话说，一言不合就要讲容器，讲容器的时候就会摆上一些大大的集装箱，我不知道为什么。在60年代的之前全球的运输主要以散货的运输方式来进行的，大部分的时间都集中在装载、卸载，再装载、再卸载上面。有人就会问了，我们为什么不能把这些货物都集中放到一些大箱子里面，我们只来做这些箱子的运输。伴随着这个问题，集装箱技术就出现了，集装箱技术出现之后，大约节省了六分之一的人力和三分之一的运输时间。
这里我们就做了一个容器技术和集装箱的对比，为什么我们总喜欢把容器和集装箱放在一起比。***个它是一个内容无关性，集装箱的东西都有这个特征，内容无关性。我不管你这个箱子里放的什么物品，或者对我们容器技术来说我不管你放的什么负载或者什么应用。第二个就是硬件无关性，我的集装箱可以通过火车、卡车或者轮船来运输，当然我们的容器也可以跑在物理机、虚拟机、笔记本或者服务器当中。
***一个我想提的是它的效率问题，集装箱能解决我们运输的效率，容器它能解决我们应用的开发部署，包括运维的效率。
说到容器，我们不得不说容器里面的一个明星了，Docker，在我理解Docker并不是在它的技术上有多么的先进，而是说它给我们带来一个统一的认识，我们可以通过Docker镜像来实现应用的开发、部署、运维，最终它的这种极大的便利性，形成一个稳定的Docker生态，其实它最有价值的地方就是Docker生态。我们有一个问题就要说了，任何一个复杂的应用并不是以独立的Docker容器能够解决问题的，通常是一组，或者是一堆的Docker容器相互协同，才能完成某一个特定的完整的应用站。这里我不得不说一个容器服务，一个可用的容器服务都需要哪些要素呢?***个就是基础架构，我一个容器服务解决资源的编排，资源的管理，包括一些在外围的负载均衡，服务的注册发现，租户方面的能力。第二个就是监控运维的能力，就是我的应用在容器服务商要能够提供对容器应用，或者集群不同维度的状态的监控。此外还有一些日志的分析，应用的升级。***一个就是外围的支持，包括一些代码库，经销商库一些能力的支持。
当前不管在开源界，还是在国内外一些重大的IT厂商，都会有一些容器服务的产品，像开源的有Docker，在国内外有些大的IT厂商里面也有很多的容器的产品，华为CCE就是基于Kubernetes做的容器服务的产品。这里我重点想跟大家分享一下Kubernetes经典的模型和它的典型的架构。
Kubernetes其实是谷歌开源容器集群的环境系统，它构建在Docker的基础之上，主要是为容器化的应用提供了应用的部署，服务的发现，扩容缩容一整套的功能。下面我们看一下Kubernetes里面基本的概念，从这个图里面可以看到，节点上运行了Kubernetes大部分的控制面的主件，里面主要是KubernetesAPIserver、调度器，还有一些资源管理控制器。下面两个是它的slive节点，slive节点就是应用真正运行的地方。它上面运行了Kubernetes控制面的两个主件。在Kubernetes里面有一些应用的模型，这边我有列。***个就是pod，pod它对应的Kubernetes里面一个最小的部署单元，它其实就是一组容器的集合。第二个想介绍一下的是副本控制器，主要就是包括我在KPI集群里面有固定数目的在运行。第三个就是service，service后端真实pod访问的问题。还不得不提的是一个label的概念，因为在kps里面，各种资源之间的管理，或者它的观点和查询都是通过label来解决的。
我们来展开讲一下Kubernetes里面的几个基本概念，***个就是pod，大家听的最多的就是pod的概念，pod在KPI里面是最小的部署调度的单元，它是一组容器的组合，不是一个单独的容器。pod里面的容器它们共享这相同的网络运营空间、IP地址，包括数据卷，所以在这个pod里面多个容器可以相互的访问。这里就有一个问题了，pod需要手动上线吗，或者在pod生命周期里面谁来维护pod的生命周期。这里面对应了Kubernetes的另外一个概念，叫做副本控制器，副本控制器通过label或者一组pod做一些关联，它能维持在我的KPI集群里面一个固定数目的pod的运行。当我的pod的数量超过了我的副本控制器里面指定数量的时候，副本控制器就会揍掉一些，如果少的话，我就会重新再启动一些。此外它能够解决pod扩容和缩容的问题。这里面我要提到一下，创建一个IC的时候，我需要指定哪两个东西，***个就是pod的模板，相当于是一个pod的描述文件。第二个就是label，label主要就是解决我的副本控制器跟pod之间的管理关系。在讲副本控制器的时候我们也提到，pod会不断的被副本控制器重新启动，或者把它Q掉。也就是说我的pod在后端是不断变化的，是一个动态的。那么我们怎么解决pod，或者我某一个应用对用户访问的问题，因为我在后台是不断变化的，Kubernetes有一个service的概念。
service的引用它就为了解决我的用户对后端pod访问的透明化，我只需要知道我的service在哪里，由service来将这个流量导向我后面支持的pod。我们可以简单理解，它就是一个虚IP，做了一个LD。它可以把外部的流量进来之后，把这个流量按照一定的规则，对后台支持的pod做了一个简单的流量分发。当前KPI对service还是一个四层的LB。但是在Kubernetes在EDL版本，也引用了资源对象，主要是解决后端七层的LB的问题。在KPI集群里面我们这个服务，它的服务发现通过两种方式。Kubernetes里面自带了一个DNS的组建，解决了我们服务发现的问题。这是Kubernetes的三个很重要的概念，因为在我们后面讲述集群联邦的时候会用到这几个概念。
下面主要想给大家一起看一下Kubernetes基础的架构。前面我们说到了它是一个典型的(10：30)的结构，在节点上运行了很重要的一个组建，就是API的服务器，主要是对外提供服务，来供用户对资源进行增查改查，包括words的操作。它后端对接的是一个CD，做私有化存储。我还会有一些认证，授权的模块，然后最终的用户他的访问流量是通过ACPI进入到我的APiservice里面。第二个主要组建就是调度器，调度器解决的问题主要就是，根据一些调度策略，来决定我的pod真正的被部署到哪个node上，它里面的调度策略是可插拔的调度策略。这里面主要有一些亲和性，或者反亲和的调度算法。第三个重要的控件的组建是控制器管理器，这里面主要是针对Kubernetes每种资源所做的控制器，它能够相应Kubernetes里面的资源变化，因为每一个资源变化都对应了一个资源变化的事件，这个事件最终是由我的控制器管理器比别人的控制器去消费的，来做不同的动作。大概这里面的东西我给大家列举一下，有node的控制器，副本的控制器，等等。控制面的组件，主要是解决了容器的生命周期管理的问题，包括我容器的启动、创建、删除、更新这些东西。Kubernetes本身也提供一个restAPI服务，会将这些运维服务通过自身的restAPI，供外面的用户查询。当前主要的应用场景是Kubernetes提供一个restAPI，***将所有的运维数据做一个不同维度的聚合。第二个slive节点上的控制件组件是pods组件，顾名思义这个pods主要是给pod做一些流量分发，主要是结合我们前面提到的service的概念，来运行的，来开展工作的。这里是Kubernetes的基础架构，大家有点印象，因为我在后面讲到Kubernetes联邦集群的时候，可能会重复一下里面的一些概念。
我们可以看到Kubernetes会有很多线连到APIservice里面，这里面我要讲一下Kubernetes里面有一个list-watch的机制，它主要是解决Kubernetes里面异步通信的问题。这个list-watch还是基于ECD的Kubernetes的能力，通过APIservice做了一层封装，对外提供的。这里有一个简单的例子，用户创建一个应用之后，或者创建一个资源之后，会在APIservice里面有一个相应的资源，我就会有相应的资源，获取到资源的变化，可以做一些相应的动作处理。这里就不展开了。
第三块主要想讲讲CCE在基于Kubernetes这个开源的解决方案上，怎么来去实现在华为IT系统里面的技术挑战。华为的CCE主要还是以Kubernetes，或者docker，以核心技术构建，主要想打通原有的在IaaS、PaaS或者CaaS这个端到端打通的融合方案。我们的愿景是能够解决跨境应用的集中部署的管理，混合资源的编排，开发测试生产环境的一致性，再集成我们华为这么多年电信领域的中间件，或者把这个中间件做一些容器化的操作。
随着业务的开展，现在我们华为CCE上了各种各样的生产环境，我们也开始面临越来越多来自生产环境上的挑战。***个就是规模问题，这边有一个统计，2015年的统计数据，我们中间件云里面，以DC为单位，我们业务量是快速增长的趋势，这是一个规模的问题。第二个就是业务的频繁发布，现在我们很多传统业务的平台不支持快速的迭代，就是说我们业务上线效率特别的低，希望能够通过我们华为CCE，在基于容器基础上，能够解决他们业务频繁发布的问题。第三个就是冗余部署，我们希望能够解决一些同城双活、混合云、异地容灾这么一些问题。因为现在我们的应用是在VM下，希望通过容器来解决这个问题，提高我们资源利用率的问题。第三个就是容器化、微服务化的改造，这里是华为CCEKubernetes提供的基础的能力，容器化管理部署的能力。
面临的挑战我们也做了很多的技术探索，我们在华为公司内部也做了一些Kubernetes的性能提升，包括调度啊，各方面的性能提升的技术探索。今天想跟大家分享的是探索的一个方面，就是Kubernetes联邦集群的一个点。它主要能够解决一些什么问题呢?***个高可用，我们知道Kubernetes本身是一个单机性部署的，如果我们想解决在集群这个维度的单点故障的问题，就是在AZ级别，或者云提供商级别的这么一些单点的问题。第二个就是我希望能够安全集群的特性做一些应用调度，可能我希望我的应用被调度到一些云提供商上面，AWS上面。第三个就是集群间应用的自动迁移，就是当我某一个集群的容量溢出了，我希望能够把上面一些应用自动的迁移到其他的界面上面，用户不感知。第四个是混合云的部署，我们希望将能负载部署到不同的云服务提供商上面，能够做到一些自动迁移，或者业务量的自动的增加减少。第五个是为了解决当前Kubernetes面临的比较严峻的问题，Kubernetes的规模问题。我们也知道现在Kubernetes发布了1.3版本，对外宣称能支持到2000节点，但是2000节点在我们生产环境上，这个能力还是略微显得比较薄弱的。所以我们想通过联邦这么一个技术点，去解决Kubernetes本身的规模问题。
下面我们把Kubernetes联邦打开，给大家分享一下。这个是集群联邦的一个架构，大家看这个图可能觉得跟我们前面讲的Kubernetes本身的架构有些相似。我们这里也是附用了Kubernetes(18：45)的机制，实现了组建结藕的架构。其实这个架构我们发现它的控制面也包括一个联邦级别的APIservice，还是附用了ECD作它的私有化存储，能够对接第三方一些认证健全的功能。在功能面上我们还是有一个联邦级别的调度器，它来解决应用在不同集群之间的一个调度问题。当然它也支持亲和性、反亲和性这些基础的调度能力。第三个重要的组件是联邦级别的资源控制器、管理器，里面也包括了联邦级别的资源的控制器。现在联邦我们引入了三种资源。下面就是联邦管辖的Kubernetes的集群，原生的Kubernetes集群。对应到联邦的资源刚才也提到过，本身Kubernetes原生的集群在联邦维度对应的是Cluster的这么一种资源。这里大家先有一个印象，后面我们在联邦不同的应用场景下面会把这个图再给大家做一个展开。
***个就是联邦上的应用创建，这里可能会跟Kubernetes原生有一点点的区别，Kubernetes我们知道它最小的应用部署单元是pod，或者一组容器。它对我们联邦来讲，它的最小的部署单元是RS，或者一个RC，叫做一个副本控制器。应用部署之主要解决的是我这个RS在联邦层级调度的问题，它调度主要解决了一个RS拆分的问题，要根据我下面集群的负载能力，或者根据一些亲和结合策略，把这个RS做一些拆分。所以***步我的联邦使用者还是通过联邦暴露出来的API，它来提供一个创建应用的请求。首先我会把这个应用划到联邦的ECD里面。我有一个联邦的集群的控制器，会周期性的采集我联邦负载的数据，或者它的健康状态，然后供联邦的调度器做一些调度的决策。对应到调度器的行为，它会把RS的副本数按照集群的维度做一些拆分。我们这里的假定场景，我ClusterB的容量可能比A要大，我就会把应用的副本数拆成2A3，对应关系是2到ClusterA上面，3到ClusterB上面。最终还是由联邦的资源控制器调下面集群的应用创建的接口，把这个应用在各个集群里面创建出来。当然它还会负责应用状态周期性的查询，最终会通过APIservice向用户提供我这个应用状态的查询。
这里面就把调度器打开了一下，这个联邦调度器会感知下面各个子集群的变化，包括我各个子集群的容量、负载，供它自己生成一些调度策略。第二它要能够看到我当前应用里面，或者我的联邦维度有哪些应用没有被调度，通过过滤出字段检查我这些应用有哪些没有被调度，放到本地的调度的队列里面再调度。第三个就是根据***步获取到的每个集群的容量啊，负载的信息，生成它的调度策略，其实也就是对我这个应用的副本做一些拆分。***它会把这个调度结果写回到我的集群联邦的APIservice里面，供我的应用控制器去调下面子集群的接口，去创建它的应用。
在我的联邦调度器里面也有一些亲和性和反亲和的考虑，我希望我的应用能够部署到某些属性的集群里面，或者我的同一个应用不同实例，我希望在不同的集群里面做一些不同的部署，去解决我的一个高可靠的问题。
前面说的比较慢，后面说的快一些。这个主要是应用跟集群之间亲和和反亲和的调度，我通过跟不同集群打一些标签，决定我某些应用会部署到某个特定的集群上面。我这里面应用A的应用，包括了集群1和集群2标签的选择性，我应用A就会被拆分到集群1和集群2上面。应用B类似的会拆分到我的集群2到集群3上面。这是应用跟应用之间的亲和的调度，如果我的应用B和应用A之间有些依赖关系，我为了解决在不同集群间的网络消耗，会尽量铺到一个集群里面。这里面可以支持一些硬亲和和软性的亲和。
这个就是前面提到过的，主要是集群的控制器和副本的控制器，前面功能刚才也讲到过。***一个很关键的点，就是集群联邦下的服务发现，刚才我在前面讲到过Kubernetes服务主要是解决后端应用的访问问题，里面主要是解决联邦场景下的应用的访问问题，包括跨集群的访问。首先用户会创建一个服务，主要目的还是为了通过这个服务访问分布在不同的集群上的应用的访问问题。我的联邦的服务控制器会感知到这个服务的创建，会在下面各个子集群里面都会创建这么一个服务实例。这里会有一个默认的选项，包括我的每个集群里面会有一个负载均衡器跟大家做一下关联。这个服务控制器会在我各个子集群里面创建一种服务，我的应用流量会从一个全球的分布式路由这边过来，首先会做一层Kubernetes集群维度的流量分发，然后这个集群里面的LB会把这个流量再进一步的分发到我应用后端对应的真实的POD上面。
这个是现在Kubernetes社区1.3版本的集群联邦的功能展示，我稍微给大家介绍一下它的背景。我现在在GKE的四个区，我分别有四个集群，我希望通过集群联邦把这四个集群管理起来，并且能够在我这四个集群里面分别创建我联邦级别的服务，通过访问这个服务可以把我的流量按照一些流量分发的策略，分发到我不同的集群里面。***步就是创建集群。第二件事就是把我这个联邦的控制面部署在其中某个集群里。第四步就是把我的个集群放到集群联邦里面。这里可以查一下我当前各个集群的状态，第二步就是创建一个联邦的服务，当你在集群联邦这里创建一个服务之后，我下面各个子集群都会有一个被创建。这个时候我的效果是什么呢，我通过分布在不同的集群的服务的访问，可以按照就近的原则，把这个流量导到某个指定的集群上面。
集群联邦大概就分享到这里，后面说的比较快，有什么问题大家可以讨论。我打个广告，现在华为CCE在Kubernetes集群的贡献，大概有四百家的提交次数，全球能够达到第四，国内基本稳坐***把交椅。包括docker的贡献，也差不多是这么一个位置。我今天的演讲大概到这里结束。
