软驱逐硬驱逐的观察期设计及驱逐与垃圾收集的本质差异

驱逐（Eviction）是Kubernetes对”杀Pod”这件事的专业称呼，由每个节点的 kubelet执行——它本身跑在节点上，最容易感知实时资源消耗。kubelet发现 某种不可压缩资源即将耗尽（默认阈值：可用内存、宿主机可用磁盘 %、文件系统可用inode%、镜像存储空间%，管理员可通过启动参数 调整，生产环境常建议把内存阈值调到10%这类更保守的值）时，会主动终止 节点上服务质量等级较低的Pod。习惯了Java/C#/Golang自动内存管理的程序员 容易把驱逐类比成垃圾收集，但两者本质不同：垃圾收集是安全的内存回收 行为，”应收尽收”；驱逐是破坏性的清理行为，可能导致服务中断，必须更加 谨慎，因此设计了软驱逐、硬驱逐、优雅退出期三层机制。软驱逐：配一个较低 的警戒线（如剩余内存20%），触及后先进入观察期，如果只是短暂的资源 抖动、能在观察期内恢复正常，就不真正驱逐；否则触发优雅退出（Grace Shutdown），通知Pod做必要清理（如把缓存数据落盘）后自行结束，优雅退出 期结束后系统才强制杀掉还没自行了断的Pod。硬驱逐：配一个较高的终止线 （如剩余内存10%），触及后立即强制杀掉，不给优雅退出的机会。软硬驱逐 并不矛盾，生产环境通常同时配置。此外驱逐还有第二个和垃圾收集不同的 特性——不能”应收尽收”，也不能只清理到刚好低于警戒线就停手（否则很 可能瞬间又超阈值触发新一轮驱逐），因此需要--eviction-minimum-reclaim 设定每次驱逐至少要清出多少资源才收手；而且被驱逐Pod通常由ReplicaSet 等高层资源管理，会立刻生成新Pod顶替，如果不加干预，新Pod极可能又被 调度回刚驱逐完的这个节点（因为它刚好空出资源、又符合上次调度的选择）， 所以还需要--eviction-pressure-transition-period设定驱逐后多久内不 向该节点调度新Pod。