k8s版本为1.25.3版本
kubectl delete pod name
当删除一个pod的时候会经历一下流程
- kubectl会发pod消息给api server。
- apiserver将信息存入etcd,然后返回确认信息。
- apiserver开始反馈etcd中pod对象的变化,其他组件使用watch机制跟踪apiserver上的变动。
- kubelet发现有pod变化,然后开始一系列的操作,操作完成后,返回给apiserver。
- apiserver将收到的pod状态信息存入etcd中。
此篇讲述的事第4步,kubelet发现pod变化后的一些操作
kubelet的启动,在cmd/kubelet/kubelet.go下。启动后会初始化必要文件,最后流程走到pkg/kubelet/kubelet.go的run函数下
func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
if kl.logServer == nil {
kl.logServer = http.StripPrefix("/logs/", http.FileServer(http.Dir("/var/log/")))
}
if kl.kubeClient == nil {
klog.InfoS("No API server defined - no node status update will be sent")
}
// Start the cloud provider sync manager
if kl.cloudResourceSyncManager != nil {
go kl.cloudResourceSyncManager.Run(wait.NeverStop)
}
if err := kl.initializeModules(); err != nil {
kl.recorder.Eventf(kl.nodeRef, v1.EventTypeWarning, events.KubeletSetupFailed, err.Error())
klog.ErrorS(err, "Failed to initialize internal modules")
os.Exit(1)
}
// Start volume manager
go kl.volumeManager.Run(kl.sourcesReady, wait.NeverStop)
if kl.kubeClient != nil {
// Introduce some small jittering to ensure that over time the requests won't start
// accumulating at approximately the same time from the set of nodes due to priority and
// fairness effect.
go wait.JitterUntil(kl.syncNodeStatus, kl.nodeStatusUpdateFrequency, 0.04, true, wait.NeverStop)
go kl.fastStatusUpdateOnce()
// start syncing lease
go kl.nodeLeaseController.Run(wait.NeverStop)
}
go wait.Until(kl.updateRuntimeUp, 5*time.Second, wait.NeverStop)
// Set up iptables util rules
if kl.makeIPTablesUtilChains {
kl.initNetworkUtil()
}
// Start component sync loops.
kl.statusManager.Start()
// Start syncing RuntimeClasses if enabled.
if kl.runtimeClassManager != nil {
kl.runtimeClassManager.Start(wait.NeverStop)
}
// Start the pod lifecycle event generator.
kl.pleg.Start()
kl.syncLoop(updates, kl) //这里进入循环
}
上面做了很多的初始化工作。在50行的kl.syncLoop进入到循环中。开始下面的操作
1.进入syncLoop函数循环状态,这里会从不同管道读取数据。 pkg/kubelet.kubelet.go
图1
kl.syncLoopMonitor.Store(kl.clock.Now())记录处理这个pod的开始时间
kl.syncLoopMonitor.Store(kl.clock.Now())记录处理这个pod的结束时间
2044行为流程走向。kl.syncLoopIteration处理函数
2.TYPE类型为DELETE,u.pod是从apiserver监听到的最新的po信息。进入handler.HandlePodUpdates函数更新pod。
图2
3.2281行kl.podManager.UpdatePod()会处理一下是否为静态pod
图3
4.先判断是否为镜像pod,如果是则代表是静态pod,使用mirrorPodUID对podmanager更新为最新的pod(静态pod可以在 apiserver 中查询到该 pod,但是不能通过 apiserver 进行控制。归kubelet控制)
如果不是静态pod,则直接更新。
图4
5.回到图3的2282行。如果是静态pod,则进行静态pod的处理(和普通pod处理一样,后续分析)
6.图3的2287行,dispatchWork进入pod处理流程(和步骤4处理是一个函数)
图5
在这里组装了一下需要的结构体UpdatePodOptions。
pod为apiserver发来的最新的pod状态。mirrorPod为静态pod(不是静态则为nil)updateType是此次状态的类型(syncpodupdate)。start是开始的时间
7.pod_workers.go 文件是真正处理pod的流程。这个文件在1.22版本后进行了比较大的改动。几乎所有的pod的变化流程都在这个文件下
图6
后续的大部分操作(除容器CRI外都是在这个文件中进行)
下一篇 kubelet源码 删除pod(二)