2023总体感觉自己还在困境中不断的挣扎，但是慢慢看到了一丝希望。就像步履蹒跚的往上爬，抬头看到了坡顶。自己感觉在云原生领域小有积累，可以慢慢的输出自己的知识和思考，同时提升自己的技术影响力。

最近在研究descheduler，主要为了解决node节点出现cpu热点问题，即节点的cpu使用率相差特别大，而节点的request分布均匀。我们知道kube-scheduler将pod调度到节点上，而descheduler将pod进行移除，让workload控制器重新生成pod，并再次触发pod调度流程将pod调度到节点。通过这个方法达到pod重调度和节点的平衡目的。

社区的descheduler项目为了解决以下场景：

1. 部分节点利用率过高，需要平衡节点的利用率
2. 在pod调度之后，节点的label、taint不满足pod的pod/node affinity，需要将pod移动到符合的节点
3. 新节点加入集群，需要平衡节点的利用率
4. pod处于failed状态但是没有清理
5. 同一个workload的pod集中在同一节点上

descheduler利用插件机制来扩展它的能力，插件分为Balance（节点平衡）和Deschedule（pod重调度）两个类型。

上篇文章讲了有意思的mirror pod的移除流程，这篇文章来研究static pod的移除流程。

static pod可以来自文件和HTTP服务，而且static pod只在kubelet内部可见，mirror pod是static pod的镜像让外部组件能够捕获static状态。

上篇文章讲了删除mirror pod并不会删除static pod，执行static pod的删除需要通过删除--pod-manifest-path目录下的文件或让--manifest-url的http server返回response body里移除这个pod。

这也是一篇研究pod移除流程的文章，这个文章专注mirror pod的移除。mirror pod这个名词可能很陌生，中文直译就是镜像pod，它是pod里的一种类型。

那我们先介绍pod的分类，pod来源分为file、http、apiserver。其中来自apiserver中的pod称为普通pod，其他来源的pod称为static pod（使用kubeadm安装集群的控制平面就是用static pod运行的）。为了管理pod方便，kubelet会在apiserver上为static pod生成对应的pod，这类型pod称为mirror pod，即可以理解是这个pod的替身（基本上跟static pod一模一样，只有uid不一样和annotations里多了"kubernetes.io/config.mirror"）。

那么删除mirror pod会发生什么？对节点上static pod有没有影响，会不会移除节点上的static pod？

在梳理kubelet移除pod流程过程中，遇到了一个问题”已经消失的pod的sandbox并未被清理掉“。

在上篇文章"为什么kubelet日志出现an error occurred when try to find container“里分析了pod移除流程，kubelet里的garbageCollector会清理退出的pod的sanbox，而实际上没有移除。

为什么kubelet移除pod流程里没有移除这个sanbox？即为什么garbageCollector没有清理退出的sandbox？

本文通过分析kubelet日志并结合代码逻辑，梳理了pod移除的整个流程，找到出现这种现象根本的原因。

大概4个月前在排查cni插件bug导致pod移除失败问题时，梳理了一下kubernetes 1.23版本pod的删除流程。在kubelet日志里遇到经常看到的报错"an error occurred when try to find container"，以前看到这样的错误直接忽略，这次下定决心分析一下这个报错的原因。

这篇文章会从这几个方面进行剖析

1. 介绍在kubelet里pod生命周期管理的几个核心组件
2. 实际pod移除过程分析–根据Pod在kuebelet中移除过程输出的日志进行分析

在开始之前，如果你问我这个报错严重么，会有什么影响？ 我的回答是无所谓这是由于异步和缓存信息不一致导致的问题，不影响pod删除和清理的流程的执行。 要是你想知道原因继续往下看，不想知道原因可以直接关闭这篇文章，因为这篇文章很长，不适合排查故障时候阅读。

在之前的文章为什么HPA扩容慢 里进行分析HPA扩容原理和算法，并提供一些解决方案。与HPA相关的有意思的一个话题是“HPA能否缩容到0”，这个需求旨在降低成本，而且这是serverless非常通用的一个需求。