关于容器迁移、运维、查错与监控,你想知道的都在这里了

_

做者 | 邱戈川(了哥)  阿里云智能云原生应用平台部高级技术专家前端

本文根据云栖大会全面上云专场演讲内容整理,关注阿里巴巴云原生公众号,回复“迁移”得到本文 PPT数据库

今天上午王坚博士讲了一句话我比较有感触,你们作系统的时候,必定要想下你的系统的数据是怎么流转,这些系统的数据是怎么造成闭环。咱们在设计阿里云的 K8s 容器服务 ACK 的时候也是融入了这些思考。安全

容器迁云解决方案一览

首先是和你们先看一下整个容器上云的解决方案。首先由于你已经作过容器,因此当你容器上云的时候,实际上这个事情是很是简单的,咱们只须要提供的相应的工具,帮助你们把容器镜像迁入阿里云同时经过工具把 K8s 的配置迁到阿里云,以及能够用 DTS 工具把数据库迁入到阿里云。这样咱们就能够完成一个完整的容器化上云的过程。性能优化

image_0_

因此这个过程其实很是简单,可是上完云以后,不是说咱们的 K8s 原来怎么玩如今仍是怎么玩。咱们但愿你们从上云的过程当中有些收益,因此咱们但愿提供一些更高效敏捷的一些方式给到你们,包括怎么去作 DevOps,包括咱们怎么去作安全的软件供应链,以及咱们作灰度发布。服务器

同时咱们但愿成本更优一点,关键是你们上完云以后的成本怎么去核算,以及怎么去节约。因此容器上云后咱们怎么去作更好的弹性伸缩、作自动化的运维,这个是你们须要在上云的过程当中去考虑的问题。同时咱们须要更好的管理咱们的系统,必定要作到更好的高可用,并且要作到一个全局的管理。包括如今不少的公司已经在作混合云管理,这个也是你们在上云的过程当中须要考虑的问题。微信

阿里云的 K8s 容器服务 ACK 到底长什么样,给你们一个概览图:网络

image_1_

中间的 K8s 部分就跟你们去玩开源自建是一个道理,这个 K8s 没有什么本质上的区别。可是上了阿里云以后,咱们但愿给到你们的是一个完整的体系,而不是单单一个 K8s。因此咱们会把底下的部分跟咱们的 GPU 服务器、跟咱们弹性计算 ECS、跟咱们的网络 VPC、跟咱们的 SLB 打通。这个在上完阿里云 ACK 以后,咱们一键的方式把它所有集成好,因此你们不用再去关心阿里云的 IaaS 层应该怎么去作,咱们但愿给你们屏蔽掉这一层复杂性。架构

存储也是同样的道理。存储的话,就是全部的阿里云的存储咱们所有都已经支持完了,可是如今咱们还在作什么事情?咱们在把阿里云的日志服务、阿里云的中间件服务,包括咱们 APM 的 ARMS、咱们云监控、以及咱们高可用服务 Ahas 等所有对接在一块儿,让你们有一个更高可用的环境,以及一个更安全的环境。less

咱们给到你们一个 K8s 仍是个原生态的 K8s,你们可能会问咱们你的 K8s 跟我本身的 K8s 到底有什么区别,因此仍是很简单的回答你们这个问题。首先咱们在上云的过程当中给到你们永远是一个非云厂商锁定的 K8s。就是你在线下怎么玩 K8s,在线上也能够怎么玩 K8s。若是你哪天你想下云的时候,你同样是能够下去的,因此这是咱们很坚持的一个宗旨,就是咱们不作任何的锁定。运维

image_2_

是咱们会注重什么事情?

  • 首先咱们会去考虑怎么作好安全,就是当你的 K8s 有问题时,咱们怎么作快速响应,作 CVE 快速修复,而后咱们怎么去打补丁,咱们怎么作安全加固;
  • 第二就是咱们跟阿里云的整个生态作结合。由于阿里云是咱们更熟悉,因此咱们跟阿里云的底层技术设施怎么打通,这个事情咱们本身会作得更好一点。

咱们如今也跟神龙服务器在一块儿,咱们知道怎么让神龙服务器发挥更好的性能。同时咱们还有不少创新,这样能够帮助你们更好的作好弹性。最重要的一点其实是:咱们作了那么久,已经积累了超过几千家的在线客户,这也是咱们最大的优点。因此咱们从几千家的客户里面浓缩回来你们所须要的最佳实践,咱们收集完、整理完以后要返回给你们,帮助你们去用 K8s 上生产,这也是咱们给客户最大的一个核心价值。

容器上云之“攻”

上完云以后,怎么用好 K8s?怎么提高你的整个管理能力、提高你的系统效率?这个是咱们要讲的“进攻”的部分。咱们主要分三个方面去讲:

  • 第一个,怎么跟咱们阿里云的裸金属服务器作结合;
  • 第二个,咱们会提供性能比较优化好的网络插件 Terway;
  • 第三个,怎么作好灵活的弹性。

物理裸金属服务器神龙

神龙裸金属服务器已经跟咱们的容器平台 ACK 作了无缝融合。它最大的好处是什么?在容器化的时代,咱们不须要再去考虑虚拟化的问题。因此二者的融合基本上是一个零虚拟化的开销的方案,容器直接使用到物理上的资源。在咱们的神龙服务器里面,给到你们的其实是个真实的 Memory 以及真实的 CPU,但它由于使用了阿里云专有的 MoC 卡技术,因此它能够直接对接到阿里云的云盘、对接到阿里云的 VPC 网络。这样的话它的体验跟全部的 ECS 是一个道理。

image_3_

这样容器化去作资源切割的时候,咱们就不会再受虚拟化的影响。同时,它带来了另一个好处就是它有一个 offload 的技术。这样网卡的中断会下沉到下面的这张卡上去,当你的流量比较大的时候,它将处理全部的网卡中断的开销,并不开销你自己的 CPU,因此咱们能够获得一个更极致的计算性能。

同时由于它的密度比较高,它基本上是个 96 核的机器,当它加入容器集群以后,这个集群的容器的密度相对来讲会比较高,因此它成本节约会比较好一点。另外,它是整个阿里云弹性计算资源里面最高规格的网络带宽,单独给 30G 的网络带宽带给到 VPC,同时有 20G 的网络带宽留给云盘。这样你们能够比较好的去部署高密度的容器,同时它仍是能够支持跟 ECS 是混搭组建集群的。这个特色在弹性场景里面特别高效。你平常的流量能够用到神龙服务器去构建,当你要去作动态伸缩的时候,你能够用 ECS。这样两种弹性资源一块儿使用会帮助你们把成本作到最优。

image_4_

性能优化网络 Terway

另一个方面,就是网络支持的状况了。网络的话是由阿里云首创的 Terway 网卡的多 IP 方式。实际上咱们利用了阿里云里面的 ENI 的弹性网卡来构建咱们的容器的网络,这样的话咱们能够用一个 ENI 来支持 10 个 IP,来构建咱们的 POD 网络。它最大的好处就是它不会再受 VPC 路由表大小的约束。POD 跟你的 ECS 或者神龙服务器在同一个网络平面,因此它的网络中转开销是很是小的。

同时咱们还支持了 Network Policy,就是 K8s 里面标准的 Network Policy,以及咱们扩展了带宽限流。这样的话也是避免你们不知道怎么去作网络内部的 POD 跟 POD 之间的安全管控,以及去作 POD 之间的网卡的带宽的约束,避免一个 POD 能够打爆整个网卡,这样的话就会比较好的去保护你的网络。而这个只须要添加 annotation 就能够完成,不影响 K8s 的兼容性。

image_5_

灵活弹性

最后一个就是咱们要去作灵活的弹性。作 K8s 有个说法:你不作弹性基本上就至关于没玩 K8s。因此,咱们给你们提供了一个完整弹性的体系,除了标准的 HPA 去作伸缩 POS 以外,咱们实际上还提供了阿里云开源的 CronHPA,就是定时的方式来支持你们去伸缩 POD。咱们还提供了额外的指标,来帮助你们按指标的方式来去作弹性伸缩。包括咱们日服务 SLS 里面提供的 Ingress Dashboard,拿到你的 QPS 以及 Latency,或者从咱们的 Arms、Ahas 拿到你的每个 POD 流量的状况,每一个 POD 延迟的状况来作对应的伸缩。

image_6_

由于你们知道你的程序可能开发出来以后,不必定能那么好的完美地去适配 CPU。也就是说不是你全部的 POD 都可以按照 CPU 的方式来作伸缩,这个时候你就须要根据咱们提供的额外指标的方式来作伸缩,这是公有云里面给你们一个比较好的弹性的方式。

另一个问题就是,当你的资源不够的时候,你可能就须要买更多的机器来支持容量,这个时候咱们提供了 Autoscaler,它会对接阿里云的 ESS 来帮助你们自动化的方式来够买机器,而后再从新扩容。经过这种方式,来帮助你们作好自动化的运维。

可是这里也有一个问题,你可能但愿这个伸缩速度会更快。可是从购买台机器到冷启动再到加入 K8s 集群,而后再去扩容器这个时间会比较长,若是你的业务是一个突发业务的话,可能你等不及机器伸缩。为了适配这个场景,咱们如今又融合了阿里云的 ECI,利用弹性容器实例来作这个事情,咱们作了一个虚拟化的 Kubelet,来对接 ECI。这个时候你们不须要再去买机器,你能够直接用扩容的方式去作就行了。

image_7_

因此它最大的好处是什么?就是说你不须要额外买机器,你只须要根据你的业务的状况下,直接伸缩容器,它会到 ECI 的池子里面去找到对应的空闲容器,而后挂到你的集群里面去。当你不须要的时候,它更快,它直接就能够释放掉了。由于你们知道,若是你是普通的方式,你还要等那台机器全部的容器全释放才能够释放机器,这时还有一个时间差。<br /> <br />你们知道,弹性好最耗钱的地方就是时间。因此咱们用最快的方式来帮你们去节约掉这个成本。同时你们若是用这样的方式,还能够不去作容量规划,由于不少时候很难去作容量规划。若是今天有 100QPS,明天又有 1000个QPS,我不知道这个容量怎么作,这个时候利用 ECI 的技术,你们就能够避免这个容量规划了。

image_8_

固然我前面提到,阿里云 ACK 制定了不少自定义的指标,因此你们只须要去配置对应的定制指标,根据 QPS 也好,平均 Latency 也好,仍是 P9九、P999 这些相应的最大延迟指标,以及你的入口流量的指标,来作相应的伸缩。因此你们只须要根据这些指标来配置对应的 HPA 的扩容伸缩就能够了。这样的话,你们比较容易去找到适配你业务场景的方式。特别是对于电商场景来说,若是你们比较有经验的话,你们不少时候根据 QPS 去作是比较合理的。

image_9_

另外,伸缩不是作某一个业务/应用的伸缩。你们必定要记住一点就是:伸缩必定是一个一体化的联动性的伸缩,因此你们必定要从接入层到服务层同时考虑伸缩性。咱们利用了 Ingress Dashboard 的指标(后面监控会提到),拿到了 QPS,能够伸缩咱们的接入层,同时咱们能够根据 APM 的系统,就是像阿里云的 ARMS 这样一个系统,拿到对应的 Latency 来伸缩咱们服务层。这样的话,你们能够构造一个联动性的全局性的伸缩。否则极可能你在入口层面上作了一次伸缩,直接把流量倒了进来,最后打爆了你的服务层。

你们必定要考虑这一点,就是全部的伸缩必定是联动性、全局性的。

容器上云之“守”

前面讲了,咱们怎么去更好地去作管理?以及咱们有什么好的方式来提升咱们的性能?第三部分的话给你们讲一下怎么去作防守,主要有三部分:

  • 怎么作智能化运维;
  • 怎么作安全体系;
  • 怎么去作监控体系。

智能化运维

image_10_

从管理角度来说的话,你们不可或缺的点就是必定要去作灰度。从接触的状况来看,不少同窗实际上并无彻底作到全灰度才上线。但在阿里云这个是强制要求,在 K8s 里面有方便的方式,你们能够用 Ingress 的方式来作灰度。其实比较简单,就是你们原来有一个旧的服务,那从新启动一个新的服务,都挂同一个 Ingress 上。那你在 Ingress 上面配置流量分割。能够是 90% 的流量割了旧服务,10% 的流量给到新的服务,这样的话,Ingress 会帮你作一个分流,这是比较简单的一个方式。

image_11_

可是这里面还有个问题:你们怎么知道何时能不能把 90% 的流量再切割10%流量过去新服务,让 10% 变成 20%?这个是你们目前比较痛苦的一个地方。由于不少时候发现不少同窗,他们最多见的方式是什么?就是找了一个测试同窗过来,帮我测一下新的服务到底 OK 不 OK,若是 OK 它就直接将 90% 的流量降低到 80%,将 10% 的流量涨到 20%,但当它涨上去的时候你的系统立马出问题。

由于什么?由于你没有很好的依据去作这个流量的切割,你只是去看测试结果,只是看了当时那一刻到底对仍是不对,而不是全局性的来看。因此在阿里云的 K8s 里面,咱们会帮助你们集成好对应的灰度监控,而后帮助你们去作好可依据的灰度。咱们会同时帮助你们去对比新的服务、旧的服务、当前的流量、平均的延迟、错误率、成功率、最大的延迟等等。经过这些去看新服务究竟是不是已经知足你的真实的要求,以这个对比的依据来看,你流量的是否应该再继续切割。

就像刚才这例子同样,新服务 10% 要变成 20%,极可能你的延迟已经在增大、你的错误率已经在升高,这个时候你并不该该再去增长流量,而是要作回滚。你们必定要记住一点,就是咱们在运维的过程当中,必定要作到运维全部的动做必定要有依据。因此咱们利用 Ingress Dashboard 给你们去作相关有依据的灰度。

image_12_

另外是给你们作好对应的主机上在容器层面上的对应的监测和预警。在开源体系里面有一个组件叫 NPD,而后咱们阿里云又开一个事件告警器叫 Eventer。咱们把这两个东西打成了一个 Helm 包,在应用目录里面提供给你们。你们能够作好相应的配置以后,当你发生 Docker 挂了、当你发现主机时间同步有问题,或者程序没开发好形成 FD 被打爆,这个时候咱们会把相应的通知,经过钉钉的方式发给你们。

你们必定要记住在上完容器以后,你还在容器层面上的主机层的监控,跟你普通的非容器的主机监控是有区别的。因此你们接下来必定要想办法把容器层面的主机监控再从新补回去。

image_13_

另外,咱们还一直在深化去作一些智能化的运维。例如容器上云后还必须作一些相关优化的配置。你们知道,上云以后,K8s 应该用什么机器?用什么的 SLB?用什么网络?这些东西都须要作一个选优,根据你的业务场景去作选优,怎么去选呢?咱们会作一些相关的优化的推荐,帮助你们去作一些相应的深度的监测,你到底有没有改过哪些配置,哪些配置被你改错了等等。

若是有一些错误的配置,智能运维会提醒你要去作一些纠错,减小你们后期发现错误的纠错高成本。这一块,咱们还一直在深化中。

安全与信任

image_14_

“防守”的第二件事情是要作安全。上云以后,你们会以为就主机层面上的安全不必定够了。因此在容器管理层面上你们还须要去看看这个安全应该怎么作。安全的话,就是你们仍是要记住一点就是安全必定要作全方位的安全,你们不要把安全认为是一个很小的事情,特别是不少公司是没有安全团队的,因此这个时候运维要承担好这个职责。

安全的话,咱们主要是分三个方面来作安全。

  • 第一就是“软性安全”,例如社区层面的合做,而后是阿里云安全团队来帮咱们作相应的一些“加持”,同时咱们也会给客户作一些按期的安全的赋能。

  • 另一块的话就是 IaaS 层的安全,咱们会作一些 CVE 的修复。咱们还有阿里云本身的 IaaS 加固,以及咱们如今还有镜像漏洞扫描。阿里云的镜像仓库已经支持了镜像扫描,因此这里也提醒你们:每次上业务、上生产以前,务必作一次镜像扫描,全部的开源社区提供的镜像均可能有漏洞。因此怎么去作好这些漏洞的防御,你们必定要下好功夫。同时咱们提供对应的磁盘的加密,这一块你们能够作好数据的加密。

  • 在 K8s 运行层面的话,咱们团队作的更多的是在 K8s 审计日志方向,咱们过会儿讲一下。包括咱们会有更严密的 K8s 的这种安全的配置,以及咱们会去作容器运行时的实时安全监测。你们有兴趣的话,能够看看阿里云安全的产品,他们已经支持了安全运行态的这种实时检测。

同时咱们还支持安全的管控,就是全部的安全配置咱们都是双向认证。特别强调一点就是从管理层面上来说的话,咱们会作好对应的整个平台的安全管理,这里更多的是针对内控。你们知道,实际上真正能偷盗你数据那我的,最容易的那我的是大家公司运维里面最有权限的那我的。因此,这里面才是你们平常须要重点管控的一个地方。

image_15_

咱们把全部可以接触到 K8s 的入口,都作了一层安全审计。除了安全审计落日志的同时,咱们还提供了不少预置的安全的审计项来帮助你们作预警。这里举一个例子,就是假如你的 K8s 有安全性的入侵、有人进入你的容器,咱们会给你们落审期日志,包括究竟是哪一个用户用了什么命令进入了哪一个容器。同时你们能够去配一个钉钉告警,一分钟内咱们会把这个告警给告出来,这样你们就能够知道有人进入你的容器环境了。

image_16_

这样确保整个 K8s 环境足够的安全。原则上是这样的,就是你们去用 K8s 的时候,在生产系统里面不该该在有人可以进入容器,因此必定要提醒你们作一点防范。

image_17_

另一点你们比较难作的地方就是人员的变更。人员变更以后,他这我的对系统在以前的时间内作过什么事情,你们有没有清楚?因此,一样的道理,咱们会提供人员审计视图,根据人员子帐户进行搜索审计的信息。这样的话,你们对内的安全管控是比较容易去作的,你只须要输入他使用的子帐户名字,咱们会帮助你把他全部 K8s 的操做都列出来。这样就避免有人偷你的数据到外面去了,而不是两三个月后你还不知道。因此这个是帮助你们去作好人员离职的管控。安全层面上的话,你们务必要把审计日制这个事情看得比较重。

一体化监控体系全链路分析与定位

最后给你们讲一下,咱们怎么去作整个监控体系,以及整个链路分析体系。整个监控体系的话,是很是的庞大。由于你们知道,不少同窗在 IDC 里面自建 K8s 也好、仍是在云上玩也好,只会去考虑 Prometheus 监控架构为主。但实际上,在上完阿里云以后,咱们会帮助你们作好整个 K8s 的监控体系以及链路分析。

image_18_

首先是咱们从全局的角度来说,会去给你们展现一下你整个 K8S 层面上,到底有多少个网络单元、有多少个 ECS、有多少个 SLB,而后你机器部署的状况什么样子。

image_19_ (Demo 演示图)

咱们底层会依赖于阿里云的云监控,以及刚才说的 NPD 的组件。中间这层仍是标准的 Prometheus 架构。可是这里 Prometheus 架构很是耗费资源,因此咱们会把它剥离出来做为一个托管的服务来提供,避免你们在集群规模愈来愈大的时候,Prometheus 会把资源从新吃回去。

顶层的话,咱们会给你们提供对应的 ARMS 以及 SLS 的 Ingress Dashboard 的监控。

image_20_

咱们细看一下整个流程应该如上图所示,你们必定要把全部的监控体系,以及链路分析体系构建完整。包括你从前端进来,到 Ingress 入口,而后到中间的 Prometheus,再到应用层的监控 Arms,最后落到代码层面上的执行效率仍是错误。你们必定要把这个链路链条构建出来,这样可以帮助你们在出现问题的时候,立马找到问题根源。在互联网体系里面,你们的每一次的问题,解决所带来的时间开销,就是你的成本。

image_21_

前面刚才提到了,在应用层面的话,咱们给你们预置了日志服务 SLS 提供的 Ingress Dashboard。由于你们知道,从 Ingress 是全局的流量入口,你们一般的作法是:都去构建一个庞大的 ELK 系统作监控,这个成本是至关高的。咱们会帮助你们只须要落盘到咱们的阿里云的 SLS 的服务,就会把所有 Ingress 监控指标构建出来,包括你当天的 PV/UV;包括你如今延迟的状况;包括你上一周以及昨天的同时间的一个 PV/UV 的对比;包括你流量的 TOP 的省份、TOP 的城市;包括你最后错误的以及最高延迟的地方,有 500 错误发生的地方在 URL 是什么。咱们把这些东西所有给你们作成一个大的 Dashboard,这样你们能够以成本最低的方式来看你的整个系统的运行状况。同时这个 Dashboard 是支持扩展的,目前这个也是如今上阿里云 ACK 的时候,你们很是喜欢的一个东西。

image_22_

若是咱们要对服务体系作监控的话,可能你们要去考虑怎么接入 APM 系统了。这一部分,咱们以前发现不少同窗最痛苦的地方在于:不少业务开发的同窗其实并不喜欢作接入。由于他去作接入的时候,你要给他一个 jar 包,而后他要在程序里去引入这个 jar 包,从新打镜像才能上线,这个是其中一个繁琐的环节。

另一个环节就是你们其实最讨厌的地方就是当你的 APM 系统升级的时候,你要求全部的业务人员所有更新换 jar 包,要从新打包镜像、从新上线,业务开发人员就是很是恼火了。因此在容器时代的时候,咱们作了一个比较简单以及优雅的方案:咱们提供一个应对的 helm 包给你们,作好相应的部署以后,只须要作一个事情:你在发布容器的时候打上两个 Annotation 咱们就自动作好 APM 系统(阿里云 Arms)接入了。当你要作升级的时候,只须要把那个应用从新作一次发布,它自动用最新的 jar 包把那个旧包给换掉了。

因此在运维阶段,你们就能够去决定要不要接入 APM 系统,而不须要开发的参与,甚至咱们连开发包都不须要给到开发。你们也能够用一样思路,在接入外部系统的时候,思考怎么作到一个无侵入的一个方式。

image_23_

刚才提到了,咱们其实是支持了 Prometheus 的托管。原来你们在 K8s 里面去作 Prometheus 的话,须要构建一堆的组件,而这些组件是很是耗费资源的。因此咱们如今的作法就是提供一个 Helm 包给到你们。这样的话,你们只须要简单的一键安装,就能够用到阿里运托管的 Prometheus 服务。而后经过托管的 Grafana 方式去看相应的数据、去作相应的告警。这些都是在后台作了,跟你整个集群没有任何关系,这样你的集群资源是最节约的也是最稳定的。

“ 阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,作最懂云原生开发者的技术公众号。”

相关文章
相关标签/搜索