主要工作内容包括：平台DevOps方案流程优化，持续部署，平台日志收集，Docker以及Kubernetes研究。

大家好，我是唯品会PaaS团队的王成昌，与大家分享一下PaaS在Kubernetes的实践。基于2014年底或2015年初PaaS没有推广的现状，唯品会PaaS部门目前已经做了两年的时间。

PaaS 主要工作将分为三个部分进行介绍，首先，PaaS定义的标准构建流程，持续 集成和持续部署的架构以及已有组建上的功能定制；第二部分，基于Kubernetes实现的网络方案，以及根据网络方案做的扩展定制；第三部分，PaaS如何做日志收集和监控方案，最后列一下唯品会目前为止所遇到的问题和总结。

唯品会现状

唯品会目前线上有一千多个域，每个域之间相互的依赖比较复杂，每次的部署发布困难。线下有多套的测试环境，每套测试环境都要去维护单独的应用升级和管理。公司层面也没有统一的持续集成和部署的流程，大家各自去维护一个Jenkins或者一个Jenkins slave，看工程师的个人追求是否能够写一个完整的从源代码、到打包、最后到部署的脚本。

唯品会线上全部用物理机在跑，之前方式没有在线上，只是在测试环境跑，物理机的使用效率还是比较低的。即使在7周年大促的高峰时段，60~80%的物理机利用率也均低于10%。

唯品会PaaS构建流程

基于前面提到的现状，唯品会的PaaS定义了一个构建流程，整个流程不是一蹴而就，这是目前为止的定义，首先从源代码的角度出发，即Git，所有的7个Phase全部包括在Jenkins Pipeline里，由于是基于Kubernetes，所以Jenkins Pipeline的执行是通过Jenkins k8s Plugin去调度后台的k8s Cluster，由k8s产生的Pod去运行Pipeline。整个Pipeline的几个阶段，除了传统的编译单元测试和打包之外，加入了烘焙镜像、部署以及集成公司的集成测试（即VTP），打包和镜像完成后会正常上传到公司统一的包管理系统Cider和平台维护的Docker registry。

部署完成后会触发集成测试，如果通过测试的话，会把这个包或者是镜像标记为可用的状态，一般先从测试环境标记，然后通过到staging环境。目前PaaS 平台主要是维护测试环境和staging环境，线上还没有，但是已经定义了一个审批的流程，如果标记了这个包为可用的状态，需要一个审批来决定它是否可以上线。部署后通过k8s client，由另外一套k8s的集群来管理部署里面所有的节点。

这是唯品会的PaaS架构，主要包含持续集成和持续部署。首先由一个统一UI的入口Dashboard，使用Nginx和Tomcat作为服务的网关。其背后有两套系统——CPMS和API server，CPMS主要管理持续集成的各个流程，API server主要管理应用部署，在CPMS背后是使用多个Jenkins server统一连到一个Kubernetes集群上产生Pod作为Jenkins slave去运行，不同的构建有多种语言也有不同的模板，这里会提供各种方案让不同的Jenkins Pipeline运行在不同的Kubernetes node里面。

在部署实现一个Cloud Framework，可以接入各种cloud provider，目前使用的是k8s provider，背后的服务发现也是k8s推荐使用的Skydns。为了兼容公司基于包发布的这样一套模式，镜像管理这部分会把包管理系统Cider接入进入，平台的Docker Registry，以及应公司安全方面的要求，通过Clair对镜像的内容进行检查。

在日志收集方面，使用fluentd+ELK的组合，采用Prometheus做监控。在PaaS架构里，安全是通过接入公司的CAS做认证的动作，有一个Oauth组件做鉴权机制，通过Gnats做消息传输的系统。配额的问题在构建和部署中都会有所体现，包括用户对于Pipeline的个数控制或者Pipeline触发的个数，以及对应用上的物理配额或者逻辑资源配额等。

Docker Registry改造，主要在Middleware做了一些工作，做了一个接入公司的CAS和Oauth做的验证和授权。也接入了当有新的镜像Push进来的时候，会自动触发应用的部署。Docker Registry本身对所有的repository不同的tag索引还是比较慢的，所以会针对push进来所有的镜像信息存入数据库做一个索引，方便查找镜像。用户行为记录主要针对pull和push的动作，把它记录下来。镜像安全通过接入Clair做扫描，push镜像layer完成之后在push镜像的manifest时，会将镜像layer信息发送到Clair做镜像的安全扫描。

原来的Jenkins Kubernetes Plugin，默认把Jenkins slave调度在所有Kubernetes node上，我们做了一个node selecter，针对不同的Pipeline类型，需要跑在不同的节点上。调度上加入了node selecter，此外在每个Pipeline要去run的时候申请资源，加入了资源的request limit，防止单个的Pipeline在运行的时候占用过多的资源，导致其他的应用或者是构建任务受影响。在挂载方面，像传统的maven项目在下载过一个包之后，如果是同一个主机上会把.m2文件会挂载在主机上，不同的Jenkins Pool在跑的时候，可以共享已经下载过的资源文件。

最后，实现了Container slave pool的策略。当要run一个Pipeline的时候，每次告诉k8s要起一个Jenkins slave Pod，当需要执行一个job的时候，等待时间比较长，这里会定一个池的策略，就是一个预先准备的过程，当有一个新的任务要run的时候，立刻就可以拿到一个可用的containerslave。

这是PaaS的功能点，包含三个主要的部分，构建，部署和测试集。构建是关于用户定义Pipeline以及对Pipeline触发的record的管理，以及Pipeline各个phase的管理。部署主要对应用配置的管理，这个应用包括服务的配置如何、资源的申请如何，以及应用实例的一些管理。测试集对接公司的集成测试环境，和平台的应用进行关联。

空间管理和镜像管理，空间主要提供不同的隔离空间，提供应用快速的复制，比如你有一个测试环境，我也有一个测试环境，为了大家环境之间相互不干扰可以提供应用的快速复制。镜像管理主要分三种，即平台提供的基础镜像，业务部门一些特殊的需求会基于基础镜像做一些定制，以及具体业务镜像。

PaaS方案和定制

PaaS采用的网络方案，网络方案最开始直接使用的k8s 1.0的版本加flannel的一套工作模式，后来由于业务需求，用户需求能够直接访问到实例IP，而flannel当时是封闭的子网。目前采用Contiv这套网络模式，由公司统一分配Pod的IP网段。这里做了一个kube-HAProxy，替换了节点上kube-proxy这个组件，用kube-HAProxy来做Service IP到end point的一个转发。

在kube2sky，完成域名和服务IP的注册。传统的模式下，域名是短域名，Service的名字作为短域名，还有Service本身的IP会注册到Skydns上。这里做了一些定制，因为公司的应用比如两个业务域A和B都有本身的域名——a.vip.com和b.vip.com，A如果要访问B，不能让这个访问跑到线上或者其他环境去，于是通过kube-sky去解析规则，把b.vip.com加入到里面，再加一个subdomain作为扩展的domain search，最终找到平台内部部署的B域。

goroute 主要是平台内部的应用，每个应用都会提供一个平台的域名，这个域名主要是有一个组件叫做state aggregator，会watch k8s apiserver发出来的Service和end point的变化，最终通过Service的名字和end point的地址，把它写到gorouter的route注册表信息中，当我们访问平台域名时就可以找到真正的end point地址。这里也有定制，采用HAproxy和KeepAlived替换了kube-proxy，之前从Service IP到end point IP的转化，通过每个节点部署的kube-proxy，它会检测到 Service和end point的变化，去写IPtables的规则，来找到最终end point的地址的IP。

现在统一使用的HAproxy加上KeepAlived，有一个kube2HAproxy组件，功能和kube-proxy前面一部分相似，都要watch kube-apiserver的Service和 end point的event来动态的生成一个HAproxy最新的配置。KeepAlived主要为了高可用。有一个值得注意的细节，kube2HAproxy所在机器的IP，要和Service IP的网段在同一个网段里，用户在访问真正的应用的时候直接使用Service IP是公共可见的，而不是随便定义的Service IP。

对外应用访问是由平台提供的域名，后缀均为*.PaaS.vip.com，解析到之后会有公司的DNS统一转发到gorouter这台机器上，因为gorouter会监听到Service和end point的变化，route表里面会存储每个域名对应的end point的地址，通过round robin的方式找到最终的Pod来完成http访问。

最后一个定制关于Pod的IP固定，为什么要做PodIP固定？因为之前的测试环境很多应用都是部署在VM甚至在物理机上，IP都是固定的，有一些应用是需要白名单访问的，应用在这个部署机上，需要将IP提供给相应的调用方或者是公司的某个部门来告诉他加入白名单。Docker 默认情况下，每次销毁和重建的过程中，IP都会随机申请和释放，所以IP有可能变化。IP固定主要在k8s apiserver做，加了两个对象，即Pod IP Allocator和IP recycler，Pod IP Allocator是一个大的Pod的网段，可以认为它是Pod的IP池， IP recycler主要记录一些临时回收的IP，或者叫临时暂存区，IP不是一直存在，否则是一种IP浪费，有一个TTL时效性的。

当应用重新部署的时候，原本的Pod会被删掉，删掉的过程中会先放在IP recycler中，当一个新的Pod启动的时候，会通过namespace+RC name的规则去找是否有可用的IP，如果找到优先用这样的IP记录在Pod里，这个Pod对象最终会交由kubelet去启动，kubelet 启动的时候会读取这个Pod IP，然后告诉Docker 启动的IP是什么。最终有新的Pod启动之后，它的IP是之前已经被销毁的Pod IP，达到的效果就是Pod IP固定。在kubelet因为修改了Pod对象的结构，增加了Pod IP记录使用IP的情况，根据Pod的IP告诉Docker run的时候执行刚刚的IP来启动。kubelet 在删除Pod的时候会告诉k8s去release这个IP。

收集和

日志收集主要分三种类型：首先是平台自身的服务组件的收集，比如像、 或者Kubernetes 相关组件的日志收集，另一个是所有部署在平台里面应用的收集，最后还有一些域，因为公司一些已有系统（dragonfly）也是做日志收集和监控的，有一些特定的规则对接公司。

平台自身日志收集的规则，包含系统组件还有平台应用两种设计。系统组件比较简单，无外乎通过systemd或者是指定日志文件的路径做日志的收集，应用收集主要在k8snode上，k8s会把每一个Pod日志link在一个特定的文件路径下，因为Docker会记录每一个容器的日志，可以从这个地方读取应用的日志，但是只拿到namespace和Pod name这样的结构，我们会通过fluentd里的filter反向去k8s拿Pod所对应的meta data，最终发送到kafka，通过logstash达到elastic search。

Kibana的展现做了一些定制，因为平台的展现主要基于namespace和应用名称的概念查看日志的，定制能够展现特定的namespace下的特定应用的日志，同时把自定义的告警加在了这里，因为告警是通过elastalert来做的，在Kibana上做一个自定义告警的UI入口，由用户来指定想要监听什么样的日志内容的告警，去配置监听的间隔或者出现的次数，以及最终的邮件接收人。

有一个组件是当用户创建了自定义告警的规则时会发送到后面的elastalert ruler，ruler解析前台UI的信息，生成elastalert能够识别的configure文件，动态地读取configure的加入。

对接公司的业务系统比较简单，特定的收集规则都是特定的，比如具体的目录规则，一般来讲都是通过挂载容器的目录到主机目录上，在主机上统一部署一个agent去run，主要体现在k8s node上，所以仍然使用Daemonset的方式去跑agent。

监控有两种，一种是对单个Pod的实例监控，在页面上是可以直接看这样的实例的，单个Pod是一个应用实例了，然后通过node agent去包装了cAdviser，前端去统一访问，获取对应的CPU和Memory使用信息。cAdviser对Network收集到的数据是不正确的，通过node agent 读取Linux file获取Network的信息。Websocket Server 是为了提供网页上直接对容器进行网页控制台的登录。

另一个是看整个的应用，因为应用是有多个实例的，通过Graphana去定制，去展现namespace的应用，有多个实例，就把多个实例的监控都展现出来。此处有一个promethus plugin的定制，之前有一些Swarm的节点加入，持续部署提到过它是一个多个cloud framework都可以接入的。唯品会接入了一些Swarm的信息，针对Swarm创建的容器的话，也要能够监控到它的容器监控信息的数据。在Promethus plugin通过Docker info获取不同的Swarm node的信息，在每个Swarm node上部署cAdviser，获取由Swarm创建的容器的监控信息。

本文转自中文社区-