EKS如何应对突发流量
本篇内容介绍了"EKS如何应对突发流量"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
前言
混合云是一种部署形态，一方面企业可从资产利旧、成本控制、控制风险减少锁定等角度选择混合云。另一方面企业也可以通过混合业务部署获得不同云服务商的相对优势能力，以及让不同云服务商的能力差异形成互补。 而容器和混合云是天作之合，基于容器标准化封装，大大降低了应用运行环境与混合云异构基础设施的耦合性，企业更易于实现多云/混合云敏捷开发和持续交付，使应用多地域标准管理化成为可能。 TKE 容器团队提供了一系列的产品能力来满足混合云场景，本文介绍其中针对突发流量场景的产品特性--第三方集群弹 EKS。
低成本扩容
IDC 的资源是有限的，当有业务突发流量需要应对时，IDC 内的算力资源可能不足以应对。选择使用公有云资源应对临时流量是不错的选择，常见的部署架构为：在公有云新建一个集群，将部分工作负载部署到云上，通过 DNS 规则或负载均衡策略将流量路由到不同的集群：
此种模式下，业务的部署架构发生了变化，因此在使用前需要充分评估：
哪些业务工作负载需要在云上部署，是全部还是部分；
云上部署的业务是否有环境依赖，例如 IDC 内网 DNS、DB、公共服务等；
云上、云下业务日志、监控数据如何统一展示；
云上、云下业务流量调度规则；
CD 工具如何适配多集群业务部署；
这样的改造投入对于需要长期维持多地域接入的业务场景来说是值得的，但对于突发流量业务场景来说成本较高。因此我们针对这种场景推出了便捷在单集群内利用公有云资源应对突发业务流量的能力：第三方集群弹 EKS，EKS是腾讯云弹性容器服务，可以秒级创建和销毁大量 POD 资源，用户仅需提出 POD 资源需求即可，无需维护集群节点可用性，对于弹性的场景来说是非常合适的。仅需要在集群中安装相关插件包即可快速获得扩容到 EKS 的能力。
与直接使用云上虚拟机节点相比，此种方式扩缩容更快，并且我们还提供了2种调度机制来满足客户的调度优先级需求：
全局开关： 在集群层面，当集群资源不足时，任何需要新创建Pod的工作负载都可以将副本创建到腾讯云 EKS 上；
局部开关： 在工作负载层面，用户可指定单个工作负载在本集群保留N个副本后，其他副本在腾讯云 EKS 中创建；
为了确保所有工作负载在本地 IDC 均有足够的副本数，当突发流量过去，触发缩容时，支持优先缩容腾讯云上 EKS 副本（需要使用 TKE 发行版集群，关于 TKE 发行版的详细介绍，请期待后续发布的该系列文章）。
这种模式下，业务部署架构没有发生变化，在单集群中即可弹性使用云上资源，避免了引入业务架构改造、CD流水线改造、多集群管理、监控日志统等一系列衍生问题，并且云上资源的使用是按需使用，按需计费，大大降低了用户使用成本。但为了保障工作负载的安全性和稳定性，我们要求用户的 IDC 与腾讯云公有云 VPC 专线互通，并且用户也需要从存储依赖、延时容忍度等多方面评估适用性。
EKS pod 可与 underlay 网络模式的本地集群 pod、node 互通(需要在腾讯云VPC中添加本地pod cidr的路由，参考路由配置)，第三方集群弹 EKS 已在 TKEStack中开源，详细使用方式和示例见 使用文档
实战演示
步骤
获取 tke-resilience helm chart
git clone https://github.com/tkestack/charts.git
配置 VPC 信息：
编辑 charts/incubator/tke-resilience/values.yaml，填写以下信息：
cloud:appID: "{腾讯云账号APPID}" ownerUIN: "{腾讯云用户账号ID}"secretID: "{腾讯云账号secretID}"secretKey: "{腾讯云账号secretKey}"vpcID: "{EKS POD放置的VPC ID}"regionShort: {EKS POD 放置的region简称}regionLong: {EKS POD 放置的region全称}subnets:- id: "{EKS POD 放置的子网ID}"zone: "{EKS POD 放置的可用区}"eklet:podUsedApiserver: {当前集群的API Server地址}安装 tke-resilience helm chart
helm install tke-resilience --namespace kube-system ./charts/incubator/tke-resilience/
确认 chart pod 工作正常
创建 demo 应用 nginx：ngx1
效果演示：
全局调度
由于此特性默认已开启，我们先将kube-system 中 的 AUTO_SCALE_EKS 设置为 false 默认情况下，ngx1 副本数为1 将ngx1副本数调整为50
可以看到有大量 POD 因为资源不足，处于 pending 状态 将 kube-system 中 的 AUTO_SCALE_EKS 设置为 true 后，短暂等待后，观察pod状态，原本处于 pend的pod，被调度到了 EKS 虚拟节点：eklet-subnet-167kzflm 上。
指定调度
我们再次将 ngx1 的副本数调整为1 编辑 ngx1 yaml，设置开启局部开关
spec: template: metadata: annotations: # 打开局部开关 AUTO_SCALE_EKS: "true" # 设置需要在本地集群创建的副本个数 LOCAL_REPLICAS: "2"" spec: # 使用tke调度器 schedulerName: tke-scheduler
将 ngx1 副本数改为3，尽管本地集群没有出现资源不足，但可以看到，超过2个本地副本后，第三个副本被调度到了EKS上
卸载 tke-resilience 插件
helm uninstall tke-resilience -n=kube-system
此外 TKEStack 已集成 tke-resilience，用户可以在 TKEStack 的应用市场中界面化安装 tke-resilience 
应用场景
云爆发
电商促销、直播等需要在短时间扩容大量临时工作负载的场景，这种场景下，资源需求时间非常短，为了应对这种短周期需求而在日常储备大量资源，势必会有比较大的资源浪费，且资源需求量随每次活动变化难以准确评估。使用此功能，您无需关注于资源筹备，仅需依靠K8S的自动伸缩功能，即可快速为业务创建出大量工作负载为业务保驾护航，流量峰值过去后，云上POD会可优先销毁，确保无资源浪费的情况。
离线计算
大数据、AI业务场景下，计算任务对算力亦有高弹性要求。为保障任务快速计算完成，需要在短时间能有大量算力支撑，而计算完成后，算力同样处于低负载状态，计算资源利用率呈高波动型，形成了资源浪费。并且由于GPU资源的稀缺性，用户自己囤积大量GPU设备不仅成本非常高，还会面临资源利用率提升，新卡适配，老卡利旧，异构计算等多种资源管理问题，而云上丰富的GPU卡型可为用户提供更多样的选择，即用即还的特性也确保了资源零浪费，每一分钱都真正化在真实的业务需求上。
"EKS如何应对突发流量"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！
