过去，我们在AWS按需/保留ec2实例上运行了一些有状态的应用程序（例如数据库），现在我们正在考虑将这些应用程序通过PVC移至k8s statefulset。
我的问题是建议在现场实例上运行k8s statefulset以降低成本吗？由于我们可以使用kube-spot-termination-notice-handler来污染节点以在Pod实例终止之前将Pod移至其他节点，因此，只要有状态集具有多个副本以防止服务中断，就好像没有问题。
答案 0 :(得分：1)
这个问题可能没有唯一的答案：它实际上取决于您要运行的工作负载是什么，以及应用程序对故障的容忍程度。当一个竞价型实例被打断时（出价更高，没有更多可用...），做得好的StatefulSet或任何其他适当的控制器确实会按预期的那样正常工作，通常很快（几秒钟）。
但是请注意，断言以下说法是错误的：
请参阅AWS文档本身https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html#using-spot-instances-managing-interruptions，这是摘录“ [...]您的竞价型实例可能会在警告可用之前终止。” 。
真正的问题是：您的应用程序对未经准备的资源删除有多宽容？
如果您只有2个EC2运行数百个Pod，您很可能不希望使用竞价型实例，因为如果这2个实例之一被中断，则服务将高度降级，直到一个新的实例旋转或k8s重新分派负载（假设另一个实例足够大）。数以百计的EC2，每个Pod很少，并且自动配置规则略有超额设置？您不妨去争取并使用节省的现货成本！
您还需要仔细检查您的客户端行为：假设您在k8s上运行API并且在响应之前停止了pod，请确保您的客户端可以处理该场景并触发另一个请求，或者至少可以正常地失败。< / p>
但是您谈到数据库：那么复制呢？它快速，自动化吗？是否有多个数据复制项允许丢失1到n个复制项？。
换句话说：它只需要一些好的计划和大规模的全面测试。好消息很容易做到：运行负载测试并自动使实例崩溃，答案在那里就可以满足您！
答案 1 :(得分：1)
IMO，我不建议在竞价型实例上运行关键的StatefulSet。例如，关键数据库。这是在以下示例中可能/可能发生的一些事情：
Mysql主/从/集群。任何发生故障的节点都将导致不可预测的错误和/或恢复之前的停机时间，或者节点重新启动（具有不同的IP地址！）
卡桑德拉。任何向上/向下的节点都会导致群集重新平衡。如果您有这些波动，那么它们将不断地重新平衡！更不用说一个事实，如果您在竞价型实例中拥有所有节点，那么大多数节点就有机会宕机。
对于大型一次性批处理作业，这些点非常有用，并且它们不受时间限制。这些可以是任何数据处理，例如创建或更新M / L模型。
它们对于无状态服务也非常有用，这意味着它位于负载均衡器后面并且使用不在竞价型实例（Mysql，Cassandra，CloudSQL，RDS等）中的状态存储。
对于测试/开发环境来说，地点也很棒，同样也不一定是有时限的工作/工作量。