kubelet源码 删除pod（一）

k8s版本为1.25.3版本
整体流程图如下

kubectl delete pod name
1

当删除一个pod的时候会经历一下流程

1. kubectl会发pod消息给api server。
2. apiserver将信息存入etcd，然后返回确认信息。
3. apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动。
4. kubelet发现有pod变化，然后开始一系列的操作，操作完成后，返回给apiserver。
5. 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)  //这里进入循环
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

上面做了很多的初始化工作。在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（二）