kubernetes - 如何在负载下安全终止Pod

Question

在某些情况下，需要终止Pod而不降低Deployment的总容量:

维护的排水节点

用于装箱

的排水节点

Pod行为异常/在不触发OOM Killer的情况下处理内存泄漏

假设有两个Pod占用大量流量的情况，如果使用终止Pod的默认工作流程，然后让Kubernetes通过重新创建Pod使用react，那么在任意时间段内我们将拥有50％的处理能力。
在高吞吐量应用程序中，这将通过以下一种或多种方式降低服务级别:

在非多线程非异步应用程序(如Rails)中的请求排队会增加响应时间

在异步多线程应用程序的情况下，较高的上下文切换会增加响应时间

具有严格响应时间SLO和超时的应用程序中的超时错误峰值

如果我们不执行严格的响应时间SLO和超时，则取决于所讨论的高吞吐量应用程序的服务的级联速度下降

理想情况下，我要寻找的是销毁前创建模式。诸如此类:我们要求Kube终止Pod，但是在将其从列出的任何服务的端点中删除之前，它会触发放大操作，遵守Readiness Gate，然后开始终止我们要求终止的Pod。我还没有在Kubernetes中提及这种模式。
人们如何应对这种情况？我可以想象以下内容:

降低HPA的targeAverageUtilization，因此我们可以容忍暂时减少50％的容量，但这意味着我们将付出比

更高的价格

优化Pod的准备时间，因此我们会在数秒钟内保持不足的配置，但是，例如，当AWS Load Balancer花费至少10秒才能使新目标正常运行时，这似乎非常困难

创建一个涉及的工作流程，而不是kubectl delete [pod]我们:

将HPA minReplicas增加到当前副本

之上的一个

等待Pod准备就绪

等待几秒钟使其热身

运行kubectl delete [pod]杀死所需的pod

等待新的替换容器准备就绪

等待几秒钟使其热身

恢复HPA

中的 minReplicas

冒着与流量增加/峰值同时发生整个操作的风险，并看到我上面列出的

的任何降级影响


这些似乎都不好。特别是最后一个将不涉及装箱，因为我们无法替代集群自动伸缩器耗尽实例的方式。

Answer 1

中断预算:

https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

https://kubernetes.io/docs/tasks/run-application/configure-pdb/

将 minAvailable设置为90％即可。