本文来源于阿里云社区电子书《阿里云产品四月刊》
《阿里云产品四月刊》—享道出行：容器弹性技术驱动下的智慧出行稳定性实践（3）https://developer.aliyun.com/article/1554123
在享道的集群架构中，存在采集微服务日志的场景，日志采集器会在 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 的
趋势时，即会触发弹性扩容，能够更好地应对突发流量，保障业务稳定性的同时，也能 够实现可观的降本效果。
作者：郑嘉扬、何杉
