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

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

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

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

容器迁云解决方案一览

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

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

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

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

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

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

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

是咱们会注重什么事情？

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

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

容器上云之“攻”

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

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

物理裸金属服务器神龙

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

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

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

性能优化网络 Terway

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

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

灵活弹性

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

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

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

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

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

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

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

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

容器上云之“守”

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

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

智能化运维

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

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

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

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

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

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

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

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

安全与信任

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

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

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

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

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

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

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

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

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

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

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

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

(Demo 演示图)

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

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

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

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

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

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

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

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

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