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

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 主要工作内容包括:平台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搭建和管理企业级网站应用
相关文章
|
1月前
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
2月前
|
存储 人工智能 Kubernetes
ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
2月前
|
存储 人工智能 物联网
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
|
3月前
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
3月前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
3月前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
5月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
5月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
6月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
6月前
|
Kubernetes 持续交付 开发者
探索并实践Kubernetes集群管理与自动化部署
探索并实践Kubernetes集群管理与自动化部署
141 1

热门文章

最新文章

推荐镜像

更多