作者：郑嘉扬、何杉
前语
享道出行是一家专心于出行服务的专业品牌，是上汽集团完成汽车产业“新四化”（即“电动化、智能网联化、同享化、国际化”）的重要组成部分。作为上汽集团移动出行战略品牌，享道出行充分利用全产业链竞赛优势，从消费者对安全及质量的需求动身，经过为消费者供给安全、高效、舒适、便捷的质量体会，打造质量出行服务平台。
在快速的事务开展过程中，基础设施规划的不断增长，为企业办理者带来了关于效率和本钱的高度重视。容器技能作为云计算时代基础设施的中心，天然成为了咱们重视的焦点。跟着容器技能及其生态的不断老练，关于企业级开发者来说，在进步布置速度、优化资源利用率以及降低环境间差异等方面展现出了巨大的潜力。然而，跟着容器数量的激增，怎么办理和调度这些容器也成为了一个应战。
事务架构与痛点
当前事务开发主要选用 Java 技能栈，运用布置架构如图所示：
中心痛点
- 现在运用的 Kubernetes 原生 HPA 弹性扩缩容计划以及 CronHPA 计划，在容器算力预备阶段流程长，包括算力资源预备、调度、镜像拉取、容器创立、容器启动以及运用启动导致冷启动基本是分钟级弹性。
- 无法承接预期外流量，流量丢失对事务有感。
- 需求运维人员经过编码、保护程序主动化测算出产环境资源水位，评估扩缩容阈值，运维本钱较高。测算结果不行精准也会导致资源糟蹋或影响事务安稳。
处理计划
针对以上痛点，为处理弹性滞后的问题一起统筹本钱最优，计划如下：
- ACK AHPA 智能弹性
- ECS、ECI 混合布置
作为出行职业，享道的事务特征具有明显的潮汐效应，经过弹性架构改造，咱们可以充分发挥云弹性算力的优势，进一步提升了事务自身的容错性。
ACK 智能弹性（AHPA）
针对传统弹性才能所存在的问题，在计划设计阶段咱们选用了 阿里云ACK 容器服务推出的 AHPA（Advanced Horizontal Pod Autoscaler）弹性猜测，可以依据前史 Pod 的 Ready Time 以及前史 Metrics 主动学习规律，在事务量上涨之前的一个 Ready Time 开始扩容，在事务量上涨时 Pod 已提早预备，可以及时供应资源，处理弹性滞后的问题。
AHPA 弹性猜测依据前史数据主动规划未来 24 小时每一分钟的运用实例数，相当于进行 1440 个点（一天为 1440 分钟）的 CronHPA 定时配置。
预先扩容
因为事务具有很强的潮汐属性，每日的涨潮落潮时刻比较固定，AHPA 会依据过往的数据推测之后的所需求的 Pod 数量。例如，服务A依据以往双休日状况猜测出这个双休日或许呈现的 Pod 数量最大值为 16，那么就可以预先扩出来满意这些额外 pod。
ECS、ECI 混合布置
如前文所述，AHPA 只可以处理运用层的弹性滞后问题，并不能提早对底层资源是否满意提早做出判别。这也意味着当底层资源缺乏时，仍存在使运用扩容时刻被无限拉长的风险。
弹性容器实例 ECI（Elastic Container Instance） 作为一种纯 Serverless 容器运转服务，关于用户而言，无需办理底层服务器资源，相同也不需求关怀运转过程中的容量规划，只需求供给打包好的 Docker 镜像，即可运转容器，十分合适应对这种流量突发场景下的事务场景。
但从本钱性上讲，单位价格会相对裸金属 ECS 较贵，该计划结合了各付费形式和底层架构的优势，当前采纳混合布置形式，统筹本钱及安稳性两方面的事务方针。如下图所示，未来方针是一半以上的运用作为事务基线布置在裸金属 ECS 上，关于周期型运用布置在按量付费的 ECS 资源，结合出行职业迟早顶峰，剩余 10% 以上的场景均经过 ECI 实例保障。
注： ECI 的计算资源与 ECS 等实例彻底解耦，在每个可用区有独自的资源划分给到 Serverless 架构相关产品，关于大部分场景（CPU 数不超过 1 万 Core），无需担心资源缺乏的状况产生。因而 ECI 也是一种相对牢靠的算力容量保障手段。
自定义弹性资源优先级调度
在资源的调度战略上，因为选用了 ECS 及 ECI 两种布置形式，咱们希望运用扩容和缩容行为都是确定性的，当运用需求布置一个 Deployment，此刻集群中有对应的多种类型的资源，分别是包年包月的 ECS、按量付费的 ECS 和弹性实例 ECI。
那么，布置的服务优先调度次序理论上依次为：包年包月的 ECS、按量付费的 ECS、弹性实例 ECI。 一起在服务缩容时优先删去 ECI 上的 Pod，释放 ECI 的节点资源，然后删去按量付费的 ECS 上的 Pod，最终删去包年包月的 ECS 上的 Pod。
关于包年包月及按量付费两种不同付费类型的节点需经过打上不同 label 标签完成。然后创立 ResourcePolicy 自定义节点池调度次序。
ResourcePolicy 配置示例：
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: DEMO
namespace: demo-ns
spec:
units:
- max: 15
nodeSelector:
env: prd
resource: ecs
- max: 5
nodeSelector:
foo: bar
resource: ecs
- resource: eci
whenExceedMax: NeverEvict
这儿详细的调度战略可依据实践事务场景区别，若关于本钱不敏感，且事务的波峰波谷颤动较大的场景，也可以考虑当 ECS 资源缺乏时，运用 ECI 弹性资源，然后加速 Pod 的启动时刻。
向虚拟节点 Pod 注入 Sidecar 容器
在享道的集群架构中，存在收集微服务日志的场景，日志收集器会在 ECS 节点上经过 DaemonSet 方式布置 Agent，但虚拟节点不是实在节点，不支持运转 DaemonSet Pod，怎么让调度到虚拟节点的 Pod 也支持上述 Agent 的平等才能呢？答案是向虚拟节点 Pod 注入 Sidecar 容器。
在施行过程中，咱们希望做到：
- 保护一份 Deployment 发布模板。在资源调度布置时，主动对底层 ECS 和 ECI 做区别，当 Pod 被调度到 ECS 节点时，无需注入 Sidecar 容器，当 Pod 被调度到虚拟节点时，则主意向 Pod 中注入 Sidecar 容器，然后完成经过保护一份 Deployment 发布模版，即可一起满意不同架构下的兼容性需求。
- 对已有存量事务入侵尽或许小。依据软件设计开闭原则，应该对修改封闭，避免改动线上现已运转安稳的存量事务（如 DaemonSet），只添加新的或对新增内容做改变。
运用一个 Deployment 在原生 K8s 架构中无法做到，原因是添加 Sidecar 容器需求修改 Pod Spec，而原生 K8s 架构中 Pod Spec 落到 etcd 之后就不允许修改了，但 Pod 是否调度到虚拟节点是在 Pod Spec 落到 etcd 后由调度器决定的。因而，运用 OpenKruise 原生 SidecarSet，因为选用 Admission Webhook 机制，在 Pod 创立阶段经过 Label 的匹配所有契合条件的 Pod，此刻 Pod 还未调度到虚拟节点，无法仅对调度到虚拟节点的 Pod 生效。
注： SidecarSet 是阿里云开源的云原生运用主动化引擎 OpenKruise 的中心功用之一。运用 SidecarSet 可以为集群中创立的契合条件的 Pod 主动注入 Sidecar 容器，完成 Sidecar 容器（如监控、日志等 agent）的定义和生命周期与事务容器解耦。
虚拟节点支持 SidecarSet就是专门用于处理该问题。凭借虚拟节点组件（ACK Virtual Node）仅为调度到虚拟节点上的 Pod 主动注入 Sidecar 容器，来解耦虚拟节点 Pod 的 Sidecar 容器与事务容器。其原理如下图所示：
经过标签 Serverless.alibabacloud.com/virtual-node:”true” 指定，该标签会在 Pod 确定调度到虚拟节点后主动打上。一起，该计划与 OpenKrusie 原生 SidecarSet 彻底兼容，关于后续 Sidecar 容器的晋级、运维等操作，仍可以继续运用OpenKrusie原生 SidecarSet 完成。
自定义弹性目标
如上文所述，根据 CPU/内存的弹性目标无法同实在事务作业杂乱彻底拟合。很多场景下，用户希望依据自定义目标对运用进行扩缩容。AHPA 所供给的 External Metrics 机制，结合 alibaba-cloud-metrics-adapter 组件，可以为运用供给更丰厚的扩缩容机制。
事务价值
当前享道出行现已规划化上线智能容器弹性才能，在保证安稳性的前提下，大大节省了资源本钱，并能很好地应对突发流量。 如图所示：当阈值设置为 50，目标有到 50 的趋势时，即会触发弹性扩容，可以更好地应对突发流量，保障事务安稳性的一起，也可以完成可观的降本作用。
