cost webhook 和 cost scheduler两个组件，本质上是为了实现成本感知调度，也就是将指定比例的Pod调度到spot虚拟机上，指定比例的Pod调度到按量付费\包年包月的虚拟机上，达到既节约成本，又能平衡可用性。
从实现角度来说，最简单的方式就是CRD+operator模式，用户使用时声明总共的副本数和spot实例的副本数，operator即可按照用户的期望将固定比例Pod的node selector选择为spot虚拟机。
然而，Kubernetes及其声明式API模式的原则之一是，“牺牲小我，完成大你”， 也就是说将负责的事情全部由Kubernetes来做，用户只需简单的声明即可。本着这样的原则再来思考，这种CRD+operator的模式虽然简单易行，但是对于用户而言，就不那么友好了，用户是平台开发者甚至是应用开发者，学习并掌握了Kubenretes的副本编排控制器如Deployment、Statefulsets等的使用配置参数，已经撸起袖子开始使用了，突然告诉用户一种新的配置，对于Paas平台开发者或者应用开发者，都是不那么友好的。因此，思考一种对用户更优雅的实现，还是很有必要的。
cost webhook 和 cost scheduler正是基于Kubernetes原生的Deployment而设计，在使用时，用户只需要将Deployment打上熟悉的annotation，如 pod-on-spot-instance=70%，cost webhook 和 cost scheduler即可完成将70%的Pod调度到spot实例，将30%的Pod调度到按量付费\包年包月实例上。
How Cost webhook works具体来说，cost webhook 是基于 Kubernetes 提供的动态准入控制机制实现的一个 webhook，用户请求到达API Server后，以此经过路由、认证、审计、鉴权等流程，而审计包括Mutating和Validating两个阶段，前者用于对API资源继续修改，后者主要用于校验，如下图。
（图片来源：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/）
cost webhook 正是 Mulating 阶段的 webhook，在流程走到 Mutating 阶段被调用执行，cost webhook 监听Deployment 这种资源类型，判断annotation中是否包含上述提到的pod-on-spot-instance=70%信息，如果有，则将该 Deployment 所属的 Pod 的 Scheduler Name 修改为 cost scheduler，对于这些Pod的调度，就交给cost scheduler来完成。
How Cost Scheduler workscost scheduker 也是基于 Kubernetes 的 scheduker framework 扩展机制实现的自定义调度器。
（图片来源：https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/）
如上图所示，Schedule Framework 为我们提供了多个扩展点，比如 preFilter、Filter、Score等等，可以在调度的各个环节实现自定义扩展。cost scheduler 主要基于 Filter 进行扩展，将Pod分为适合调度到spot实例和适合调度到非spot实例。
spot-controller - 持续稳定的算力交付看到这里，可能您还有个疑问还没有得到解答：是否有自动化的方式可以抵消回收带来的对业务的潜在影响？Spot-controller 可以回答这个问题，它定义了一种算力交付的方式，将维持期望状态的能力从应用层扩展到了资源层。
用户无需关心资源购买过程，只需定义期望资源的状态（规格、可用区、计费类型）等，spot-controller 会自动供应资源直至满足客户期望。
spot-controller 在实现上采用了 CRD+operator 的模式，用户只需填写一份CR并提交到 Kubernetes 集群，spot-controller 则监听该CR，负责集群node资源的新增和删除，当然，这需要拥有 IaaS 层虚拟机的创建和删除权限。
从功能模块来看，Spot-Controller 的功能模块分为以下几个部分：
混合算力供应 —— 抵消竞价实例可能回收/库存不足带来的算力不足的风险
用户可指定部分按量算力作为竞价实例的算力补充，即稳定的算力buffer
用户可指定多种机型规格，降低某种机型售罄的潜在风险
用户可指定多可用区，作用和配置多机型规格类似
灵活的供应策略 —— 满足不同的本质需求
多可用区打散策略 （在您配置的多可用区内平均供应算力，达到高可用）
容量高可用策略（优先扩容资源库存最高的实例规格，达到高可用）
成本优化策略 （优先扩容成本最低的实例规格，具有最优的成本优化效果）
释放闲置资源 —— 极致的弹性伸缩