在Kubernetes（k8s）中，当节点资源面临压力时，如何决定Pod的优先级是一个关键问题。在Kubernetes 1.8版本之后，引入了基于Pod优先级的调度策略，即Pod Priority Preemption。这种策略允许在资源不足的情况下，系统可以选择性释放一些优先级较低的Pod，以确保最重要的Pod能够获取足够的资源并稳定运行。
Pod的优先级是由用户设置的，并且可以通过权重来区分不同的优先级。权重是区分优先级的关键因素，Kubernetes将Pod分成了三个QoS（服务质量）等级，分别是：
- Guaranteed：优先级最高，通常用于数据库应用或一些重要的业务应用。这些Pod只有在资源超出其限制或节点内存压力非常大且没有其他更低QoS的Pod时，才会被杀死。
- Burstable：这种类型的Pod可以使用的资源超过其请求的资源（上限由limit指定），但优先级相对较低，通常用于一般性应用或批处理任务。
- Best Effort：优先级最低，集群不知道Pod的资源请求情况，调度时不考虑资源，通常用于一些临时性的不重要应用。
当节点资源不足时，Kubernetes的调度器会尝试驱逐一些优先级较低的Pod，以释放资源供新的或更重要的Pod使用。这种驱逐行为称为Eviction。而在调度新Pod时，如果资源不足，调度器会尝试抢占一些优先级较低的Pod来满足新Pod的需求，这称为Preemption。
需要注意的是，高优先级的Pod并不保证始终被调度到特定节点上。如果在驱逐低优先级Pod的过程中出现了更高优先级的Pod，调度器会重新调度这些Pod。此外，优先级抢占的调度方式可能会导致调度陷入“死循环”状态，这通常需要通过多个Scheduler协作来避免。
总之，在Kubernetes中，通过合理的设置Pod的优先级和QoS等级，可以在节点资源面临压力时实现更智能的资源管理和调度，从而确保关键业务的稳定运行。
真实案例：
参考订单号：
PT-20240115002：[EU PRD]节点Calico pod因内存压力会被优先重启
http://hds.ms-sit.xxxxxx.net/orderOperation/planTaskView/vendor/249
通过k8s原理来看，在节点出现资源紧张的情况下，会对该节点的pod做驱逐排名，而resources设置了1:1相比于设置了1:n的，排名会更后，所以就出现了calico-node等pod被优先驱逐的情况。
节点内存压力问题的出现，从之前的排查来看可能跟低版本的DCE有关，也有可能是节点产生了较多的cache占用了较多的内存，我们的建议是重启节点（之前同样问题的节点重启后暂时没出现过），如果不能重启节点，我们的建议是对节点进行扩容，暂时不建议将平台组件的资源用量也调整为1:1，因为这个过程需要滚动重启所有ds相关的pod
调整方案初步确定为，将calico node的memory request从200M改为与limit一致的400M，并且滚动升级策略改为onDelete。
onDelete 参数的含义：
在 Kubernetes（k8s）中，滚动升级（Rolling Update）是一种常见的部署策略，用于逐步替换集群中的旧版本 Pod，以新版本 Pod 替代它们。在滚动升级过程中，旧的 Pod 会被逐个删除，而新的 Pod 会被逐个创建，以确保应用程序始终有可用实例。
然而，在某些情况下，您可能希望更精细地控制滚动升级的过程。onDelete 升级策略允许您手动触发 Pod 的替换过程。当您设置滚动升级策略为 onDelete 时，新的 Replicaset（代表新版本 Pod 的集合）不会自动替换旧的 Replicaset（代表旧版本 Pod 的集合）。相反，您需要手动删除旧的 Replicaset，以便 Kubernetes 开始创建新版本 Pod。
将滚动升级策略改为 onDelete 的目的可能包括：
- 精确控制升级过程：
onDelete策略允许您精确地控制何时开始和结束升级过程。这对于需要精细调整升级时间窗口或避免在特定时间段内执行升级的场景非常有用。 - 避免意外的中断：在某些情况下，自动滚动升级可能会导致意外的中断或问题。通过将升级策略设置为
onDelete，您可以确保在升级过程中有更多的控制和可见性，从而避免这些问题。 - 与其他系统或流程集成：在某些场景中，您可能希望将 Kubernetes 的滚动升级与其他系统或流程集成。通过将升级策略设置为
onDelete，您可以更轻松地触发升级过程，并将其与其他自动化工具或流程相结合。
请注意，使用 onDelete 策略需要您手动管理升级过程，确保在删除旧的 Replicaset 之前备份重要数据，并在升级过程中密切监视应用程序的状态。否则，可能会导致应用程序中断或数据丢失。