构建与定制:唯品会PaaS基于Kubernetes的实践

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
.cn 域名,1个 12个月
简介: 主要工作内容包括:平台DevOps方案流程优化,持续部署,平台日志收集,Docker以及Kubernetes研究。 大家好,我是唯品会PaaS团队的王成昌,与大家分享一下PaaS在Kubernetes的实践。

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

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

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

唯品会现状

20170118090757

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

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

唯品会PaaS构建流程

20170118090806

基于前面提到的现状,唯品会的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的集群来管理部署里面所有的节点。

20170118090814

这是唯品会的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触发的个数,以及对应用上的物理配额或者逻辑资源配额等。

20170118090820

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

20170118090844

原来的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。

20170118090852

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

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

PaaS网络方案和定制

20170118090859

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。

20170118090907

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

20170118090914

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

20170118090921

最后一个定制关于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。

日志收集和监控

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

20170118090930

平台自身日志收集的规则,包含系统组件还有平台应用两种设计。系统组件比较简单,无外乎通过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。

20170118090937

监控有两种,一种是对单个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创建的容器的监控信息。

本文转自中文社区-构建与定制:唯品会PaaS基于Kubernetes的实践

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
19天前
|
Kubernetes 持续交付 开发者
探索并实践Kubernetes集群管理与自动化部署
探索并实践Kubernetes集群管理与自动化部署
44 4
|
11天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践
|
1天前
|
Kubernetes Cloud Native 云计算
云原生之旅:Kubernetes 集群的搭建与实践
【8月更文挑战第67天】在云原生技术日益成为IT行业焦点的今天,掌握Kubernetes已成为每个软件工程师必备的技能。本文将通过浅显易懂的语言和实际代码示例,引导你从零开始搭建一个Kubernetes集群,并探索其核心概念。无论你是初学者还是希望巩固知识的开发者,这篇文章都将为你打开一扇通往云原生世界的大门。
41 17
|
7天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker与Kubernetes入门
【9月更文挑战第30天】在云计算的浪潮中,云原生技术正以前所未有的速度重塑着软件开发和运维领域。本文将通过深入浅出的方式,带你了解云原生的核心组件——Docker容器和Kubernetes集群,并探索它们如何助力现代应用的构建、部署和管理。从Docker的基本命令到Kubernetes的资源调度,我们将一起开启云原生技术的奇妙之旅。
|
7天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
阿里云ACK容器服务生产级可观测体系建设实践
|
11天前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
35 4
|
25天前
|
Kubernetes Docker 微服务
构建高效的微服务架构:基于Docker和Kubernetes的最佳实践
在现代软件开发中,微服务架构因其灵活性和可扩展性而受到广泛青睐。本文探讨了如何利用Docker和Kubernetes来构建高效的微服务架构。我们将深入分析Docker容器的优势、Kubernetes的编排能力,以及它们如何结合实现高可用性、自动扩展和持续部署。通过具体的最佳实践和实际案例,读者将能够理解如何优化微服务的管理和部署过程,从而提高开发效率和系统稳定性。
|
1月前
|
Cloud Native 持续交付 Docker
云原生技术实践:Docker容器化部署教程
【9月更文挑战第4天】本文将引导你了解如何利用Docker这一云原生技术的核心工具,实现应用的容器化部署。文章不仅提供了详细的步骤和代码示例,还深入探讨了云原生技术背后的哲学,帮助你理解为何容器化在现代软件开发中变得如此重要,并指导你如何在实际操作中运用这些知识。
|
1月前
|
Kubernetes 负载均衡 应用服务中间件
kubeadm快速构建K8S1.28.1高可用集群
关于如何使用kubeadm快速构建Kubernetes 1.28.1高可用集群的详细教程。
53 2
|
2月前
|
运维 Kubernetes 监控
自动化运维:使用Python脚本实现系统监控云原生技术实践:Kubernetes在现代应用部署中的角色
【8月更文挑战第31天】在现代IT运维管理中,自动化已成为提高效率和准确性的关键。本文将通过一个Python脚本示例,展示如何实现对服务器的自动监控,包括CPU使用率、内存占用以及磁盘空间的实时监测。这不仅帮助运维人员快速定位问题,也减轻了日常监控工作的负担。文章以通俗易懂的语言,逐步引导读者理解并实践自动化监控的设置过程。 【8月更文挑战第31天】本文旨在探索云原生技术的核心—Kubernetes,如何革新现代应用的开发与部署。通过浅显易懂的语言和实例,我们将一窥Kubernetes的强大功能及其对DevOps文化的影响。你将学会如何利用Kubernetes进行容器编排,以及它如何帮助你的
下一篇
无影云桌面