分享人：弦望 阿里云智能业务支撑平台解决方案架构师
易欢 ECI产品经理
正文：本文从三方面来介绍基于ECI的ACK集群高弹性架构最佳实践。
Ÿ 最佳实践原理讲解
Ÿ 最佳实践核心产品ECI讲解
Ÿ 最佳实践系统搭建
一、最佳实践原理讲解
1）基于ECI的ACK机器高弹性架构-场景描述
核心场景是用户原有的业务部署在K8S集群上，在K8S集群上运行常规业务。当业务突发波动时（如秒杀活动），让突增的业务运行在ECI实例上。随着业务波动动态创建或释放ECI实例，达到成本的最优控制。业务方无需管理节点和容量规划，依托ECI和ECS资源共持，做到全自动实现容器“无限”弹性扩容，以下这几个场景非常适合使用本方案：
Ÿ Long-Run类业务，例如：业务生产系统。
Ÿ 明显的业务弹性诉求，例如：爬虫、秒杀、大促等。
Ÿ 离线job类任务，执行完即释放的应用。
2）基于ECI的ACK机器高弹性架构-系统架构图
本方案使用K8S集群部署系统应用，应用系统后端数据库使用云上RDS和Redis，存储使用NAS，常规业务跑在ACK集群上，弹性业务如大促场景使用虚拟节点扩容到ECI上，做到秒级无限扩容。
本方案的优点是：
Ÿ 成本非常低，使用ECS和ECI混合部署，平时的业务使用ECS承载，弹性业务使用ECI承载，ECI与真实节点中的Pod互联互通，做到按需使用和计费。
Ÿ 弹性部分按使用量、秒级弹性扩容，具资源池足够大。
Ÿ 支持比例或数量指定ECS和ECI部署，按实际业务需求动态调整。
这个方案有几种使用方法：
Ÿ 使用Virtual-kubelet-autoscaler，可以在资源不足时，自动弹性伸缩到ECI上，即ACK集群资源满了自动弹性到ECI上。
Ÿ 使用Namespace label，指定Namespace下的pld调度到ECI，可以做到不同Namespace应用分别部署到ACK和ECI.
Ÿ 使用OpenKruise，可以指定pod的部署拓扑，指定个数pod分别调度到ACK或ECI上。
Ÿ 使用Taints和Tolerations可以指定deployment 或者pod调度到ECI上。
3）Virtual Node弹性伸缩示意图
Virtual Node在ACK集群中是通过API server进行交互的，VK支持动态创建POD、SLB和DNS entry，这里DNS解析使用阿里云的private Zone内网解析。当HPC controller监听到POD、Service、Ingress等资源变化时，弹性伸缩POD，根据配置的策略伸缩到ECI或ECS上，HPA的策略会在物理Node不满足的前提下再弹ECI，同时也会优先回放ECI的POD，做到资源的合理利用及秒级弹性。
4）基于ECI的ACK机器高弹性架构-方案优势
Ÿ 支持混合部署，平时稳定业务使用ECS承载，节省成本，弹性业务使用ECI承载，无需执行弹性部分，弹性业务使用ECI承载，无需执行弹性部分容量规划。
Ÿ 与真实节点中的Pod互联互通，并且支持VM级别的安全加固和资源隔离。
Ÿ 弹性部分按使用量付费，按秒收费，降低成本。
Ÿ 资源池无限容量，秒级弹性扩容，快速承载流量。
Ÿ 使用预留实例能降低使用成本，最高可以降低70%以上的使用成本。
Ÿ 支持HPA和CronHPA，满足不同场景的弹性需求。
5）ECI弹性容器实例
目前K8S在阿里云的使用有三种形态，一是K8S on ECI，二是K8S on ECS，三是K8S on 神龙，那么这三种形态有什么核心差别呢？K8S on神龙我们交付给客户的资源是裸金属服务器，它的性能无虚拟化损耗，但是宕机影响的POD数量较多，POD之间的隔离较弱。
K8S on ECS对比神龙有一定的虚拟化损耗，但是弹性能力较好，故障时影响半径较小。
K8S on ECI，我们以POD的形式交付资源，客户只需要为容器POD部分使用付费，底层资源完全免运维，不需要管理节点，具有最强的弹性能力，同时故障影响的范围最小，仅单POD，并且使用安全容器做到POD之间的强隔离。
二、核心产品ECI讲解
1）阿里云容器计算服务
提到容器计算服务，大家比较熟悉的是我们现在经常听说的ACK这款产品，也就是容器服务提供的托管版Kubernetes服务，它底层使用的是咱们弹性计算提供的ECS计算资源，那么ECI是弹性计算团队在2018年开始提供的一款新型的针对容器场景的、容器资源类服务。它最大的特征是原来用户在阿里云上跑容器，首先需要购买一台ECS，并且为这台ECS付费，ECI的用户不再需要购买和管理ECS，就可以直接在阿里云上运行他的容器和Pod，并且他只需要为他运行的容器资源付费。
2）ECI作为虚拟Node，加入已有ACK Kubernetes集群
在使用方式上面，ECI可以作为一个虚拟的节点加入到用户已有的K8S集群里面，加入进去后，我们可以看到在集群的节点列表里面出现一个虚拟的节点，这个方案的优点在三个方面：
Ÿ 低成本，平时客户常态业务使用ECS包月来承载，弹性部分使用ECI虚拟节点承载，这样客户不需要预留弹性部分资源和容量规划工作了，可以极大的节省资源的成本。
Ÿ 在整个弹性伸缩的过程中，ECI可以做到秒级的弹性扩容的能力，这样客户就可以根据客户实际业务流量，进行弹性伸缩的操作和控制。
Ÿ 高并发的能力，ECI支持给每个用户1000每分钟Pod调度能力，满足绝大部分客户的弹性诉求。
这个方案比较适用的场景，首先第一个是在线业务的弹性，比如在线教育行业，泛互联网行业APP，以及电商行业，这些行业的业务特征是具有日常的弹性流量，包括突发的弹性流量诉求，都可以使用ACK加虚拟节点的方式来承载，另外一块就是现在比较火热的大数计算及AI计算的能力，这部分业务的特征都是job计算任务，都是可以直接放在ECI上面进行承载。
3）ECI适合弹性和并发场景的业务，支持业务托管
所以ECI作为一款基础设施计算类产品，特别适用于容器场景下高弹性、高并发业务的支撑。
ECI首先是一个Serverless的产品，是一个免运维的产品，其次在弹性、成本、效率上相比ECS有一定程度提升，它也是一个完全兼容Kubernetes的基础设施产品。所以在容器化的在线业务弹性、AI推理和训练、大数据计算、自动驾驶的仿真计以及现在特别火热的在线教育和短视频的音视频编解码，包括直播流的录制事件上，以及普通Job任务、自动化测试场景上，能够很好的支撑客户业务把效率提升上去，把成本降下来。
三、基于ECI的ACK集群高弹性架构最佳实践
进入CADT以后，通过官方模版进行新建，这是方案的架构图，里面使用了ack、virtdal、rds、NAS，这是一个基础的架构。
我们看一下相关配置，集群名称、网络插件可以根据需要配置调整。
进行rds，nas配置。
调整完之后进行应用部署，首先验证一下资源，看是否可以购买，这些参数是否正确，先做一次验证，目前我们可以看到的所有的结果都是成功的。
再去做一个价格的评估，会列出预付费的资源和后付费的资源，以及产生的价格、帐单。
把协议勾选上，可以创建资源。
等待资源创建，可以看到所有的资源都部署完成了。
在资源列表里直接点击资源名称，直接进入到相对应的资源控制台。
进入挂载使用，添加挂载点，选择创建的vpc，选择交换机，默认权限，确定。
这里已经生成了挂载地址。
接下来去配置rds的白名单、数据库帐号等，进入rds，设置白名单。
我们可以通过安全组来添加白名单，把刚创建的安全组添加到白名单里面。
添加完之后，我们可以在查看连接详情里面rds的内网地址。
创建数据库帐号。
再创建一个数据库，后面以wordpress为例，创建一个wordpress数据库。
资源都已经创建完成了，进入到ack集群。
首先创建一个命名空间，作为资源隔离的一个空间，创建一个新的命名空间，叫做wordpress，确定。
接下来在无状态应用里面进行应用部署，我们选择命名空间，在wordpress下面。
去使用镜像创建应用，对资源做了一个评估，在集群上能使用22个副本，我们这是个测试，先创建22个副本。
选择镜像，在镜像上搜一下wordpress镜像。
选一个tag，版本非常多，选择一个适合自己的，这里选latest最近的版本。
挂载到主径目录下，先把它删掉。
接下来创建一个服务，创建一个service，这里面使用负载均衡，新建一个负载均衡，策略选择local，输入名称sp-svc，端口80。
应用已经创建成功。
接下来看无状态的应用里面，选择Yaml。
已经把latest的路径挂载到容器里面了。
接下来对应用进行部署，我们找到服务，我们刚刚创立的这个服务，点进服务里面。
对应用类型的一个初始化的安装，我们选择简体中文，继续。
现在可以看到数据库就是wordpress，这里使用在数据库存里的用户名、密码，数据库的地址可以看下rds控制台，拷贝内网地址，粘贴过来，提交。
开始安装。
安装完成之后需要设置站点名称，名称为ECI高可用Demo，用户名myuser，设置密码、邮箱，勾选建议搜索引擎不索引本站点，安装。
我们再登陆一下wordpress。
成功登陆后，我们发表一篇文章，测试一下。新建文章，这个测试有点慢，输入标题，这是我测试的demo，发布。可以看到应用系统已经正常使用。
开启eci实例的服务，我这边已经开通了。如果没有开通，进入到eci的控制台会提示让开通这项服务的。
接下来在容器服务里进行配置，找到命名空间。
给命名空间设置一个注解，添加变量的名称，具体可参考文档复制过来，添加，确定。
这里就添加了一个虚拟节点的标签。这样我们应用在弹性伸缩的时候，就会伸缩到命名空间弹到ecs上。
接下来进行虚拟节点的安装，找到应用目录ack-virtual-node，进行安装。
这里参建需要配置一下，安全组、AK的信息。在vpc里找一下，我们创建vpc。
可以看下交换机这里的ID，复制。
粘贴到这里。
进入安全组列表。我们使用容器里创建的案例组。
再去配置AK的信息，把AK复制过去。
把secret复制一下，粘贴过来，创建。
这样虚拟节点就部署好了。可以看到当前的虚拟是StatefuSet，如果在虚拟节点不够用的话，也可以部署多个虚拟节点，进行伸缩就可以了。
进入集群，在virtual-node应用里进行伸缩，进行多节点的伸缩。
我们可以创建多个virtual-node节点，通常一个节点可以支持3000个word，数量特别大的情况下，virtual-node的节点进行相应的调整。
接下来看一下节点，virtual-node的节点是可调度的状态，说明我们当前的
部署是正常的。
然后回到wordpress应用，进行简单的伸缩测试，比如刚才是22个，要伸缩到30个。
伸缩完之后进入到应用，已经有word在pending状态了。可以看到pending已经被调度到virtual-node的节点了。新增的全部调度到eci上了。
可以看到当前的pond已经eci实例里面了。刚才是22个伸缩到30个，有8个pond已经跑到eci上了。
刷新后，看到是正常运行的。
如果我们要缩回去是一个什么状态，把30个缩回到22个。
可以看到应用被正常的释放。
现在模拟正式的环境，假如业务有大量流量进入的时候，我们可以看下业务的表现情况。在控制台上，找到集群里面的节点，可以看到当前节点的CPU的情况，request有的是28.13%，有的是35.63%。
比如我们要做同一伸缩的时候，要利用节占的CPU的资源，建议不要超过60%，所以我们在伸缩的时候进行根据CPU的一个配置进行伸缩，可以在无状态应用里面，对容器进行伸缩，可以去配置HPA，配置CPU的指标，让CPU使用量不要超过60%，最大是100个，最小是22个，确定。
我们就已经创建了HPA的控制器了。
接下来进入到pts的控制台，对业务进行模拟的压测。
这是我们的网站的IP地址，去创建压测场景，场景名改为wp-test。
我们进行施压的配置，最大并发上限是1000，递增10%，时长1分钟，测试10分钟。
这时候可以去保存压测。
回到容器控制台看一下弹性伸缩的情况。可以看到已经在伸缩了，被调度到eci上了。
虚拟节点容器已经在pending状态了。
随着我们流量的加大，访问的压力越来越大，伸缩的数量会越来越多，目前是44个。
下一步是已经往83伸缩了。
通过我们的压力不断加大，容器数量会达到我们的上限，目前已经100个了。
通过这种方式我们可以看到整体请求的成功率的情况。应用系统随着流量的增加，不断进行自动地扩容，承接更多的流量。
我们可以看下测试报告，在这里可以看到业务的请求率，业务的响应的情况，TPS并发的情况。
接口异常的情况，流量加大没有及时扩容，导致超时的情况，我们可以通过TPS进行观察。
如果把实践做完，或者在生产的时候要释放资源，我们刚才已经一键创建了这些资源，同样地可以进行一键销毁，在应用里点释放资源，可以看到已经在启动释放了，我们待到所有资源释放完，今天的实践就结束了。
