《容器上云的攻与守》-云栖演讲实录-阿里云开发者社区

开发者社区> 云原生> 正文

《容器上云的攻与守》-云栖演讲实录

简介: 今天上午王坚博士讲了一句话我比较有感触,大家做系统的时候,一定要想下你的系统的数据是怎么流转,这些系统的数据是怎么形成闭环。我们在设计阿里云的K8S容器服务ACK的时候也是融入了这些思考。 首先是跟大家先看一下整个容器上云的解决方案。首先因为你已经做过容器,所以当你容器上云的时候,实际上这个事情是非常简单的,我们只需要提供的相应的工具,帮助大家把容器镜像迁入阿里云同时通过工具把K8S的配置迁到阿

今天上午王坚博士讲了一句话我比较有感触,大家做系统的时候,一定要想下你的系统的数据是怎么流转,这些系统的数据是怎么形成闭环。我们在设计阿里云的K8S容器服务ACK的时候也是融入了这些思考。
首先是跟大家先看一下整个容器上云的解决方案。首先因为你已经做过容器,所以当你容器上云的时候,实际上这个事情是非常简单的,我们只需要提供的相应的工具,帮助大家把容器镜像迁入阿里云同时通过工具把K8S的配置迁到阿里云,以及可以用DTS工具把数据库迁入到阿里云。这样我们就可以完成一个完整的容器化上云的过程。
image.png
所以这个过程其实非常简单,但是上完云之后,不是说我们原来的K8S原来怎么玩我们现在还是怎么玩。我们希望大家从上云的过程中有些收益,所以我们希望提供一些更高效敏捷的一些方式给到大家,包括怎么去做DevOps,包括我们怎么去做安全的软件供应链,以及我们做灰度发布。同时我们希望成本更优一点,关键是大家上完云之后的成本是怎么去核算,以及怎么去节约。所以容器上云后我们怎么去做更好的弹性伸缩,做自动化的运维。所以这个是大家需要在上云的过程中去考虑的问题。同时我们需要更好的管理我们的系统,我们一定要做到更好的高可用,而且要做到一个全局的管理。包括现在很多的公司已经在做混合云管理,这个也是大家在上云的过程中需要考虑的问题。
阿里云的K8S容器服务ACK到底长什么样,给大家一个概览图。
image.png
中间的K8S部分就跟大家去玩开源自建是一个道理,这个K8S是没有什么本质上区别。但是上了阿里云之后,我们希望给到大家的是一个完整的体系,而不是单单一个K8S。所以我们会把底下的跟我们的GPU服务器,跟我们弹性计算ECS,跟我们的网络VPC,跟我们的SLB打通。这个在上完阿里云ACK之后,我们一键的方式把它全部集成好,所以大家不用再去关心阿里云的IaaS层应该怎么去做,所以我们希望给大家屏蔽掉这一层复杂性。
同时存储也是一样的道理。存储的话,就是所有的阿里云的存储我们全部都已经支持完了,但是现在我们还在做什么事情?就是我们在把阿里云的日志服务,阿里云的中间件的服务,包括我们APM的ARMS,包括我们云监控的,包括我们高可用服务Ahas等全部对接在一起,让大家有一个更高可用的环境,以及一个更安全的环境。
我们给到大家一个K8S还是个原生态的K8S,所以大家可能会问我们你的K8S跟我自己的K8S到底有什么区别,所以还是很简单的回答大家这个问题。首先我们在上云的过程中给到大家永远是一个非云厂商锁定的K8S。就是你在线下怎么玩K8S,在线上也可以怎么玩K8S。如果你哪天你想下云的时候,你一样是可以下去的,所以这是我们很坚持的一个宗旨,就是我们不做任何的锁定。
image.png
但是我们会注重什么事情?首先我们会去考虑怎么做好安全,就是当你的K80的有问题的时候,我们怎么做快速响应,做CVE快速修复,然后我们怎么去打补丁,我们怎么做安全加固。第二就是我们跟阿里云的整个生态做结合。因为阿里云是我们更熟悉,所以我们跟阿里云的底层技术设施怎么打通,这个事情我们自己会做得更好一点。
我们现在也跟神龙服务器在一起,我们知道怎么让神龙服务器发挥更好的性能。同时我们还有很多创新,这样的话帮助大家更好的做好弹性。最重要一点实际上是我们做了那么久,我们已经积累了超过几千家的在线客户,这也是我们最大的优势。所以我们从几千家的客户里面浓缩回来大家所需要的最佳实践,我们收集完、整理完之后要返回给大家,帮助大家去用K8S上生产,这也是我们给客户最大的一个核心价值。
然后上完云之后,怎么用好K8S,怎么提升你的整个管理能力,提升你的系统效率,这个是我们要讲的“进攻”的部分。我们主要分三个方面去讲。
第一个,我们怎么跟我们阿里云的裸金属服务器做结合。
第二个,我们会提供性能比较优化好的网络插件Terway。
第三个,怎么做好灵活的弹性。

神龙裸金属服务器已经跟我们的容器平台ACK做了无缝融合。它最大的好处是什么?在容器化的时代,我们不需要再去考虑虚拟化的问题。所以两者的融合基本上是一个零虚拟化的开销的方案,容器直接使用到物理上的资源。在我们的神龙服务器里面,给到大家的实际上是个真实的Memory以及真实的CPU。但是它因为使用了阿里云专有的MoC卡技术,所以它可以直接对接到阿里云的云盘,对接到阿里云的VPC的网络。这样的话它的体验跟所有的ECS是一个道理。
image.png
这样容器化去做资源切割的时候,我们就不会再受虚拟化的影响。同时,它带来了另外一个好处就是它有一个offload的技术。这样网卡的中断会下沉到下面的这张卡上去,这样的话就是当你的流量比较大的时候,它将处理所有的网卡中断的开销,并不开销你本身的CPU。所以我们可以得到一个更极致的计算性能。
同时因为它的密度比较高,它基本上是个96核的机器,所以它加入容器集群之后,这个集群的容器的密度相对来说会比较高,所以它成本节约会比较好一点。另外,它是整个阿里云弹性计算资源里面最高规格的网络带宽,单独给30G的网络带宽带给到VPC,同时有20G的网络带宽留给云盘。这样大家可以比较好的去部署高密度的容器,同时它还是可以支持跟ECS是混搭组建集群的。
这个特点在弹性场景里面特别高效。你日常的流量可以用到神龙服务器去构建,当你要去做动态伸缩的时候,你可以用ECS。这样两种弹性资源一起使用会帮助大家把成本做到最优。另外一个方面,就是网络支持的情况了。网络的话是由阿里云独创的Terway网卡的多IP方式。实际上我们利用了阿里云里面的ENI的弹性网卡来构建我们的容器的网络,这样的话我们可以用一个ENI来支持10个IP,来构建我们的POD网络。它最大的好处就是它不会再受VPC的路由表大小的约束。所以POD跟你的ECS或者神龙服务器在同一个网络平面,所以它的网络中转开销是非常小的。
image.png
同时我们还支持了Network Policy,就是K8S里面的标准的Network Policy,以及我们扩展了带宽限流。这样的话也是避免大家不知道怎么去做网络内部的POD跟POD之间的安全管控,以及去做POD之间的网卡的带宽的约束,避免一个POD可以打爆整个网卡,这样的话就会比较好的去保护你的网络。而这个只需要添加annotation就可以完成,不影响K8S的兼容性。
image.png
最后一个就是我们要去做灵活的弹性。所以做K8S有个说法,就是你不做弹性基本上就相当于没玩KBS。所以,我们给大家提供了一个完整弹性的体系。除了标准的HPA去做伸缩POS之外,我们实际上还提供了阿里云开源的CronHPA,就是定时的方式来支持大家去伸缩POD。我们还提供了额外的指标,来帮助大家按指标的方式来去做弹性伸缩。包括我们日服务SLS里面提供的Ingress Dashboard,拿到你的QPS,拿到你的Latency,或者我们从我们的Arms,或者Ahas拿到你的每一个POD流量的情况,每个POD延迟的情况来做对应的伸缩。
image.png
因为大家知道你的程序可能开发出来之后,不一定能那么好的完美地去适配CPU。也就是说不是你所有的POD都能够按照CPU的方式来做伸缩,这个时候你就需要根据我们提供的额外的指标的方式来做伸缩,这是公有云里面给大家一个比较好的弹性的方式。
另外一个问题就是,当你的资源不够的时候,你可能就需要买更多的机器来支持容量,这个时候我们提供了Autoscaler,它会对接阿里云的ESS来帮助大家自动化的方式来够买机器,然后再重新扩容。所以通过这种方式,来帮助大家做好自动化的运维。
但是这里面也有另外一个问题,你可能希望这个伸缩速度会跟快。但是从购买台机器到冷启动再到加入K8S集群,然后再去扩容器这个时间会比较长,如果你的业务是一个突发的业务的话,可能你等不及机器伸缩。所以为了适配这个场景,我们现在又融合了阿里云的ECI,我们利用弹性容器实例来做这个事情,我们做了一个虚拟化的Kubelet,来对接ECI。这个时候大家不需要再去买机器,你可以直接用扩容的方式去做就好了。
image.png
所以它最大的好处是什么?就是说你不需要额外买机器,你只需要根据你的业务的情况下,直接伸缩容器,它会到ECI的池子里面去找到对应的空闲的容器,然后挂到你的集群里面去。当你不需要的时候,它更快,它直接就可以释放掉了。因为大家知道,如果你是普通的方式,你还是等那台机器所有的容器全释放才可以释放机器,这个时候还有一个时间差。因为大家知道,弹性好最耗钱的地方就是时间。所以就是我们用最块的方式来帮大家去节约掉这个成本。同时大家如果用这样的方式,还可以不需要去做容量规划。因为大家知道,很多时候很难做容量规划。如果今天有100QPS,明天又有1000个QPS,我不知道这个容量怎么做,这个时候可以利用ECI的技术,大家就可以避免这个容量规划了。
image.png
当然我前面提到,阿里云ACK制定了很多自定义的指标,所以大家只需要去配置对应的定制指标,根据QPS也好,平均Latency也好,还是P99、P999这些相应的最大延迟指标,以及你的入口流量的指标,来做相应的伸缩。所以大家只需要根据这些指标来配置对应的HPA的扩容的伸缩就可以了。所以这样的话,大家比较容易的去找到适配你业务场景的方式。特别是对电商的场景的话,大家很多时候去根据QPS做是比较合理的,如果大家比较有经验的话。
image.png
另外,伸缩不是做某一个业务/应用的伸缩。所以大家一定要记住一点就是,伸缩一定是一个一体化的联动性的伸缩,所以大家一定要从接入层到服务层同时考虑伸缩性。所以我们利用了Ingress Dashboard的指标(后面监控会提到),拿到了QPS,可以伸缩我们的接入层,同时我们可以根据APM的系统,就是像阿里云的ARMS这样一个系统,拿到对应的Latency来伸缩我们服务层。这样的话,大家可以构造一个联动性的全局性的伸缩。不然的话,很可能你在入口层面上做了一次伸缩,直接把流量倒了进来,最后打爆了是你的服务层。
所以大家一定要考虑这一点,就是所有的伸缩一定是联动性的全局性的。

这是前面讲了,我们怎么去更好地去做管理,以及我们有什么好的方式来提高我们的性能。第三部分的话给大家讲一下怎么去做防守,主要有三部分。

1、怎么做智能化运维。
2、怎么做安全体系。
3、怎么去做监控体系。
image.png
从管理角度来讲的话,大家不可或缺的点就是大家一定要去做灰度。从接触的情况来看的话,很多同学实际上并没有完全做到全灰度才上线,但是在阿里云是强制的要求。所以在K8S里面有方便的方式,大家可以用Ingress的方式来做灰度。其实比较简单,就是大家原来有一个旧的服务,那重新启动一个新的服务,都挂同一个Ingress上。那你在Ingress上面配置流量分割。可以是90%的流量割了旧服务,10%的流量给到新的服务,那这样的话Ingress会帮你做一个分流,这是比较简单的一个方式。
image.png
但是这里面还是有个问题,大家怎么知道什么时候能不能把90%的流量再切割10%流量过去新服务,让10%变成20%。这个也是大家日前比较痛苦的一个地方。因为很多时候发现很多同学很他们最常见的方式是什么?就是找了一个测试同学过来,她帮我测一下新的服务到底OK不OK,如果OK它就直接将90%的流量下降到80%,将10%的流量涨到20%,但是当它涨上去的时候你的系统立马出问题。
因为什么?因为你没有很好的依据去做这个流量的切割,你只是去看测试结果,只是看了当时那一刻到底对还是不对,而不是全局性的来看。所以我们在阿里云的K8S里面,我们会帮助大家集成好对应的灰度监控,然后帮助大家去做好可依据的灰度。我们会同时帮助大家去对比新的服务、旧的服务,当前的流量、平均的延迟、错误率、成功率、最大的延迟等等。通过这些去看新服务到底是不是已经满足你的真实的要求。以这个对比的依据来看,你流量的是否应该再继续切割。
就像刚才这例子一样,你新服务10%要变成20%,很可能你的延迟已经在增大,你的错误率已经在升高,这个时候你其实并不应该再去增加流量,而是要做回滚。所以这个大家一定要记住一点,就是我们在运维的过程中,一定要做到运维所有的动作一定要有依据。所以我们利用Ingress Dashboard给大家去做相关有依据的灰度。
image.png
另外是给大家做好对应的主机上在容器层面上的对应的监测和预警。在开源体系里面有一个组件叫NPD,然后我们阿里云又开一个事件告警器叫Eventer。我们把这两个东西打成了一个Helm包,在应用目录里面提供给大家。大家可以做好相应的配置之后,当你发生Docker挂了,当你发现主机时间同步有问题,或者程序没开发好造成FD被打爆,这个时候我们会把相应的通知,通过钉钉的方式要发给大家。
所以大家一定要记住在上完容器之后,你还在容器层面上的主机层的监控,跟你普通的非容器的主机监控是有区别的。所以大家下来一定要想办法把容器层面的主机监控再重新补回去。
image.png
另外,我们还一直在深化去做一些智能化的运维。例如容器上云后还必须做一些相关优化的配置。大家知道,上云之后,K8S应该用什么机器,用什么的SLB,用什么的网络,这些东西都需要做一个选优的,根据你的业务场景去做选优,所以怎么去选,我们会做一些相关的优化的推荐。我们会帮助大家去做一些相应的深度的监测,你到底有没有改过哪些配置,哪些配置被你改错了等等。
如果有一些错误的配置,智能运维会提醒你要去做一些纠错,减少大家后期发现错误的纠错高成本。这一块,我们还一直在深化中。
image.png
“防守”的第二件事情是要做安全。上云之后,大家会觉得就主机层面上的安全不一定够了。所以在容器管理层面上大家还需要去看看这个安全应该怎么做。安全的话,就是大家还是要记住一点就是安全一定要做全方位的安全,大家不要把安全认为是一个很小的事情,特别是很多公司是没有安全团队的,所以这个时候运维要承担好这个职责。
安全的话,我们主要是分三个方面来做安全。第一就是“软性安全”,例如社区层面的合作,然后是阿里云安全团队来帮我们做相应的一些“加持”,同时我们也会给客户做一些定期的安全的赋能。
另外一块的话就是IaaS层的安全,我们会做一些CVE的修复。我们还有阿里云自己的IaaS加固,以及我们现在还有镜像漏洞扫描。阿里云的镜像仓库已经支持了镜像扫描,所以这里也提醒大家。每次上业务,上生产之前,务必做一次镜像扫描。所有的开源社区提供的镜像都可能有漏洞的,大家记住。所以怎么去做好这些漏洞的防护,大家一定要下好功夫。同时我们提供对应的磁盘的加密,所以这一块大家可以做好数据的加密。
在K8S运行层面的话,我们团队做的更多的是在K8S审计日志方向,我们过会儿讲一下。包括我们会有更严密的KBS的这种安全的配置,以及我们会去做容器运行时的实时安全监测。所以大家有兴趣的话,可以看看阿里云安全的产品,他们已经支持了安全运行态的这种实时的检测。
同时我们还支持安全的管控,就是所有的安全配置我们都是双向认证。特别强调一点就是从管理层面上来讲的话,我们会做好对应的整个平台的安全的管理。这里更多的是针对内控。大家知道,实际上真正能偷盗你数据那个人,最容易的那个人是你们公司运维里面最有权限的那个人。所以,这里面才是大家日常需要重点管控的一个地方。
image.png
我们把所有能够接触到K8S的所有的入口,我们都做了一层安全审计。除了安全审计落日志的同时,我们还提供了很多预置的安全的审计项来帮助大家做预警。这里举一个例子,就是假如你的K8S如果有安全性的入侵,有人进入你的容器,我们会给大家落审期日志,包括到底是哪个用户用了什么命令进入了哪个容器。同时大家可以去配一个钉钉告警,这样一分钟内我们会把这个告警给告出来,这样的话大家可以知道,有人进入你的容器环境了。
image.png
这样确保整个K8S环境足够的安全。原则上是这样的,就是大家去用K8S的时候,在生产系统里面不应该在有人能够进入容器,所以一定要提醒大家做一点的防范。
image.png
另外一点大家比较难做的地方就是人员的变动。如果人员的变动之后,他这个人对系统在之前的时间内做过什么事情,大家有没有清楚?所以,同样的道理,我们会提供人员审计视图,根据人员子账户进行搜索审计的信息。这样的话,大家对内的安全管控是比较容易去做的,你只需要输入他使用的子账户名字,我们会帮助你把他所有K8S的操作都列出来。这样就是避免有人偷你的数据到外面去了,而不是两三个月后你还不知道。所以这个是帮助大家去做好人员离职的管控。安全层面上的话,大家务必要把审计日制这个事情看得比较重。
最后给大家讲一下,我们怎么去做整个监控体系,以及整个链路分析体系。整个监控体系的话,是非常的庞大。因为大家知道,很多同学在IDC里面自建K8S也好,还是在云上玩也好,只会去考虑Prometheus监控架构为主。但实际上,在上完阿里云之后,会帮助大家做好整个K8S的监控体系以及链路分析。
image.png
首先是我们从全局的角度来讲,会去给大家展示一下你整个KBS层面上,到底有多少个网络单元有多少个ECS,有多少个SLB,然后你机器部署的情况什么样子。
image.png
(Demo演示图)
我们底层会依赖于阿里云的云监控,以及刚才说的NPD的组件。中间这层还是标准的Prometheus架构。但是这里面有个问题,Prometheus架构非常的耗资源,所以我们会把它剥离出来作为一个托管的服务来提供,避免大家在集群规模越来越大的时候,Prometheus会把资源重新吃回去。
顶层的话,我们会给大家提供对应的ARMS以及SLS的Ingress Dashboard的监控。
image.png
我们细看一下整个流程应该上图这样子,大家一定要把所有的监控体系,以及链路分析体系构建完整。包括你从前端进来,到Ingress入口,然后到中间的Prometheus,最后到应用层的监控Arms,最后落到代码层面上的执行效率还是错误。大家一定要把这个链路链条构建出来,这样话帮助大家出现问题的时候,能够立马找到问题根源。因为在互联网体系里面,大家的每一次的问题,解决所带来的时间开销,就是你的成本。
image.png
前面刚才提到了,在应用层面的话,我们给大家预置了日志服务SLS提供的Ingress Dashboard。因为大家知道,从Ingress是全局的流量入口。大家通常的做法都去构建一个庞大的ELK系统做监控,这个成本是相当高的。但是,我们会帮助大家只需要落盘到我们的阿里云的SLS的服务。我们就会把这个全部Ingress监控指标构建出来,包括你当天的PV/UV,包括你现在延迟的情况,包括你上一周以及昨天的同时间的一个PV/UV的对比,包括你流量的TOP的省份,TOP的城市,包括你最后错误的以及最高延迟的地方,有500错误发生的地方在URL是什么,我们把这些东西全部给大家做成一个大的Dashboard,这样的话大家可以以成本最低的方式来看你的整个系统的运行情况。同时这个Dashboard是支持扩展的。目前这个也是现在上阿里云ACK的时候,大家非常喜欢的一个东西。
image.png
如果我们要对服务体系做监控的话,可能大家要去考虑怎么接入APM系统了。这一块,我们之前发现很多同学最痛苦的地方在哪,就是很多业务开发的同学其实并不喜欢做接入。因为他去做接入的时候,你要给他一个jar包,然后他要在程序里去引入这个jar包,重新打镜像才能上线,这个是其中一个繁琐的环节。另外一个环节就是大家其实最讨厌的地方就是当你的APM系统升级的时候,你要求所有的业务人员全部更新换jar包,要重新打包镜像,重新上线,业务开发人员就是非常地恼火了。所以我们在容器时代的时候,我们做了一个比较简单以及优雅的方案。我们提供一个应对的helm包给大家,做好相应的部署之后,只需要做一个事情:只需要你在发布容器的时候打上两个Annotation我们就自动做好APM系统(阿里云Arms)接入了。当你要做升级的时候,只需要把那个应用重新做一次发布,它自动用最新的jar包把那个旧包给换掉了。所以在运维的阶段,大家就可以去决定要不要接入APM系统,而不需要开发的参与。我们连开发包都不需要给到开发。大家也可以用同样思路,在接入外部系统的时候,思考怎么做到一个无侵入的一个方式。
image.png
刚才提到了,我们实际上是支持了Prometheus的托管。原来大家在K8S里面去做Prometheus的话,需要构建一堆的组件,而这些组件是非常的耗资源的。所以我们现在的做法就是提供一个Helm包给到大家。这样的话,大家只需要简单的一键安装,就可以用到阿里运托管的Prometheus服务。然后通过托管的Grafana的方式去看相应的数据,去做相应的告警。这些都是在后台做了,跟你整个集群没有任何关系,这样你的集群资源是最节约的也是最稳定的。
今天大概就这样给大家分享这几部分,谢谢大家!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云原生
使用钉钉扫一扫加入圈子
+ 订阅

云原生时代,是开发者最好的时代

其他文章