今天上午王坚博士讲了一句话我比较有感触，大家做系统的时候，一定要想下你的系统的数据是怎么流转，这些系统的数据是怎么形成闭环。我们在设计阿里云的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。如果你哪天你想下云的时候，你一样是可以下去的，所以这是我们很坚持的一个宗旨，就是我们不做任何的锁定。
但是我们会注重什么事情？首先我们会去考虑怎么做好安全，就是当你的K80的有问题的时候，我们怎么做快速响应，做CVE快速修复，然后我们怎么去打补丁，我们怎么做安全加固。第二就是我们跟阿里云的整个生态做结合。因为阿里云是我们更熟悉，所以我们跟阿里云的底层技术设施怎么打通，这个事情我们自己会做得更好一点。
我们现在也跟神龙服务器在一起，我们知道怎么让神龙服务器发挥更好的性能。同时我们还有很多创新，这样的话帮助大家更好的做好弹性。最重要一点实际上是我们做了那么久，我们已经积累了超过几千家的在线客户，这也是我们最大的优势。所以我们从几千家的客户里面浓缩回来大家所需要的最佳实践，我们收集完、整理完之后要返回给大家，帮助大家去用K8S上生产，这也是我们给客户最大的一个核心价值。
然后上完云之后，怎么用好K8S，怎么提升你的整个管理能力，提升你的系统效率，这个是我们要讲的“进攻”的部分。我们主要分三个方面去讲。
第一个，我们怎么跟我们阿里云的裸金属服务器做结合。
第二个，我们会提供性能比较优化好的网络插件Terway。
第三个，怎么做好灵活的弹性。
神龙裸金属服务器已经跟我们的容器平台ACK做了无缝融合。它最大的好处是什么？在容器化的时代，我们不需要再去考虑虚拟化的问题。所以两者的融合基本上是一个零虚拟化的开销的方案，容器直接使用到物理上的资源。在我们的神龙服务器里面，给到大家的实际上是个真实的Memory以及真实的CPU。但是它因为使用了阿里云专有的MoC卡技术，所以它可以直接对接到阿里云的云盘，对接到阿里云的VPC的网络。这样的话它的体验跟所有的ECS是一个道理。
这样容器化去做资源切割的时候，我们就不会再受虚拟化的影响。同时，它带来了另外一个好处就是它有一个offload的技术。这样网卡的中断会下沉到下面的这张卡上去，这样的话就是当你的流量比较大的时候，它将处理所有的网卡中断的开销，并不开销你本身的CPU。所以我们可以得到一个更极致的计算性能。
同时因为它的密度比较高，它基本上是个96核的机器，所以它加入容器集群之后，这个集群的容器的密度相对来说会比较高，所以它成本节约会比较好一点。另外，它是整个阿里云弹性计算资源里面最高规格的网络带宽，单独给30G的网络带宽带给到VPC，同时有20G的网络带宽留给云盘。这样大家可以比较好的去部署高密度的容器，同时它还是可以支持跟ECS是混搭组建集群的。
这个特点在弹性场景里面特别高效。你日常的流量可以用到神龙服务器去构建，当你要去做动态伸缩的时候，你可以用ECS。这样两种弹性资源一起使用会帮助大家把成本做到最优。另外一个方面，就是网络支持的情况了。网络的话是由阿里云独创的Terway网卡的多IP方式。实际上我们利用了阿里云里面的ENI的弹性网卡来构建我们的容器的网络，这样的话我们可以用一个ENI来支持10个IP，来构建我们的POD网络。它最大的好处就是它不会再受VPC的路由表大小的约束。所以POD跟你的ECS或者神龙服务器在同一个网络平面，所以它的网络中转开销是非常小的。
同时我们还支持了Network Policy，就是K8S里面的标准的Network Policy，以及我们扩展了带宽限流。这样的话也是避免大家不知道怎么去做网络内部的POD跟POD之间的安全管控，以及去做POD之间的网卡的带宽的约束，避免一个POD可以打爆整个网卡，这样的话就会比较好的去保护你的网络。而这个只需要添加annotation就可以完成，不影响K8S的兼容性。
最后一个就是我们要去做灵活的弹性。所以做K8S有个说法，就是你不做弹性基本上就相当于没玩KBS。所以，我们给大家提供了一个完整弹性的体系。除了标准的HPA去做伸缩POS之外，我们实际上还提供了阿里云开源的CronHPA，就是定时的方式来支持大家去伸缩POD。我们还提供了额外的指标，来帮助大家按指标的方式来去做弹性伸缩。包括我们日服务SLS里面提供的Ingress Dashboard，拿到你的QPS，拿到你的Latency，或者我们从我们的Arms，或者Ahas拿到你的每一个POD流量的情况，每个POD延迟的情况来做对应的伸缩。
因为大家知道你的程序可能开发出来之后，不一定能那么好的完美地去适配CPU。也就是说不是你所有的POD都能够按照CPU的方式来做伸缩，这个时候你就需要根据我们提供的额外的指标的方式来做伸缩，这是公有云里面给大家一个比较好的弹性的方式。
另外一个问题就是，当你的资源不够的时候，你可能就需要买更多的机器来支持容量，这个时候我们提供了Autoscaler，它会对接阿里云的ESS来帮助大家自动化的方式来够买机器，然后再重新扩容。所以通过这种方式，来帮助大家做好自动化的运维。
但是这里面也有另外一个问题，你可能希望这个伸缩速度会跟快。但是从购买台机器到冷启动再到加入K8S集群，然后再去扩容器这个时间会比较长，如果你的业务是一个突发的业务的话，可能你等不及机器伸缩。所以为了适配这个场景，我们现在又融合了阿里云的ECI，我们利用弹性容器实例来做这个事情，我们做了一个虚拟化的Kubelet，来对接ECI。这个时候大家不需要再去买机器，你可以直接用扩容的方式去做就好了。
所以它最大的好处是什么？就是说你不需要额外买机器，你只需要根据你的业务的情况下，直接伸缩容器，它会到ECI的池子里面去找到对应的空闲的容器，然后挂到你的集群里面去。当你不需要的时候，它更快，它直接就可以释放掉了。因为大家知道，如果你是普通的方式，你还是等那台机器所有的容器全释放才可以释放机器，这个时候还有一个时间差。因为大家知道，弹性好最耗钱的地方就是时间。所以就是我们用最块的方式来帮大家去节约掉这个成本。同时大家如果用这样的方式，还可以不需要去做容量规划。因为大家知道，很多时候很难做容量规划。如果今天有100QPS，明天又有1000个QPS，我不知道这个容量怎么做，这个时候可以利用ECI的技术，大家就可以避免这个容量规划了。
当然我前面提到，阿里云ACK制定了很多自定义的指标，所以大家只需要去配置对应的定制指标，根据QPS也好，平均Latency也好，还是P99、P999这些相应的最大延迟指标，以及你的入口流量的指标，来做相应的伸缩。所以大家只需要根据这些指标来配置对应的HPA的扩容的伸缩就可以了。所以这样的话，大家比较容易的去找到适配你业务场景的方式。特别是对电商的场景的话，大家很多时候去根据QPS做是比较合理的，如果大家比较有经验的话。
另外，伸缩不是做某一个业务/应用的伸缩。所以大家一定要记住一点就是，伸缩一定是一个一体化的联动性的伸缩，所以大家一定要从接入层到服务层同时考虑伸缩性。所以我们利用了Ingress Dashboard的指标(后面监控会提到)，拿到了QPS，可以伸缩我们的接入层，同时我们可以根据APM的系统，就是像阿里云的ARMS这样一个系统，拿到对应的Latency来伸缩我们服务层。这样的话，大家可以构造一个联动性的全局性的伸缩。不然的话，很可能你在入口层面上做了一次伸缩，直接把流量倒了进来，最后打爆了是你的服务层。
所以大家一定要考虑这一点，就是所有的伸缩一定是联动性的全局性的。
这是前面讲了，我们怎么去更好地去做管理，以及我们有什么好的方式来提高我们的性能。第三部分的话给大家讲一下怎么去做防守，主要有三部分。1、怎么做智能化运维。
2、怎么做安全体系。
3、怎么去做监控体系。
从管理角度来讲的话，大家不可或缺的点就是大家一定要去做灰度。从接触的情况来看的话，很多同学实际上并没有完全做到全灰度才上线，但是在阿里云是强制的要求。所以在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审计日志方向，我们过会儿讲一下。包括我们会有更严密的KBS的这种安全的配置，以及我们会去做容器运行时的实时安全监测。所以大家有兴趣的话，可以看看阿里云安全的产品，他们已经支持了安全运行态的这种实时的检测。
同时我们还支持安全的管控，就是所有的安全配置我们都是双向认证。特别强调一点就是从管理层面上来讲的话，我们会做好对应的整个平台的安全的管理。这里更多的是针对内控。大家知道，实际上真正能偷盗你数据那个人，最容易的那个人是你们公司运维里面最有权限的那个人。所以，这里面才是大家日常需要重点管控的一个地方。
我们把所有能够接触到K8S的所有的入口，我们都做了一层安全审计。除了安全审计落日志的同时，我们还提供了很多预置的安全的审计项来帮助大家做预警。这里举一个例子，就是假如你的K8S如果有安全性的入侵，有人进入你的容器，我们会给大家落审期日志，包括到底是哪个用户用了什么命令进入了哪个容器。同时大家可以去配一个钉钉告警，这样一分钟内我们会把这个告警给告出来，这样的话大家可以知道，有人进入你的容器环境了。
这样确保整个K8S环境足够的安全。原则上是这样的，就是大家去用K8S的时候，在生产系统里面不应该在有人能够进入容器，所以一定要提醒大家做一点的防范。
另外一点大家比较难做的地方就是人员的变动。如果人员的变动之后，他这个人对系统在之前的时间内做过什么事情，大家有没有清楚？所以，同样的道理，我们会提供人员审计视图，根据人员子账户进行搜索审计的信息。这样的话，大家对内的安全管控是比较容易去做的，你只需要输入他使用的子账户名字，我们会帮助你把他所有K8S的操作都列出来。这样就是避免有人偷你的数据到外面去了，而不是两三个月后你还不知道。所以这个是帮助大家去做好人员离职的管控。安全层面上的话，大家务必要把审计日制这个事情看得比较重。
最后给大家讲一下，我们怎么去做整个监控体系，以及整个链路分析体系。整个监控体系的话，是非常的庞大。因为大家知道，很多同学在IDC里面自建K8S也好，还是在云上玩也好，只会去考虑Prometheus监控架构为主。但实际上，在上完阿里云之后，会帮助大家做好整个K8S的监控体系以及链路分析。
首先是我们从全局的角度来讲，会去给大家展示一下你整个KBS层面上，到底有多少个网络单元有多少个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的方式去看相应的数据，去做相应的告警。这些都是在后台做了，跟你整个集群没有任何关系，这样你的集群资源是最节约的也是最稳定的。
今天大概就这样给大家分享这几部分，谢谢大家！
