在梳理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非常通用的一个需求。

最近遇到业务活动期间遇到突发流量，由于pod资源使用飙升导致业务可用性降低的问题。这里面导致业务不可用的原因有很多，其中一个直接原因是流量来临时候资源使用飙升，而HPA没有及时的进行扩容。 这篇文章就是针对这个问题进行研究，主要从这三方面进行阐述：

1. 扩容有多慢
2. 为什么扩容慢
3. 有什么解决方案

1 kubectl apply无法移除annotation

我平时喜欢用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

dns服务器作为基础设施，一般很少变更。如果dns服务器ip发生变化了，怎么更换kubernetes节点的dns配置？

1 平常操作方法

更换节点步骤，直接替换/etc/resolv.conf文件里的dns服务器ip。