这也是一篇研究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"，以前看到这样的错误直接忽略，这次下定决心分析一下这个报错的原因。
这篇文章会从这几个方面进行剖析
在开始之前，如果你问我这个报错严重么，会有什么影响？ 我的回答是无所谓这是由于异步和缓存信息不一致导致的问题，不影响pod删除和清理的流程的执行。 要是你想知道原因继续往下看，不想知道原因可以直接关闭这篇文章，因为这篇文章很长，不适合排查故障时候阅读。
在之前的文章为什么HPA扩容慢 里进行分析HPA扩容原理和算法，并提供一些解决方案。与HPA相关的有意思的一个话题是“HPA能否缩容到0”，这个需求旨在降低成本，而且这是serverless非常通用的一个需求。
最近遇到业务活动期间遇到突发流量，由于pod资源使用飙升导致业务可用性降低的问题。这里面导致业务不可用的原因有很多，其中一个直接原因是流量来临时候资源使用飙升，而HPA没有及时的进行扩容。 这篇文章就是针对这个问题进行研究，主要从这三方面进行阐述：
我平时喜欢用yaml进行部署应用，最近使用kubectl apply发现一个问题。我使用kubectl rollout restart重启应用，kubectl会在spec.template.metadata.annotations添加kubectl.kubernetes.io/restartedAt: <current time>。然后我再更新yaml文件进行kubectl apply后，并没有将annotation里kubectl.kubernetes.io/restartedAt: "2022-07-26T11:44:32+08:00"删除掉。
首先感谢karmada社区提供的kubeCon票，并在现场遇到了zhen chang、hongcai Ren、Wei jiang等karmada的核心贡献和维护者。
往年参加技术大会，如雁过无痕，没有留下深刻印象，没有收到收获。这次强迫自己记录一下，加深映像总结收获。
由于对在离线混部感兴趣，所以听的分享基本都跟这个有关系。
更新：kubecon china 2023的所有视频录像已经出来了，YouTube地址，微信公众号文章
PPT地址：https://kccncosschn2023.sched.com/?iframe=no
istioCon china 2023 PPT：https://istioconchina2023.sched.com/ https://github.com/cloudnativeto/academy/tree/master/istiocon-china-2023
