k8s 容器的驱逐时间是多少 节点notready api kubelet
在默认配置下，k8s节点故障时node notready，工作负载的调度周期约为6分钟，
参数概念：
node-monitor-period
节点控制器(node controller) 检查每个节点的间隔，默认5秒。
node-monitor-grace-period
节点控制器判断节点故障的时间窗口, 默认40秒。即40 秒没有收到节点消息则判断节点为故障。
pod-eviction-timeout
当节点故障时，kubelet允许pod在此故障节点的保留时间，默认300秒。即当节点故障5分钟后，kubelet开始在其他可用节点重建pod。
5+40+300 ≈ 6分钟
kubernetes节点失效后pod的调度过程：
0、Master每隔一段时间和node联系一次，判定node是否失联，这个时间周期配置项为 node-monitor-period ，默认5s
1、当node失联后一段时间后，kubernetes判定node为notready状态，这段时长的配置项为 node-monitor-grace-period ，默认40s
2、当node失联后一段时间后，kubernetes判定node为unhealthy，这段时长的配置项为 node-startup-grace-period ，默认1m0s
3、当node失联后一段时间后，kubernetes开始删除原node上的pod，这段时长配置项为 pod-eviction-timeout ，默认5m0s
以下我的参数
最后再设置pods漂移时间
方法 1 统一设置时间
vim /etc/kubernetes/manifests/kube-apiserver.yaml
添加以下参数
- --default-not-ready-toleration-seconds=30
- --default-unreachable-toleration-seconds=30
原文链接：https://blog.csdn.net/weixin_42562106/article/details/124698888
-------------------------------------------------------------------
API 发起的驱逐是一个先调用 Eviction API 创建 Eviction 对象，再由该对象体面地中止 Pod 的过程。
你可以通过直接调用 Eviction API 发起驱逐，也可以通过编程的方式使用 API 服务器的客户端来发起驱逐， 比如 kubectl drain 命令。 此操作创建一个 Eviction 对象，该对象再驱动 API 服务器终止选定的 Pod。
API 发起的驱逐将遵从你的 PodDisruptionBudgets 和 terminationGracePeriodSeconds 配置。
使用 API 创建 Eviction 对象，就像对 Pod 执行策略控制的 DELETE 操作
最近看代码时，老是在代码中能看到PDB 是什么呢？Pod Disruption Budget (pod 中断 预算)，含义其实是 终止pod前 通过labelSelector机制获取正常运行的pod数目的限制，目的是对主动驱逐的保护措施。
场景
节点维护或升级时(kubectl drain)
对应用的自动缩容操作(autoscaling down)
由于节点不可用(not ready)导致的Pod驱逐就不能称之为主动
特性
PDB指定一个pod集合在一段时间内存活的最小实例数量或者百分比
作用于一组被同一个控制器管理的pod。例如：RC或者statefulapp
使用PodDisruptionBudget控制器本身无法真正保障指定数量或者百分比的pod存活，PodDisruptionBudget控制器只能保证POD主动逃离的情况下业务不中断或者业务SLA不降级
场景局限于：主动驱逐
主动驱逐的场景，用用如果能够保持存活pod数量，将会非常有用。通过使用Pod Disruption Budget 对象，应用可以保证那些主动移除pod的集群操作永远不会同一时间停掉太多pod，导致服务中断或者服务降级。
kubectl drain 操作时遵循PDB对象的设定，如果在该节点上运行了属于统一服务的多个pod，则为了保证最少存活数量，系统会确保每终止一个pod就会在健康的node上启动新的pod后，再继续终止下一个pod容器。
------------------------------------------------------------------------------------------------------
- kubelet的eviction机制
如果节点处于资源压力，那么kubelet就会执行驱逐策略。驱逐会考虑Pod的优先级，资源使用和资源申请。当优先级相同时，资源使用/资源申请最大的Pod会被首先驱逐。
kube-controller-manager的eviction机制是粗粒度的，即驱赶一个节点上的所有pod，而kubelet则是细粒度的，它驱赶的是节点上的某些Pod，驱赶哪些Pod与Pod的Qos机制有关。该Eviction会周期性检查本节点内存、磁盘等资源，当资源不足时，按照优先级驱逐部分pod。
驱逐阈值分为软驱逐阈值（Soft Eviction Thresholds）和强制驱逐（Hard Eviction Thresholds）两种机制，如下：
- 软驱逐阈值：当node的内存/磁盘空间达到一定的阈值后，kubelet不会马上回收资源，如果改善到低于阈值就不进行驱逐，若这段时间一直高于阈值就进行驱逐。
- 强制驱逐：强制驱逐机制则简单的多，一旦达到阈值，直接把pod从本地驱逐。
kubelet提供了以下参数控制eviction：
- eviction-soft：软驱逐阈值设置，具有一系列阈值，比如memory.available<1.5Gi时，它不会立即执行pod eviction，而会等待eviction-soft-grace-period时间，假如该时间过后，依然还是达到了eviction-soft，则触发一次pod eviction。
- eviction-soft-grace-period：默认为90秒，当eviction-soft时，终止Pod的grace的时间，即软驱逐宽限期，软驱逐信号与驱逐处理之间的时间差。
- eviction-max-pod-grace-period：最大驱逐pod宽限期，停止信号与kill之间的时间差。
- eviction-pressure-transition-period：默认为5分钟，脱离pressure condition的时间，超过阈值时，节点会被设置为memory pressure或者disk pressure，然后开启pod eviction。
- eviction-minimum-reclaim：表示每一次eviction必须至少回收多少资源。
- eviction-hard：强制驱逐设置，也具有一系列的阈值，比如memory.available<1Gi，即当节点可用内存低于1Gi时，会立即触发一次pod eviction。
-
“条件满足了”，等待零秒就开始执行删除镜像和停止容器进程的操作，这就是硬驱逐。
“条件满足了”，等待N（N > 0）秒就开始执行删除镜像和停止容器进程的操作，这就是软驱逐。数字N，可通过kubelet的参数–eviction-soft-grace-period来设定。另外，对于软驱逐，–eviction-max-pod-grace-period参数来影响驱逐管理器等待kubelet清理Pod的时间（真正等待的时间是eviction-max-pod-grace-period+ ( eviction-max-pod-grace-period/ 2 )
