中国东信基于Kubernetes的容器云PaaS平台

“中国-东盟信息港”是按照国家“一带一路”倡议整体布局要求、建设更为紧密的中国—东盟命运共同体、21世纪海上丝绸之路的一个信息平台：http://www.caih.com。东信基于Rancher Kubernetes架构和建设了他们的容器云PaaS平台，在云原生、容器化、微服务、CICD、DevOps等方面的都有了相关实践和应用。

6月28日，负责中国东信容器云PaaS 平台的研发和建设、中国-东盟信息港的研发总监王志雄出席了Rancher Labs举办的Container Day 2018容器技术大会，并作了题为**《中国东信基于Kubernetes的容器云PaaS平台》**的主题演讲，本文根据演讲内容整理而成。

王志雄，中国-东盟信息港研发总监，负责中国东信公司容器云的研发和管理工做。硕士，曾就任于IBM、华为等公司，在IBM时任研发部门经理、技术专家。10年以上的云计算IaaS、PaaS、容器云、SDN/NFV、微服务、DevOps等研发经验。

各位来宾，各位朋友，你们上午好，我是来自中国-东盟信息港的王志雄，在中国东信负责容器云PaaS 平台的研发和建设。今天我从技术角度、就以下四个方面，给你们分享中国东信基于Kubernetes建设容器云PaaS平台的经验。

第一个是PaaS平台，PaaS平台在云计算刚出现的时候就已经和IaaS、SaaS已经共存了，可是刚开始只是不温不火，为何到这几年PaaS平台才这么火了呢？如何来建设一个PaaS台？PaaS平台须要哪些技术内容来承载？我会在这里作一个分享。

第二个是微服务，微服务咱们说有两条路线，第一条是SpringCloud，第二条是Kubernetes，咱们来看一看怎么使用Kubernetes来构建一个微服务的平台。

第三个是CICD ，第四个是DevOps。咱们会看到有些场合说的CICD，有的场合说的DevOps，这两者有什么关系，有什么区别，如何来构建CICD 和DevOps，我会在这里作一个揭晓。

Kubernetes与容器云PaaS平台

咱们首先来看一下Kubernetes与容器云平台。Kubernetes这个PaaS平台要解决三个方面的IT架构方面的问题。第一，耦合，咱们作研发的知道，除了应用程序以外，无论Java，仍是Go，仍是Python，都须要大量的应用配置，这些配置和咱们的系统环境——Windows也好，Linux也好——都是耦合的，因此会常常出现咱们在交付产品的时候，明明在研发的环境可用的，到了测试不可用，到了最后的生产发布也不可用，从而出现这样的神秘的BUG、神秘的配置。以前有人提出一个比较好的方法是写一个很好的文档以供参考，可是文档一般仍是会遗漏，并且这还要依赖于咱们人员写文档的能力，以及理解的能力。第二个，繁杂，如今不管是技术、工具仍是语言都很是繁杂，例如语言有java、有Go、有python、有php。第三个，不灵活，咱们如今互联网时代是须要从按周发布，提高为按天发布，甚至一天几回、十几回甚至上百次发布，这在之前的物理机或者虚拟机时代是不可能的。

因此如何来解决这些问题？Cloud Native是这个答案。Cloud Native能作到什么呢？第一是容器化，把应用以及它的配置打包，保证开发、测试和运维的环境一致，从而避免神秘的配置、神秘的错误、神秘的文档、还有多是神秘的人。第二是面向微服务，把之前的一体的区域式服务给分解为微服务，从而更灵活，并能够独立更新。第三方面是动态编排管理，若是容器不少，则须要大量的配置文件，须要部署不少容器则必然要用到编排管理，也就是咱们在此选择的Kubernetes。

下图是中国东信基于Kubernetes、Docker研发的四大场景。第一是企业应用平台，企业应用平台能够将应用在平台上作到一键部署，利用pod auto-scaling进行弹性自动伸缩，若是出现故障则能够经过health check实现故障自愈，另外还有强大的灰度发布功能。以前的互联网公司可能须要一个很是大的团队来作灰度发布，现在使用Kubernetes，Kubernetes已经自带灰度发布功能了。第二个是咱们的微服务，用Kubernetes来构建咱们的微服务平台，构建以后咱们就能够组件化、松耦合、去中心，并且是灵活独立的。第三个咱们作了这样一套CICD的系统，CICD的系统从咱们的开发、从代码提交、从编译到构建到自动化测试、到容器化发布。第四个是DevOps ，DevOps是能够作到开发运维的协同。

这是咱们中国东信的PaaS 平台，咱们从最底层看起，最底层是容器云的Infra，咱们说Infra不是IaaS产品吗？其实不论是IaaS仍是PaaS 都须要Infrastructure，固然它们是有区别的。咱们无论作Iass作PaaS ，其中的难点归到最后其实都是存储和网络，我在后面会分享存储网络咱们是怎么作的。再上来是容器资源管理，以及容器集群编排与调度，须要把这个Pod调度到众多集群节点中的哪个？根据什么策略来调度？根据CPU调度仍是根据内存调度？根据亲和策略仍是反亲和策略？再上来是咱们容器云应用Service，咱们说PaaS 平台是以应用为中心，因此确定须要这样一个强大的应用Service，PaaS平台应用的Service有服务发现、配置中心、负载均衡、弹性伸缩、服务编排这样一些强大的功能，那么就用咱们的PaaS平台，上面咱们会提供中间件、数据库、负载均衡、文件存储等等。若是须要哪个，好比须要一个MySQL ，把一个MySQL容器拿过去用就能够了。再去用咱们的中间件，PaaS平台上面就承载咱们庞大的、灵活的企业应用。

若是研发过Kubernetes应该对这个图很熟悉，这是个典型的Kubernetes集群，咱们分两个层面来看。第一个层面一个是咱们本身内部的管理，部署Service，Service都是经过Master进行来管理，经过API Server来和各个组件进行交互，用Controller Mananger来控制咱们各个组件得到的调度，Scheduler是具体的应用策略，etcd 是一个数据库。那么会调度到咱们的Node上，Node上存在咱们的Pod ，一个Pod里能够有能够有多个Container，这是咱们的内部的管理提供Service。第二个层面是咱们从外部的访问，外部的访问通常就是经过Internet通过防火墙来访问咱们对外提供一个ingress ，ingress是Kubernetes提供的一个很是强大的功能，有了ingress 以后，咱们能够对外提供一个统一的域名系统，外部只要访问咱们的统一域名，就能够访问咱们内部的不一样的应用，经过此域名就能够进行智能的分发。

上面咱们说的叫物理架构，而下面我会讲讲逻辑架构，这两个的关注面不同。逻辑架构从咱们研发内部看，最底层是容器基础设施层，包括咱们的Runtime、Volume Plugin、Network Plugin；再上来是核心层，核心层对外提供API，对内提供Plugin环境；第三层是应用层，能够进行部署，能够进行ingress智能路由；再上来是管理层，能够进行智能化以及Network policy；接口层是对外提供咱们的命令行管理工具；Ecosystem是咱们的生态。

刚才说PaaS的基础架构的终极难题是网络和存储。咱们先来看一下中国东信是怎么解决网络问题的。网络的方案很是多，咱们看到有单组区域的，开始是单组区域有bridge、host、container、NAT，也有原生的iptables；再上来有主机集群，有OVS，有IPSec；如今最主流的就是最上面一行，一个是Flannel，一个是calico，还有将这两个折在一块儿的Canal。这里我能够提一下咱们的SDN（软件定义网络）。SDN起源于Openflow，什么是Openflow？Openflow是有强大的报文解析能力，能够对报文进行任意的更改，这个强大的能力刚问世时取得了瞩目的关注，而且在当年被评为将来10大创新技术的排名第二位，第一位是云计算，第二位是SDN。但最初Openflow在问世后的广大的应用中碰到了一些问题，由于它和之前传统的不兼容，因此实际上最后被应用最多的是VXLAN。VXLAN是一个overlay的技术。SDN在应用最多的是什么？是VXLAN overlay。第三个是BGP，BGP在网络中应该有二三十年的历史，通过不断地打磨、沉淀、优化，实际上BGP已经开始统一咱们的SDN领域了，如今BGP已经能够取代咱们的软件定义网络，虚拟化的网络。

SDN网络通用的两个方向，第一个是Flannel，Flannel其实本质上是一个Overlay的方案，因此在主机的容器内是自动分布的IP，只是在主机以外，作了一个Overlay叠加的封装，但这个Overlay和咱们传统的IaaS的overlay相比实际上是不同的，传统的IaaS的VXLAN除了Overlay的功能，还有多租户的功能，可是这里由于它只在出口作了个封装，因此没有多租户的功能。因此Flannel有什么缺点？它没有安全隔离的功能。第二个它封包解包必然带来开销，因此这个是咱们要解决的问题。Flannel官方也表示若是用户想对数据中心作更好的网络安全隔离，推荐用Calico。

Calico的核心是基于BGP，若是是小网络能够用BGP的client进行IP路由的自动分发以及路由互联。Calico的好处是什么？简单！如果使用Overlay网络出现故障，用户难以排查故障是来自overlay仍是underlay；但用BGP，用户直接定位路由就行了。此外，Calico还带了一个很好的特性就是和network policy结合在一块儿，能够提供网络的微分段，若一个主机上有多个容器、有多个应用，能够提供很好的安全隔离。Calico的不足是什么？它须要取决于数据中心对于BGP的支持力度，可能如今还不是全部数据中心都是BGP。但我仍是推荐BGP的，从最初的的Facebook到如今国内的大公司，不少都已经开使用BGP来取代全部的内部的路由协议，包括二层协议。这是一个很好的方案，能够简化运维工做，数据中心只有一种路由协议多好。

谈完网络，另外一个难题就是存储。Kubernetes和Docker相比除了普通的volume以外，还提供了persistent volume和storage class，经过PV和PVC来抽象存储细节。这有什么好处？能够作到管理控制与转化分离。管理员关注PV的存储细节，用户只要关注PVC使用存储就行了。通用的存储ceph、NFS、Gluster都没问题。

容器云微服务

下面咱们来看一下怎样用Kubernetes来构建一个微服务。下图是咱们很熟悉的微服务架构的特性，把一个单体的应用来分解拆分为多个灵活的微服务。微服务的特性是服务的组件化。怎样拆分一个微服务？不是按代码的行数，不是按函数，而是按功能、按产品模式来拆分。有了微服务就能够去中心化的管理。

构建微服务，必然要有以下这些功能：有这么多的服务，怎样发现这个服务？因此要服务发现。多个服务如何作到负载均衡？多个应用service怎么样进行智能的路由分发？怎样管理成千上万个服务的配置？怎样弹性伸缩？怎样容错？怎样自动升级？访问控制怎么作？

下图就是咱们使用Kubernetes来构建的微服务。怎样来构建？把上述问题的答案汇聚在一块儿就是最终答案了。第一个服务发现，使用咱们的service，包括咱们Kubernetes内置的DNS就能够来作这样一个服务发现。第二个负载均衡，有node上的kube-proxy加上咱们的service分发是负载均衡。第三个智能路由，经过ingress能够智能地将不一样的应用经过统一的入口分发到后端的服务。配置中心经过咱们的Kubernetes的config-map，能够在一个统一的服务器上进行远端多个微服务的配置的统一管理、统一更新。明文用config-map，若是重要的机密的配置能够secret。

再接下来是咱们的服务编排，deployment是实际使用过程当中用户很是欢迎的一个特性。由于deployment把这个yaml文件写好以后，你们去自动部署了，须要几个副本，它会自动的去扩容以及缩容deployment。若是须要开发一个应用商店，能够去helm开发。

再下来是咱们的弹性伸缩，经过RS写好副本数，再经过auto-scaling指定须要自动伸缩的条件，好比说能够基于CPU伸缩，能够基于咱们的内存访问伸缩。再下来是咱们的容错，使用咱们的liveness来监控咱们的容器以及应用的健康情况，若是容器挂掉了，能够把它重启，若是这个节点挂掉了，那就把容器调度到另外一个节点。熔断怎么作？能够用咱们的readiness，readiness不但能够监控咱们的容器的存活，还能够监控咱们的service是不是健康的。

限流，限流能够经过咱们的quota限额，能够经过咱们的namespace限额，也能够对咱们的pod限额，也能够对容器限额。

升级，rolling updates是自动升级，有问题能够一键回滚。那RBAC是能够提供基于角色的安全访问。Network policy在BGP Calico基础上提供微分段，能够很好的安全隔离，包括日志监控EFK和Prometheus。

容器云CI/CD

如何来作容器云的CI/CD，天然使用咱们的容器云三剑客，Jenkins+Docker+Kubernetes。其实在容器云出现以前，其实已经有CI/CD了，那时CI/CD用Jenkins作，Jenkins能够提供编译、构件、测试、任务调度的流水线；那Docker有什么做用？可让咱们的环境标准化，能够隔离；Kubernetes能够提供一个大的平台，可让资源共享、弹性伸缩。

CI/CD也就是须要把开发、测试流水线作一个自动化，从开发、编译、构件、测试、打包到部署，因此在咱们的测试报告出来以后，若是是经过了就把镜像上传到镜像仓库，而后再发布到Kubernetes的发布平台。

DevOps

谈完CI/CD咱们来看一下很火的DevOps。经过这张图咱们其实就能够看出CI/CD和DevOps有什么区别，有什么联系，什么场合该用CI/CD，什么场合该用DevOps。CI/CD在左边，CI/CD最关注的是开发和测试，关注的具体的序数是什么？是Jenkins来作个流水线，是Git来作一个源代码的仓库、源代码的拉取，Maven来作构建，SonarQube来作静态的代码分析，Robotframework来作自动化的测试。SonarQube这样一个代码分析工具对咱们的编译经过以外的一个保证把它良好的代码是有很是好的好处。由于我记得仍是在十年前，当时在一个国内特大公司入职培训的时候，通常的导师对每位员工都会培训一个案例：代码规范。好的代码并非经过编译就好了，并且须要好的编程规范，避免经过了编译但却其实会出现神秘的故障，并且很难定位。

看完CI/CD，咱们来看看DevOps关注什么。DevOps的关注的是咱们发布的环境要自动伸缩，要A/B Test，要灰度发布，要自动的升级，或者要滚动升级，滚动升级就是指不是一次性升级完全部的pod，仍是能够选择性的升级一部分，好比升级20%，或者升级50%。有什么好处？可使咱们的应用服务不中断。它们二者的共同点，固然都须要基于Docker和Kubernetes来作这样的一个容器化封装和自动化。右边的这个DevOps实际上是DevOps刚出现的时候，咱们叫标准的DevOps。它和CI/CD有区别，可是其实有很大的联系，CI/CD和这样的标准DevOps组合起来就叫作咱们的大DevOps，因此这二者是能够结合起来，CI/CD解决咱们开发、测试、自动化、标准化的问题，标准DevOps解决咱们的开发运维，主要是运维方面的问题，只有这二者结合起来就能够一键式解决咱们的开发、测试、运维问题，而且能够造成一个闭环。

下图就是滚动升级这一功能，能够经过逐个容器替代，升级其中的25%的容器，而后再确认一下，若是工做正常，咱们再能够升级其中的下一批容器。

下面是灰度发布。这在咱们突飞猛进的频繁发布的互联网场景特别有用。由于咱们有大量的互联网应用。因此有一个特别好的新功能，像看看它的这个功能，看看用户的反馈，用户的使用状况怎么样，咱们的灰度发布。用Kubernetes的pod很是方便。开始能够给一个灰度版本1，内部用户使用的没问题，再给一个版本2，给咱们的用户群，用户群A，再逐渐的扩大到全部的用户，这是互联网很是好的应用。

总 结

这里来回顾一下中国东信基于Kubernetes开发的这样四大场景。第一个是PaaS企业应用平台。第二个是Kubernetes的微服务，SpringCloud也是微服务，但SpringCloud微服务是主要关注在应用层面，并且它只是针对Java有效，对别的语言是没有的。Kubernetes是语言无关的，并且是比SpringCloud使用面更广的，但最佳的实践是能够把咱们的SpringCloud的每一个微服务经过容器化的方式进行封装，再经过Kubernetes进行平台的集群资源调度和自动伸缩。第三个就是咱们CICD，第四个是咱们的DevOps。

后续将会为你们带来更多大会的演讲实录，请保持关注Rancher公众号的最新推送~