我们过去在AWS按需/保留的ec2实例上运行了一些有状态的应用程序(例如数据库(，现在我们正在考虑将这些应用程序移动到具有PVC的k8s状态集。
我的问题是，是否建议在现场实例上运行k8s语句集以降低成本？由于我们可以在spot实例终止之前使用kube spot终止通知处理程序来污染节点以将pod移动到其他节点，因此只要statefulset有多个副本以防止服务中断，看起来应该没有问题。
这个问题可能没有唯一的答案：它实际上取决于你想要运行的工作负载是什么，以及你的应用程序对故障的容忍度。当一个点实例被中断时(出价更高，没有更多可用的…(，一个做得很好的StatefulSet或任何其他合适的控制器确实会按预期完成它的工作，而且通常很快(秒(。
但要意识到，断言是错误的
- 您每次都会收到中断通知
- 并且通知总是在spot实例中断前2分钟内到达
参见AWS文档本身https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#using-spot实例管理中断，下面是摘录"[…]您的spot实例可能在发出警告之前终止">。
因此，真正的问题是：您的应用程序对未经准备的资源删除的容忍度如何
如果你只有两个EC2，每个EC2运行数百个pod，你很可能不想使用spot实例，因为如果这两个实例中的一个中断，你的服务将高度降级，直到一个新实例启动或k8s重新分配负载(假设另一个实例足够大(。数百个EC2，每个pod很少，并且略微超出了自动缩放规则的供应范围？你还不如直接去做，并使用现场节省的成本！
你还需要仔细检查你的客户行为：假设你在k8s上运行API，并且在响应之前停止了pods，那么让你的客户处理这个场景并触发另一个请求，或者至少优雅地失败。
但是您谈到了数据库：那么复制呢？它是快速和自动化的吗？是否有多个数据复制以允许1到n个复制副本丢失？。。
换句话说：它只需要一些良好的计划和大规模的彻底测试。好消息是它很容易做到：运行负载测试并自愿崩溃一个实例，答案会在那里与您见面！
IMO，我不建议在现场实例上运行关键的StatefulSet。例如，关键数据库。以下是这些例子中可能发生的情况：
-
Mysql主/从/集群。任何节点故障都会导致不可预测的错误和/或在恢复前停机，或者节点恢复正常(使用不同的IP地址！(
-
卡桑德拉。任何节点上升/下降都会导致集群重新平衡。如果你有这些上升和下降，那么它们将不断地重新平衡！更不用说，如果您将所有节点都放在"点实例"中，则大多数节点都有可能宕机。
Spots非常适合大型一次性批处理作业，而且它们没有严格的时间限制。这些可以是任何数据处理，例如，创建或更新M/L模型。
它们也非常适合无状态服务，这意味着一个位于负载均衡器后面的应用程序，并使用不在点实例中的状态存储(Mysql、Cassandra、CloudSQL、RDS等(
Spot对于测试/开发环境也很好，同样不一定是有时间限制的作业/工作负载。