PPT下载 | KubeCon欧洲大会热点议题总汇

4月22日，由K8S技术社区、Linux中国联合主办的K8S GeekGathering 2017吸引了国内容器领域关注者100+人到场参与，如下是EasyStack 容器架构师王后明的演讲实录整理：

EasyStack 容器架构师王后明

你们下午好，开场以前，我作一个简单的现场调查，有哪位朋友在生产环境上或者使用K8S平台的，你们能够举手。生产环境或者在运维，或者在生产上使用的，开发和测试环境上用的多一些。

今天的话题，我主要是对KubeCon2017欧洲峰会的热门话题的总结和社区关注的的分享和回顾，说到现场的，对我印象最深的是其中某个话题的时候，现场调查的时候，问有谁，哪位同事在生产环境上运维K8S平台，在现场能够看到超过80%的人举手，我感受在K8S平台，在国外的使用程度，可能比国内走得更前一步，已经有很是很是多的生产案例在跑。

1

CNCF最新动态

首先分享第一个问题是CNCF的最新动态，在两天的会议上，CNCF宣布了社区发展的最新状况，就是在加入黄金和会员后，CN已经增长到85家的会员的数量，生态发展速度很是快，托管项目，目前从峰会上，3月25日，DOcker把容器运营时捐赠给了容器的基金会，进入基金会之后，CNCF托管的项目目前一共有9个，包括K8S、等等，目前一共9个托管的项目，但同时，由于在这个图里面，CNCF进行了维护，至关于整个企业在云里面作运用改造，可能涉及到很是多的项目，包括整个技术架构，项目的安装部署，容器的编排，应用的开发和部署的流程，整个其实涉及到很是很是多的开源的项目，来支撑云应用层的生态，目前CNCF基金会管理9个项目，更多项目进入基金会的视野，未来会有更多项目进入CNCF下托管，这是CNCF社区的状况。

峰会上一个比较重要的消息就是说DOcker把本身的容器运营时捐赠给了CNCF和基金会。咱们知道在K8S1.5版本的时候，他已经脱离多个运行的CII容器，Container的接口，有这个接口以后，K8S能够绕过DOcker使用基金会的实现，作容器的编排，在1.5发布以后，Docker的话，多少也可以感受到一些压力，由于若是K8S一个CII+OCI标准运行成为事实之后，Docker的市场占有率会有所降低，今年峰会的时候，Docker选择把ContainerD捐赠给基金会，这是本身的容器运营时，主要解决下面几个问题，好比说他怎么样，第一个部分是进行容器竞相的格式的管理，怎么样把分层的镜像，进行运行时，同时会管理底层的存储和网络，怎么样去分配，就是容器运行时要作的事情，容器ContainerD的话，主要是结合Docker的产品，结合微软的共同开发了开源的容器运行时的平台，这是ContainerD要解决的问题。

说到OCI和这些标准，咱们能够简单看一下，目前这个容器的生态里面所存的几个，标准化的一个组织，首先从镜像运行时和网络方面都有不一样的标准化组织来规范容器的生态，CoreOS是APPC和OCI和CNI，谷歌是OCI和CNI，DOcker本身推的Liwork，1.5版本里面，怎么调动不一样的容器运行时的接口，1.5开始是这个状态，避免直接使用，直接调用下面的，好比DOcker和这样的容器的实现，就是造成统一的容器运行时的接口，底下不一样的实现是经过不一样的接口调度容器，若是一个公司企业里面来选择一个容器的编排的工具，选择K8S是底层的容器引擎没有硬性的要求，这样能够更好地避免底层技术厂商锁定的问题。

其实在峰会上，分享了他为何选择把ContainerD捐赠给基金会，主要是两个大的方面，一个是你们也是立志于造成整个容器生态的统一的规范，避免说你们各自玩本身的一套规范。这样也是给整个生态的开发者和厂商都会带来一些兼容性的问题，选择CNCF基金会，是由于二者目标一致，造成统一的容器生态的规范，而后技术实现方面的话，ContainerD是直接使用GRPC的调动的关系，监控数据也是使用普罗米修斯的方式发布，这样能够更好地跟K8S更好地融合。其实ContainerD进入CNCF之后，代替DOcker的地位，在社区已经有针对ContainerD和CNCF接口的实现，直接调用CII的调用Containerd的技术实现也跟CNCF其余项目保持一致，作下面容器的盛行周期的管理，这个就是Containerd的为何捐赠给CNCF基金会的说明。

2

峰会上的技术热点总汇

接下来咱们能够看一下整个峰会上所讲述的一些比较重要的和比较新的技术话题，咱们看到第一点是KubeVirt，咱们目前用得比较多的是，IaaS层里面，open stack比较多，容器的话K8S比较大，KubeVirt的实现方法有两种，对Open Stack平台里面，从Open Stack平台上，完成对虚拟化和容器技术的统一调度，KubeVirt目的是作容器和虚拟机的统一调度，实现方式是把K8S做为容器的控制平面，评比容器的差别，让整个K8S调度数据中心的虚拟化和容器的技术。

现场的话，工程师也给你们作了说明，怎么样实时建立虚拟机，同时怎么管理虚拟机的生命周期，KubeVirt的实现的话，实现方式，和K8S目前三方的，若是咱们要新增功能，在K8S里面新增一些功能加一些资源，是相似的方案在K8S里面，是不会直接改这个sever，会扩展一套新的，会有一套新的管理者响应新的资源，由于整个平台是在K8S框架下，因此这两个下面的统一资源管理是经过TBR统一管理、调度三方资源，把三方的服务定义为统一的实现，具体的他们新加了一个APIsever，经过新的资源的描述类型，来定义这个虚拟机的资源，咱们响应虚拟机类型的资源，把资源真正的请求分发到底层运行在每一个节点上的资源，这样的话，来完成整个用K8S平台对虚拟机和容器作统一的调度。

这是KubeVirt的大概介绍。这个项目的话，目前它尚未到特别成熟的阶段，目前是至关于原型的阶段，来证实这种方式，若是咱们想用K8S做为统一的虚拟机和容器的管理平台也是可行的。这是关于容器和虚拟化，它俩统一管理，做为统一的控制平面的实现方式之一，除了KubeVirt以外，其实整个当前K8S生态上面，其实也有另一些实现容器和虚拟机调度管理的思路，第一种是virtlet，让虚拟机和容器统一管理，和KubeVirt类似，Virtlet沿用现有的资源和框架，作二者统一的资源的调度，如今已经进入统一项目下面，你们能够本身作一些尝试。

另一种是Frakti也是一个项目，跟郭理靖分享的京东云的类似，底层其实用来真正跑容器运行时，其实仍是虚拟化的技术，只是把虚拟化和容器进行了深度的融合，底层的容器运行时仍是虚拟化的技术。主要是用的hypervisor控制的。Open Stack这边其实也是另一种实现思路，就是在Open Stack和虚拟机统一管理，这是另外的话题，这边咱们就不说这部分了，这是容器和虚拟机统一管理的方案。接下来咱们能够看一下对Open sevice API以及K8S Service Catalog。

咱们若是用某一个平台以外的服务，咱们要作的事情很是简单，第一步要获取这个服务提供商能够提供哪些服务，好比从这上面能够提供服务，有这个服务能力以后，咱们第二步直接向服务提供商提供具体的数据出来。把建立出来的数据库和底层的某个应用进行绑定，绑定好以后，咱们应用能够更方便用，往数据库里写入数据存储数据，这样的话，咱们使用这些服务的时候，并不须要关注具体的细节，这是提供给咱们的桥梁，让整个生态应用之间，使用、分发更方便。这个就是Open sevice Broke API作的事情，对应的，相似于KubeVirt，是插件格式加入整个平台里面，至关于整个的实现，让K8S里面的服务更好地使用数据库提供的原理，这个也是和刚才相似，也是经过三方的资源来实现，目前也是孵化项目，能够作一些使用。

在目前的审计，在生产的系统里面是很是重要的组成部分，按照时间顺序记录用户，管理员或者其余组建，跟安全相关的行为，审计的话，能够给系统管理员提供，对安全行为的审计，过程当中须要回答的几个问题，好比这个用户作了什么操做，操做是何时发生，由谁发起，对谁发起，它发起的目标是什么，它在哪里被观察到，哪里被发起，会影响哪些地方。这是整个审计过程当中须要的信息，其实在整个审计的系统里面都应该能囊括到，主要是用来发现系统的安全违规行为，作性能分析、软件BUG的分析，调试的工具，这是审计系统要完成的功能，审计系统，并不会给系统带来额外的安全性，主要是以K8S审计为例，Virtlet在Open sevice以后的行为，是已认证用户的行为的记录。这是审计系统的定位，只能说做为咱们感应系统安全的一个参数信息的来源，这是审计系统。

那审计系统在K8S里面，目前功能比较简单，你在审计的时候，加几个选项就能把审计系统打开，打开以后，咱们能够从日志里面看到，咱们系统的用户和管理员作的认证的操做，当前的日志的记录，目前是比较简单的状态，刚开始有这么一个系统，能够来做为系统K8S审计的信息的输出，这是审计的在K8S的状态，而后另一个就是别的工程师分享了，K8S里面无服务框架的项目，其实跟容器也是至关于目前像公有云里面，AWS，谷歌、微软，都有本身的无服务框架的产品，在K8S里面，也有很多的尝试的实现，K8S的话，也是跟KubeVirt相似，也是用TBR做为函数，操做的具体的展示的对象，同时也是新加了一个响应函数的请求，最底层的话，无服务器请求，并非没有最后的服务器的门第，是经过最底层的K8S的基础资源来响应函数后面的资源的运算的请求，同时相关的一些配置，是经过map作的。这是K8S的实现，同时经过插件化的方式加入整个K8S的平台里面来的。

除了K8S以外，也有这样的框架。底层也是利用Kubeless是兼容谷歌的API。另外还有分享的容器初始化系统的，由于linux内核启动的时候会先启动一个init进程，这个进程的PID开始hypervisor于特殊的使命，须要作好的父进程的角色，好比传递信号，容器使用PID隔离不一样容器里面进程的，带到这个问题就是每一个容器里面都能看到这么一个进程，这个进程由于linux设立的是惟一的进程有使命，处理这个子进程的关系，在init为1的进程就变得重要了，早期若是运维过生产环境，Docker或多或少遇到，容器某个进程怎么样，其实这种状况下，就是跟容器初始化进程关系比较大，由于PID为一的进程比较关键。

因此对应实现的话，有三种实现的方式，第一种是dumb init，系统起来的时候，若是咱们在某个容器件里面使用这个的话，咱们首先要启动真正的应用，这个dumb init是完成了容器初始化的工做，真正的是做为dumb init的子进程，不会由于没有处理进程化，致使进程上不掉的状况，因此dumb init是比较轻量级的实现方式。另外从Docker1.13版本以后，DockerD已经加了这种标记，DOckerD会自动会用户的应用程序处理初始化的工做，因此重新版本的话，咱们遇到这种进程相对少一些了。这是DOcker这边的实现。第三种方式是能够经过Systemd，同时咱们在容器里面的话，也能够选择用Systemd充当内部的初始化的进程，这个好处是除了作容器初始化系统以外，还能更多处理日志，服务之间的启动顺序，这是它带来的好处，这是容器初始化系统，你们作应用容器的时候，若是遇到相似的问题，能够选择三种不一样的方式，用哪一种方式解决可能存在的问题。

3

与生产实践相关的技术话题

最后一部分跟你们分享一下，我所听到的这些里面跟生产应用关系比较大的，对我印象深入的几个话题，其中之一是houm，我大概普及一下，简单理解能够理解成应用系统里的一个，其实就是，目的是让K8S里面的一个应用，它使用和维护升级更加方便。咱们知道。若是咱们单跑一个容器其实很是方便，咱们直接进行单个容器的使用、启动、删除就能够。若是真正的一个系统作完微服务化，整个大系统不多是单个的容器，容器之间或多或少存在跟其余系统之间微服务的交互关系，这个时候，把各个大系统里面子系统的依赖关系交代清楚，这个是很是重要的。houm的出现是为了解决大系统进行容器应用化以后，在线上运维的所作的事情，至关于咱们把每一个小的服务定义好以后，以houm里面的定义好，一个应用的话，能够包括多个微服务，一个helm能够理解为一个ITE，至关于一个大应用之间，它的依赖关系能够经过一个管理起来，这是helm作的事情。

K8S生态里面的一个应用包的管理工具。helm的内部组成相对简单，helm本身是一个客户端，你本身执行的样本、app这些，你能够本身设定对应的应用，运营的名字是，客户端发起请求之后，响应完之后，服务器上把这个应用的描述先描述的压缩文件下载到K8S集群里面，度曲这些信息，部署组件，helm的话，在整个企业里面，其实它的重要性愈来愈重要，其中第一点是CTO分享了，第一个K8S里面的，咱们目前只有Docker，这只是单个容器的，有了helm以后，咱们能够把标准的应用，不只仅是咱们能够用容器生态来管理好一个容器，更方便的是咱们把标准应用经过应用的方式管理和发布，quay集成helm，相似于应用商店，quay和容器的仓库融合得比较紧密，在整个微服务过程当中，除了能把整个image以外，同时能够推送到应用的里面去，这样能达到整个应用方面的运维和管理。这是这个产品。

第二部分，其实helm能够做为整个流程的重要部分，其实整个企业作应用容器化的时候，少不了代码提交、触发、流程以后，把对应的应用推送到容器里面去，有了helm以后，咱们能够作的事情还有不少，一个大的服务分为三个应用，若是咱们三个应用事先定义好应用的组织关系，这个时候，若是咱们每次应用的代码提交，其实都会带动整个线上的大系统作总体的更新和测试，这样不只是对某个服务自己作一个测试，其实能够对多个服务大系统作大的过程，这是helm在企业里面应用更丰富，重要性，后面会愈来愈重要。包括国内国外，愈来愈多的平台和产品已经支持用helm做应用商店的方式。最后一个部分就是分享一下华为工程师的分享，如何让K8S支持5万+个服务。在1.6发布的时候，官方宣称，K8S能够支持5千个物理节点，若是真正开始规模化地使用这么一些应用的时候。

若是规模上去以后，会遇到一些问题，由于服务的话，都是经过IP 作流量的负载，对整个副本，决定你这个应用最后到哪一个访问的时候，它流量在那个pot上面，是经过ip tab的规则，能够看到整个系统规则里面一些IP tabs规则的增长，你的数量上来以后，会成倍的增长，ip table达到必定程度会形成反应延迟很是大，这个时候对IPTables作一些删除修改的话，整个延迟很是大，为何慢，是由于ip tables不是增量作规则的增长，若是当前有服务出来，后面要新建立一个服务，这些规则是要把当前全部规则拷贝出来作修改，再把这个规则save回去，把整个规则作一个更新，这个过程会致使ip table锁住，若是规则很是大，会很是耗时，有个具体的数据是若是有5千个serves的时候，ip table有四万条，添加一条规则耗时11分钟才能把这条规则在系统上生效，这是绝大的耗时，有16万条规则，须要耗时5小时。在生产里面能够理解为不可用的状态了。ip table做为内部使用，存在的问题。这是服务延迟的问题，就是你请求到节点以后，分发到哪一步了的延迟，第一个服务和最后一个服务之间，到哪一个之间的间隔，这是比较显著的变化了。面对IP table存在的问题，社区有方案，用IPVS代替当前kube proxy，基于Netfilter之上的协议。

目前经过NAT负载均衡模式，支持更高级的，直接路由的方式，目前K8S使用NAT的实现，这种实现的话，目前代码仍是在，若是五千规则须要耗11分钟，如今降到2秒，以前须要5小时，也只须要2秒，这样的话，能够解决这样的问题。这是如何用IPVS支持5万级别的service，这是性能数据的对比，在5千个数据的时候，以前须要11分钟，若是2万个服务的话，须要5小时，用IPVS，能够很小，这样的话可以很好地支撑整个大的应用的，大规模的应用的分发，大规模应用的运行。以上就是我在峰会上听到的比较多的热门的技术话题的简单分享，涉及到的问题比较多，你们有问题的话，这只是影子，告诉你们有这个东西，后面要用的话，能够从社区上，或者网络上找到更丰富的资源和介绍，个人分享就到这儿，谢谢你们。