Kubernetes源码分析之Pod的删除

本文主要梳理删除Pod时，Pod的执行流程

kube-apiserver的任务

咱们一般使用kubectl命令删除Pod，或者经过http协议直接调用apiserver暴露的接口去删除Pod。因此，删除Pod的起源确定在apiserver这儿。
在以前分析kube-apiserver部分有分析到，kube-apiserver的http处理架构使用的是go-restful。其中，对于删除，调用的天然是DELETE接口。方法以下（位于kubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/install.go下的registerResourceHandlers方法）

该方法最终的处理handler为 restfulDeleteResource

restfulDeleteResource继续封装handler，调用了 DeleteResource方法。 DeleteResource方法很长，但最终调用的仍是 DELETE方法，以下

DELETE方法位于 staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go下。在 DELETE方法中，最主要的是 updateForGracefulDeletionAndFinalizers方法，该方法的主要做用就是用来改变Pod的一些内部信息，其实就是改变Pod的两个字段： DeletionTimestamp以及 DeletionGracePeriodSeconds，调用的是 BeforeDelete方法

经过比对工具也能够发现，主要的字段改变以下

kubelet的任务

经过以前分析过kubelet的代码得知，kubelet一直在经过listwatch监听apiserver的变化

如图，监听到相应的变化以后，调用相应的处理逻辑。同时，kubelet还启动了一个goroutine： statusManager

在syncLoop以前调用了statusManager的start方法启动statusManager。
start方法以下：

主要的任务就是经过监听事件的变化，调用 syncPod方法。在syncPod方法有下面一段代码

咱们发现，kubelet又去调用了一次DELETE接口，这是为何呢？不是已经删除了吗？别急，这才是咱们要分析的DELETE操做最核心的部分。

深层分析

咱们知道，Pod的删除若是不去强制删除，则实际上是一个优雅的删除，也就是一个graceful的删除。默认状况下，这个优雅的时间是30s，也就是grace-period的时间。在kube-apiserver的任务中，经过updateForGracefulDeletionAndFinalizers方法为Pod设置了DeletionTimestamp和DeletionGracePeriodSeconds两个字段，此时Pod定义为graceful的状态。回到代码处，调用完updateForGracefulDeletionAndFinalizers方法后，下面有一个判断的语句

很显然，由于咱们是优雅删除，因此 deleteImmediately字段false，删除到此结束。是否是与咱们想象的彻底不同？
没错，实际状况的确是这样，每次删除的时候，apiserver的处理逻辑到此就中断了。接下来就要从新认识kubelet了。
Kubelet在调用apiserver的删除接口的时候，提早会有一个判断，调用链为 canBeDeleted-->PodResourcesAreReclaimed。在 PodResourcesAreReclaimed方法内，主要的任务就是判断Pod内的资源是否已经彻底关闭和清理，包括 containers、 processes、 volumes以及 cgroup sandbox资源。

当全部的资源都清理干净以后，此时 canBeDeleted方法返回true，kubelet调用apiserver的delete接口再次删除Pod。不过，与优雅删除不一样的是，此次调用，多了一个 deleteOptions字段

意思很好理解，就是设置grace-period字段为0，表示此次是强制删除Pod。所以，apiserver会再次收到DELETE的请求，继续执行DELETE handler的流程。与第一次不一样的时，此次是强制删除Pod，因此会执行完整的过程，apiserver去etcd删除最终的Pod信息。

kubelet接收到事件变化以后，转化为 REMOVE事件，完成Pod的最终清理工做。至此，Pod删除流程结束。

总结

优雅删除Pod时：
一、apiserver handler执行了两次，第一次主要是修改Pod信息，设置DeletionTimestamp和DeletionGracePeriodSeconds信息，第二次去数据库etcd删除Pod信息；
二、kubelet经过检测到Pod内的资源已经彻底释放以后，触发了第二次删除事件，且是强制删除Pod；
三、kubelet的DELETE操做其实监听到的是Pod的更新事件，Pod删除以后，执行的是REMOVE操做；
四、处理流程为：客户端请求删除Pod-->apiserver更新Pod信息-->kubelet优雅释放Pod资源-->kubelet请求删除Pod-->apiserver删除etcd中Pod信息-->kubelet完成最终Pod的资源清理。