本文来源于阿里云社区电子书《阿里云产品四月刊》
《阿里云产品四月刊》—享道出行：容器弹性技术驱动下的智慧出行稳定性实践（2）https://developer.aliyun.com/article/1554124
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 的启动时间。
《阿里云产品四月刊》—享道出行：容器弹性技术驱动下的智慧出行稳定性实践（4）https://developer.aliyun.com/article/1554122
