关于容器迁移、运维、查错与监控,你想知道的都在这里了-阿里云开发者社区

开发者社区> 阿里巴巴云原生> 正文

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

简介: 作者 | 邱戈川(了哥)  阿里云智能云原生应用平台部高级技术专家 本文根据云栖大会全面上云专场演讲内容整理,关注阿里巴巴云原生公众号,回复“迁移”获得本文 PPT 今天上午王坚博士讲了一句话我比较有感触,大家做系统的时候,一定要想下你的系统的数据是怎么流转,这些系统的数据是怎么形成闭环。

_

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

本文根据云栖大会全面上云专场演讲内容整理,关注阿里巴巴云原生公众号,回复“迁移”获得本文 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 等全部对接在一起,让大家有一个更高可用的环境,以及一个更安全的环境。

我们给到大家一个 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 的池子里面去找到对应的空闲容器,然后挂到你的集群里面去。当你不需要的时候,它更快,它直接就可以释放掉了。因为大家知道,如果你是普通的方式,你还要等那台机器所有的容器全释放才可以释放机器,这时还有一个时间差。


大家知道,弹性好最耗钱的地方就是时间。所以我们用最快的方式来帮大家去节约掉这个成本。同时大家如果用这样的方式,还可以不去做容量规划,因为很多时候很难去做容量规划。如果今天有 100QPS,明天又有 1000个QPS,我不知道这个容量怎么做,这个时候利用 ECI 的技术,大家就可以避免这个容量规划了。

image_8_

当然我前面提到,阿里云 ACK 制定了很多自定义的指标,所以大家只需要去配置对应的定制指标,根据 QPS 也好,平均 Latency 也好,还是 P99、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等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”

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

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

关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践

官方博客