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