作者
王玉君，腾讯云后盾高级开发工程师，负责腾讯云原生零碎开发及建设。
晏子怡，腾讯云容器产品经理，在 K8s 弹性伸缩、资源管理畛域有丰盛的实战经验。
导语
Kubernetes 作为 IaaS 和 PaaS 两头的一层，通过申明式 API/ 控制器模式、以应用服务为核心、并且从 API 到运行时都提供了高度灵便的可扩大机制，为云厂商、各企业构建利用托管服务甚至云原生服务提供了对立的规范和基础设施治理的各项能力。
随着企业上云进入稳定期，老本管制 就是永远逃不开的话题。本文通过 Kubernetes 的扩大机制 Admission Webhook、Scheduler Framework 和 CRD+Operator，联合云上资源的特异性，介绍如何基于 Kubernetes 和云上环境构建老本控制系统。
TKE 的头部客户 S（离线计算场景），面对增长的客户月活以及相应剧增的计算需要，强烈心愿腾讯云容器服务能提供更低单价的算力和更弹性的架构。S 通过构建适合的老本控制系统，将月账单升高了靠近 80%（业务计算量雷同）。联合 S 的业务场景，咱们次要倡议 S 做了如下低成本革新动作：
通过 Spot Controller 配置了较高的竞价实例比例（靠近 90%），同时配置了 10% 左右的包年包月实例作为稳固资源的 buffer 池。因为 Spot 比例设置较高，为了加强资源供给的稳定性，S 配置了多种备选机型来扩充资源池的供给范畴，放弃回收频率在极低水平。
为了进一步保障业务的高可用，S 设置了多可用区均衡散布的扩容策略，来保障实例在多可用区打散散布。
为了保障弹性以及架构的容错性，S 同时应用了业务弹性伸缩(HPA)+ 资源弹性伸缩(节点池）来实现应用层弹性伸缩到资源层的弹性伸缩平滑过渡，同时也能够在业务低谷时主动开释闲置资源，进一步节老本。
为了应答极其状况下的回收状况，S 装置了 Spot Agent 来保障业务的优雅终止以及计算过程的断点续传。
WHY SPOT ? 咱们须要一种云原生的低成本算力
TKE 能力的底座是集群以及节点能力（底层依赖腾讯云的 CVM 实现），而 TKE 自身是不计费的，那么您购买节点时抉择的计费形式将极大水平上决定您的总体应用老本。
依据不同的应用场景，用户最常应用的计费形式为按量计费或者包年包月：
- 按量计费是一种合乎云计算理念的计费形式 —— 按需应用，弹性供给，秒级计费。
按量计费的这种按需应用的个性，和云上的弹性伸缩能力人造适配，很多用户也会搭配应用。 - 包年包月是一种更低成本的计费形式 —— 提前付费，降低成本
您在十分明确应用期限的状况下，能够以低折扣按月、按年、按周的形式购买实例。
那么，有没有一种计费类型，既具备云原生按量计费的个性、可能匹配弹性伸缩能力，又可能像包年包月实例一样提供较低折扣呢？竞价实例，就是这个问题的答案。
竞价实例（Spot）是云服务器 CVM 的一种新实例运作模式，它最外围的特点是折扣售卖和零碎中断机制。
竞价实例是三种计费模式中老本最低的一种应用形式（低至两折), 能够极大水平升高您的云资源收入。
但正如它的名字一样，您和其余同时应用竞价实例的用户存在肯定的竞争关系：在特定场景下，实例可能会被回收，咱们官网将这种回收定义为零碎被动中断（库存稳定）：以后阶段，在腾讯云的竞价实例模型下，仅会因为竞价实例资源池库存有余而产生中断。资源管控零碎会主动依据实时库存变动回收这些折扣售卖的实例。
当您胜利购买一个竞价实例后，它的应用和按量计费的 CVM 实例根本毫无区别，包含控制台操作、近程登录、服务部署、关联 VPC 等。
在丰盛的实际与摸索中，咱们发现，Spot 非常适合容器、无状态服务、CI/CD、强化学习、离线转码、大数据分析 等具备容错能力的业务利用，尤其是基于云原生框架构建的利用 ，在这些场景下能够在巨幅降低成本(80% 以上) 的前提下，保障业务的稳定性。
不惧中断 — 云原生框架保障业务稳定性
下面咱们曾经介绍了竞价实例的外围个性，可能您看到零碎被动中断这个概念，心里会浮现一些顾虑以及纳闷：
**- Q1: 回收机制是怎么样的？会提前告诉吗？
- Q2: 我想要节约老本，我能够做些什么来升高甚至打消回收带来的潜在危险吗？
- Q3: 是否有自动化的形式能够对消回收带来的对业务的潜在影响？
- Q4: 怎么判断我的业务是否适宜应用竞价实例？**
这几个问题，本文都会一一解答。咱们依靠于丰盛的实战经验，基于 Kubenetes 构建了云上老本控制系统，利用弹性供给能力以及云原生的维持业务冀望状态的能力，定义且实现了一种低成本且稳固的算力交付模式。
● 竞价实例在被零碎回收前的 2 - 5 分钟（不同云服务商配置的工夫不统一），都会收回回收信号、或者以虚拟机元数据信息的形式体现进去，TKE 基于 云原生的优雅终止以及 Workload Controller 维持利用冀望状态 的个性，无效升高了回收的危险，在感知回收信号后，能够优雅终止竞价实例上运行的利用正本，同时主动创立新的副原本满足业务冀望状态。
● TKE 将 维持冀望状态 的能力从应用层扩大到了资源层，用户无需关怀资源购买过程，只需定义冀望资源的状态（规格、可用区、计费类型）等，spot-controller 会主动供给资源直至满足客户冀望。
老本控制系统概述
上图是整个老本控制系统的架构图。
在介绍零碎各组件前，先提一下位于架构图最上面的资源池这一层，其中最次要的一种资源是竞价实例(Spot)，各个支流云厂商都有提供，所谓竞价实例（Spot）。
竞价实例是用户能够间接购买的，而碎片资源，则是指一些长期闲置的资源碎片，因为规格起因始终未被申请到，这些资源往往须要具备 IaaS 层操作权限，所以比拟适宜云厂商来应用，作为普通用户，应用竞价实例池即可。
整个零碎由三局部组成，tke-spot-agent、cost-wehbhook+ cost-scheduler，以及 spot controller，这三局部是齐全松耦合的，比方局部业务在后期只应用了 tke-spot-agent.
● the-spot-agent 以 deamonset 的形式运行在每台 Node 节点，用于监听竞价实例的回收信号，从而实将节点 Disable 以禁止调度新的 POD，优雅驱赶 POD 等。
● cost-webhook+cost-scheduler 是中心化的，每个集群只需部署一套，用于拦挡用户申请，将用户申请通过自定义调度器调度，满足指定比例的 Pod 被调度到竞价实例。
● spot-controller 也是中心化的，每个集群一套，用于解决用户配置的 CRD 资源，调用云厂商提供的购买机器的云 API 进行机型的购买，用户得以依照一个简略的形容文件申明集群所需竞价实例的配比，从而管制老本。
通过以上三个组件，别离实现了竞价实例被回收前的优雅解决、用户对不同业务场景下将 Pod 按比例调度到竞价实例上的老本感知调度、对用户的老本申明进行协调控制。
tke-spot-agent – 业务的优雅终止以及平滑迁徙
上文提到，竞价实例在被零碎会收前的 2 - 5 分钟（不同云服务商配置的工夫不统一），都会收回回收信号、或者以虚拟机元数据信息的形式体现进去，针对这个云厂商普遍存在的敌对预警机制，咱们能够提供一种守护服务，时刻监听这个来自 IaaS 层的预警信息，提前做一些解决，将业务利用容器无损的迁徙到其余虚拟机上。
从架构上来讲，这种守护服务，最优的形式是以中心化的模式运行在集群中，也就是一个 Kubernetes 集群只需运行一个这样的 Pod，最多通过选举机制启动一个 standby 容器做高可用，然而这样的前提是，Iaas 层的预警机制可能以对立的音讯发送过去，目前各大云厂商也只有极少数提供了这样的产生音讯的机制，只是在虚拟机元数据信息中做了体现，而且该信息只能在虚拟机的节点上查问，思考到以后阶段的广泛适用性，咱们目前将该服务以 Kubernetes daemonsets 的形式部署在每一台 spot 机型上。
云厂商虚拟机的元数据信息，能够在虚拟机上以 HTTP 的形式获取，该守护服务启动后，一直的监听该 spot 虚拟机的元数据信息，当发现回收信息后，首先调用 Kubernetes API 将该虚拟机的调度状态设置为不可调度，避免新的 Pod 被调度到这台行将被回收的虚拟机上。紧接着，守护服务通过 Kubernetes API 获取到以后节点上所有的 Pod，对这些 Pod 发动驱赶命令，Kubernetes 为每个 Pod 配置了默认优雅退出工夫，这个值是 30s，有些业务利用的场景可能在 30 秒内难以解决完手头的事件，守护服务在向 Kubernetes API server 发动申请时，能够携带一个叫做 DeleteOptions 的 Kubernetes 资源属性，能够将优雅退出的工夫进行用户自定义，当然，这个工夫，设置为大于 IaaS 层对 Spot 虚拟机回收工夫（2- 5 分钟）就没有意义了，Pod 还没有优雅退出，虚拟机可能就曾经被回收了。
这里须要额定提到的是，业务利用如何感知到 spot 实例行将被回收呢？这就要从 Kubernetes 的设计说起，Kubelet 在真正删除 Pod 之前，会在 Pod 上设置一个删除标记的起始工夫，示意这个时刻收到了删除该 Pod 的申请，并会给 Pod 的容器过程发送一个 SIGTerm 信号，通知业务过程该 Pod 行将被删除，而业务过程要做的，就是实现一行代码，去监听这个信号，这也算是云原生利用的根本要求了，对于云原生利用而言，云资源是不稳固的。
cost webhook + cost scheduler – 灵便的业务调度模式
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 调度到按量付费 \ 包年包月实例上。
1.How Cost webhook works
具体来说，cost webhook 是基于 Kubernetes 提供的动静准入管制机制实现的一个 webhook，用户申请达到 API Server 后，以此通过路由、认证、审计、鉴权等流程，而审计包含 Mutating 和 Validating 两个阶段，前者用于对 API 资源持续批改，后者次要用于校验，如下图。
（图片起源：https://kubernetes.io/blog/20…
cost webhook 正是 Mulating 阶段的 webhook，在流程走到 Mutating 阶段被调用执行，cost webhook 监听 Deployment 这种资源类型，判断 annotation 中是否蕴含上述提到的 pod-on-spot-instance=70% 信息，如果有，则将该 Deployment 所属的 Pod 的 Scheduler Name 批改为 cost scheduler，对于这些 Pod 的调度，就交给 cost scheduler 来实现。
2.How Cost Scheduler works
cost scheduker 也是基于 Kubernetes 的 scheduker framework 扩大机制实现的自定义调度器。
（图片起源：https://kubernetes.io/docs/co…
如上图所示，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
- 用户可指定多种机型规格，升高某种机型售罄的潜在危险
- 用户可指定多可用区，作用和配置多机型规格相似
-
灵便的供给策略 —— 满足不同的实质需要
- 多可用区打散策略（在您配置的多可用区内均匀供给算力，达到高可用）
- 容量高可用策略（优先扩容资源库存最高的实例规格，达到高可用）
- 老本优化策略（优先扩容老本最低的实例规格，具备最优的老本优化成果）
-
开释闲置资源 —— 极致的弹性伸缩
- 联合 TKE 提供的全套弹性伸缩解决方案: HPA/VPA + Cluster Autoscaler, 主动开释闲置资源，即可利用弹性能力进一步助力老本缩减。
应用老本控制系统的最佳实际
文章最初，通过积淀咱们在服务不同行业场景客户的实战经验，咱们给出了一些应用本零碎以及竞价实例的最佳实际。
从业务场景来看，如果您的业务是无状态业务，比方可横向伸缩的 Web 站点服务、图像渲染、大数据分析、并行计算、强化学习、AI 等，都非常适合应用这套老本控制系统。
此外，咱们有一些 Tips 供您参考，以取得更佳的应用体验：
大数据 / 强化学习场景 – 切分工作粒度
● 长时间作业拆成细粒度的作业，缩小被中断可能性（联合容器场景下的 Workload 能力）
● 强化学习场景
在线业务场景 – 通过负载平衡在保障服务的稳定性
● 利用 Kubernetes 原生的 Service 能力，配合负载平衡，保障业务的高可用。
● 通过合理配置 Spot-controller 中的不同资源配比，保障负载平衡后端资源的稳固供给。
● 通过 tke-spot-agent 监听竞价实例中断状况，优雅终止并迁徙业务正本。
离线计算场景 – 反对断点续算的计算调度模式
● 将计算两头后果放到 COS/CFS/NAS 等长久存储产品上。
● 通过 tke-spot-agent 监听竞价实例中断状况，在利用 (Pod) 中定义优雅退出钩子，保留两头计算结果。
● 定义利用 (Pod) 中定义启动钩子，当新业务正本胜利启动后主动从长久存储中拉取两头后果，持续计算。
在腾讯云容器服务应用竞价实例
以后 TKE 曾经通过节点池集成了竞价实例，您能够间接通过 TKE 间接创立竞价实例节点池。具体可查看创立节点池。并且能够通过 TKE 利用市场部署上述 Spot Agent 利用助力业务优雅终止和平滑迁徙。
同时弹性容器服务 EKS 行将推出竞价类型 Pod，届时您也能够通过弹性容器服务应用更低成本的计算资源。
总结
少数企业上云外围目标之一就是降低成本，且容器化让老本具备了十分大的优化空间，而真正降低成本须要深度利用云和容器化的弹性能力，并且容器可能让弹性和稳定性失去了衡量。腾讯云容器团队将陆续提供上述老本控制系统套件，如您有任何倡议或诉求欢送通过小助手与咱们分割。
参考资料
竞价实例：https://cloud.tencent.com/doc…
创立节点池：https://cloud.tencent.com/doc…
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！