问题的回答。
该架构围绕一个控制平面展开，用于拦截云供应商的元数据信号（例如，AWS临时实例中断通知，GCP抢占警告）并协调实时工作负载迁移。一个调度器维护可抢占实例健康状态的实时热图，以及在按需和第二云区域的预热备用容量池。在收到终止警告后，系统启动应用一致的检查点到分布式存储（例如，Ceph或S3），同时在保留的容量上启动替换的Pod。服务网格边车（例如，Istio）通过连接排水和HTTP/2 GOAWAY信号来处理流量优雅转移，以防止请求丢失。最后，一个全局负载均衡器在成功健康验证后更新健康检查，确保延迟保持在100毫秒以下，通过优先选择地理上接近的备用区域。
生活中的情况。
一家高频交易公司利用AWS EC2临时实例来减少其基于Kubernetes的风险计算引擎的计算成本，降低了60%。在市场波动激增期间，AWS在其主要的us-east-1可用区域发出了大规模的临时终止通知。这威胁到在处理具有严格50毫秒延迟要求的实时交易时在两分钟内关闭500个Pod，从而可能导致数百万美元的交易损失。
解决方案A：本机Kubernetes Pod干扰预算。
团队考虑依赖标准的Pod干扰预算（PDBs）和集群自动缩放器来优雅地将Pod驱逐到按需节点。这种方法提供了简单性，并且不需要自定义代码。然而，120秒的终止窗口被证明不足以使有状态的风险引擎将其复杂的内存衍生模型序列化到持久存储中，从而导致不可接受的数据丢失和计算缺口。
解决方案B：使用Velero的自定义可抢占节点控制器。
另一个选项是部署一个自定义控制器，利用Velero进行持久卷快照，并使用Karpenter进行快速节点配置。虽然Karpenter在快速节点启动（低于30秒）方面表现优异，但Velero的快照和恢复周期对50GB内存状态的平均时间为三分钟。这种延迟违反了零停机的要求，并且由于积压的交易超出了系统的缓冲能力，可能会导致级联故障。
解决方案C：应用程序级检查点与多云备用。
选择的解决方案使用CRIU（用户空间中的检查点/恢复）实现应用感知的检查点，每30秒冻结和序列化进程状态到Redis持久集群。该架构在GCP 计算引擎中维护了一池温暖的备用，利用Anthos进行跨集群服务网格联合。当收到AWS的终止信号时，控制器立即触发最终的增量同步到Redis，在GCP中使用预拉取的容器镜像生成替换的Pod，并使用Istio的区域故障转移来转移流量。这种方法牺牲了一定的应用复杂性，但保证了低于60秒的故障转移时间且没有数据丢失。
结果。
在大规模终止事件中，该公司成功地在90秒内撤离了98%的工作负载。平均故障转移延迟为45毫秒，远低于SLO，并且该系统在整个事件中保持了99.99%的可用性。实施后的分析显示，与纯按需使用相比，成本降低了55%，验证了多云临时实例策略的抗灾能力。
候选人常常遗漏的内容。
当临时实例网络分区但终止信号延迟或丢失时，您如何防止分裂脑场景?
候选人常常假设2分钟的警告是有保证的。实际上，网络分区可能延迟信号的传送。解决方案实现了一个租约机制，使用etcd或Consul，工作负载持有时间限制的锁。如果控制平面无法续租，则将节点标记为可疑并停止路由新流量。与此同时，分布式日志中的墓碑记录（例如，Apache Kafka）确保即使孤立的实例继续处理，它的结果在重新连接时被拒绝为陈旧，防止冲突状态更新。
在最终同步时，当实例可能在强制检查点中被终止，您如何确保数据一致性?
许多人建议简单的检查点，但忽略了“最后一英里”的一致性问题。正确的方法使用写时复制（COW）语义和原子提交协议。在最终同步之前，应用程序暂停分配（通过GC暂停或应用程序钩子），使用CRIU创建内存快照，并写入S3，具有S3强一致性或使用原子RADOS事务写入Ceph。该系统采用两阶段提交（2PC）模式：准备检查点，确认控制平面，然后再排干连接。如果在提交阶段发生终止，备用实例将回滚到先前的一致检查点，并重播来自Kafka偏移日志的事件。
当成千上万的临时实例同时收到终止通知并竞争有限的备用容量时，您如何缓解雷鸣的群体问题?
候选人经常忽略大规模驱逐期间的资源争用。解决方案在控制平面层实现了一个令牌桶算法，限制迁移速度以匹配备用池的吸收率。此外，它还利用优先级类（Kubernetes中的PriorityClass）确保关键财务工作负载优先于备用容量上的不太重要的批处理作业。一个反压力机制向API网关发出信号，暂时排队传入请求，防止新实例在迁移后立即因流量激增而不堪重负。最后，预测性机器学习模型分析AWS临时价格历史，以在预期的终止波之前15分钟预先扩展备用容量，平滑过渡曲线。