kubelet源码 删除pod pod_workers.go（三）

已于 2023-05-25 17:52:53 修改
阅读量994 收藏 1
点赞数 1
分类专栏： kubernetes 文章标签： kubelet java docker
于 2022-11-24 17:02:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35679620/article/details/127983606
版权

kubelet源码 删除pod pod_workers.go（三）

上篇中UpdatePod函数结束，然后进入managePodLoop函数。
UpdatePod负责对pod的状态流程进行更新，对pod状态的标记
managePodLoop函数主要负责就是上述标记后处理这些pod了

1.managePodLoop函数里整个都是一个for循环，接收podUpdates管道传过来的数据

func (p *podWorkers) managePodLoop(podUpdates <-chan podWork) {
	var lastSyncTime time.Time
	var podStarted bool
	for update := range podUpdates {
		//******
	}
}

2.这里主要校验的是静态pod，只有静态pod是允许启动的才可以走下面流程，如果是不存在的或者已准备删除的，则直接关闭这个静态pod的goroutine，不参与循环。如果这个pod正等待启动中则跳过当前这次循环即可。（流程4详解)

		if !podStarted {
			canStart, canEverStart := p.allowPodStart(pod)
			if !canEverStart {
				p.completeUnstartedTerminated(pod)
				if start := update.Options.StartTime; !start.IsZero() {
					metrics.PodWorkerDuration.WithLabelValues("terminated").Observe(metrics.SinceInSeconds(start))
				}
				klog.V(4).InfoS("Processing pod event done", "pod", klog.KObj(pod), "podUID", pod.UID, "updateType", update.WorkType)
				return
			}
			if !canStart {
				klog.V(4).InfoS("Pod cannot start yet", "pod", klog.KObj(pod), "podUID", pod.UID)
				continue
			}
			podStarted = true
		}

3.流程2代码块的第三行。验证这个pod是否允许启动

  • 判断是否为静态pod，如果不是，直接返回true
  • 如果是静态pod，但是流程里并未创建过，不允许启动，也不是始终如一启动的。都会返回false（必须回到updatePod中重新创建流程链路）
  • 如果pod已经停止了，则都返回false
  • 如果静态pod已经有其他的同名启动成功。或者没有其他的同名启动成功，但是等待中的和当前pod不是同一个。则会执行流程2的continue（流程4介绍这步）
  • 如果静态pod允许启动，则都返回true
func (p *podWorkers) allowPodStart(pod *v1.Pod) (canStart bool, canEverStart bool) {
	if !kubetypes.IsStaticPod(pod) {
		return true, true
	}
	p.podLock.Lock()
	defer p.podLock.Unlock()
	status, ok := p.podSyncStatuses[pod.UID]
	if !ok {
		klog.ErrorS(nil, "Pod sync status does not exist, the worker should not be running", "pod", klog.KObj(pod), "podUID", pod.UID)
		return false, false
	}
	if status.IsTerminationRequested() {
		return false, false
	}
	if !p.allowStaticPodStart(status.fullname, pod.UID) {
		p.workQueue.Enqueue(pod.UID, wait.Jitter(p.backOffPeriod, workerBackOffPeriodJitterFactor))
		status.working = false
		return false, true
	}
	return true, true
}

4.流程3第15行。这个函数场景是静态pod有全名是一样的。如果当前的已经有启动的了并且是自己，则返回true。如果不是自己，是其他同名的启动成功，则返回false。

  • 先获取已启动的静态pod是当前pod，证明是当前pod已经启动了，返回true
  • 如果已启动的静态pod不是当前pod，证明有其他pod已经启动了，返回false（这种场景不应该关闭goroutine，继续一直循环状态，等待静态pod关闭，它好继续争抢）
  • 如果未启动成功，查看等待排队启动的静态pod
  • 如果等待启动的pod没有链路信息或者已经关闭或者关闭中，跳过这个pod
  • 如果等待启动的第一个pod和当前要处理的pod不是一个id，则直接返回false，并且更新缓存当前pod为最新的排队中的（这种场景不需要关闭goroutine，继续一直循环状态，下次循环进入，排队的第一个就是当前pod了）
  • 如果等待启动的pod和当前要处理的是同一个，则将当前pod变成已经启动的。并且把这个pod从未启动的pod数组移除。
func (p *podWorkers) allowStaticPodStart(fullname string, uid types.UID) bool {
	startedUID, started := p.startedStaticPodsByFullname[fullname]
	if started {
		return startedUID == uid
	}

	waitingPods := p.waitingToStartStaticPodsByFullname[fullname]
	for i, waitingUID := range waitingPods {
		status, ok := p.podSyncStatuses[waitingUID]
		if !ok || status.IsTerminationRequested() || status.IsTerminated() {
			continue
		}
		if waitingUID != uid {
			p.waitingToStartStaticPodsByFullname[fullname] = waitingPods[i:]
			return false
		}
		waitingPods = waitingPods[i+1:]
		break
	}
	if len(waitingPods) != 0 {
		p.waitingToStartStaticPodsByFullname[fullname] = waitingPods
	} else {
		delete(p.waitingToStartStaticPodsByFullname, fullname)
	}
	p.startedStaticPodsByFullname[fullname] = uid
	return true
}

5.流程2代码块的第4行 如果这个静态pod已经收到关闭或者删除信号了，将这个pod的更新信息及管道都清除。

  • cleanupPodUpdates函数关闭这个uid的管道。并且删除podUpdates的map，删除lastUndeliveredWorkUpdate的map
  • 从podSyncStatuses中取出这个pod的状态链，关闭working状态，finished状态为true，删除时间为现在。
  • 如果startedStaticPodsByFullname已经启动的pod中有此pod，则删掉这个pod的map信息
func (p *podWorkers) completeUnstartedTerminated(pod *v1.Pod) {
	p.podLock.Lock()
	defer p.podLock.Unlock()

	klog.V(4).InfoS("Pod never started and the worker can now stop", "pod", klog.KObj(pod), "podUID", pod.UID)

	p.cleanupPodUpdates(pod.UID)

	if status, ok := p.podSyncStatuses[pod.UID]; ok {
		if status.terminatingAt.IsZero() {
			klog.V(4).InfoS("Pod worker is complete but did not have terminatingAt set, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		if !status.terminatedAt.IsZero() {
			klog.V(4).InfoS("Pod worker is complete and had terminatedAt set, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		status.finished = true
		status.working = false
		status.terminatedAt = time.Now()

		if p.startedStaticPodsByFullname[status.fullname] == pod.UID {
			delete(p.startedStaticPodsByFullname, status.fullname)
		}
	}
}
  1. 这里的case判断是否为孤儿pod，如果是孤儿pod，不做什么操作，因为配置文件及状态已经没有了。如果不是孤儿pod则第六行，
    在本地缓存（运行时pod）作比较。如果本地缓存的pod的时间大于当前时间，则使用本地缓存的数据，否则返回个空
    最后一行contextForWorker，这里是给pod注册一个context.WithCancel函数，为了后续推出使用，上一篇说到过这个函数。
            var status *kubecontainer.PodStatus
			var err error
			switch {
			case update.Options.RunningPod != nil:
			default:
				status, err = p.podCache.GetNewerThan(pod.UID, lastSyncTime)
			}
			if err != nil {
				p.recorder.Eventf(pod, v1.EventTypeWarning, events.FailedSync, "error determining status: %v", err)
				return err
			}

			ctx := p.contextForWorker(pod.UID)

7.这里进行处理pod了

  • 第2行，如果是删除的pod工作（后续再看，量太大，执行了kubelet.go中的syncTerminatedPod函数）
  • 第5行，如果是进行删除的pod工作。第七行中如果pod有删除状态，取出删除状态的优雅删除事件，
  • 第10行是将pod的删除状态设置为true，同时注册一个函数，函数是这个pod的PodStatusFunc不为空时才会有。这个函数是当pod被kill时，执行可以覆盖pod状态
  • 第12行调用kubelet.go的处理函数，开始删除pod下的容器等信息（后续再看，量太大，需要几篇去写。执行了kubelet.go中的syncTerminatingPod函数）
  • 第15行代表这个pod是进行同步中的，调用kubelet.go的syncPod（后续再看，量太大）
  • 最后记录一下当前时间。
			switch {
			case update.WorkType == TerminatedPodWork:
				err = p.syncTerminatedPodFn(ctx, pod, status)

			case update.WorkType == TerminatingPodWork:
				var gracePeriod *int64
				if opt := update.Options.KillPodOptions; opt != nil {
					gracePeriod = opt.PodTerminationGracePeriodSecondsOverride
				}
				podStatusFn := p.acknowledgeTerminating(pod)

				err = p.syncTerminatingPodFn(ctx, pod, status, update.Options.RunningPod, gracePeriod, podStatusFn)

			default:
				isTerminal, err = p.syncPodFn(ctx, update.Options.UpdateType, pod, update.Options.MirrorPod, status)
			}

			lastSyncTime = time.Now()
			return err

8.上面的函数在kubelet.go中已经对容器和沙箱处理完了。开始对pod的状态进行处理

  • 第2行，如果是ctx退出的，则打印日志
  • 第5行，如果err不等nil，打印错误日志
  • 第8行，如果是已经删除的（流程9）
  • 第16行，如果是删除中的（流程10）
  • 第29行，如果是同步终端的（流程11）
	switch {
		case err == context.Canceled:
			klog.V(2).InfoS("Sync exited with context cancellation error", "pod", klog.KObj(pod), "podUID", pod.UID, "updateType", update.WorkType)

		case err != nil:
			klog.ErrorS(err, "Error syncing pod, skipping", "pod", klog.KObj(pod), "podUID", pod.UID)

		case update.WorkType == TerminatedPodWork:
			p.completeTerminated(pod)
			if start := update.Options.StartTime; !start.IsZero() {
				metrics.PodWorkerDuration.WithLabelValues("terminated").Observe(metrics.SinceInSeconds(start))
			}
			klog.V(4).InfoS("Processing pod event done", "pod", klog.KObj(pod), "podUID", pod.UID, "updateType", update.WorkType)
			return

		case update.WorkType == TerminatingPodWork:
			if update.Options.RunningPod != nil {
				p.completeTerminatingRuntimePod(pod)
				if start := update.Options.StartTime; !start.IsZero() {
					metrics.PodWorkerDuration.WithLabelValues(update.Options.UpdateType.String()).Observe(metrics.SinceInSeconds(start))
				}
				klog.V(4).InfoS("Processing pod event done", "pod", klog.KObj(pod), "podUID", pod.UID, "updateType", update.WorkType)
				return
			}
		
			p.completeTerminating(pod)
			phaseTransition = true

		case isTerminal:
			klog.V(4).InfoS("Pod is terminal", "pod", klog.KObj(pod), "podUID", pod.UID, "updateType", update.WorkType)
			p.completeSync(pod)
			phaseTransition = true
		}

9.流程8中的第8行

  • 先关掉pod的工作状态，因为是删除的了，所以pod的goroutine管道可以关闭了。同时删除这个pod的map信息和还未执行的变化。
  • 如果这个pod曾经有过整条状态链路，finished代表结束。同时将working工作中变为false，这样就不会阻塞后续的变化（虽然已经没有了）
  • 如果这个pod是已经启动的静态pod，删掉它
func (p *podWorkers) completeTerminated(pod *v1.Pod) {
	p.podLock.Lock()
	defer p.podLock.Unlock()

	klog.V(4).InfoS("Pod is complete and the worker can now stop", "pod", klog.KObj(pod), "podUID", pod.UID)

	p.cleanupPodUpdates(pod.UID)

	if status, ok := p.podSyncStatuses[pod.UID]; ok {
		if status.terminatingAt.IsZero() {
			klog.V(4).InfoS("Pod worker is complete but did not have terminatingAt set, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		if status.terminatedAt.IsZero() {
			klog.V(4).InfoS("Pod worker is complete but did not have terminatedAt set, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		status.finished = true
		status.working = false

		if p.startedStaticPodsByFullname[status.fullname] == pod.UID {
			delete(p.startedStaticPodsByFullname, status.fullname)
		}
	}
}

//上面函数的第七行
func (p *podWorkers) cleanupPodUpdates(uid types.UID) {
	if ch, ok := p.podUpdates[uid]; ok {
		close(ch)
	}
	delete(p.podUpdates, uid)
	delete(p.lastUndeliveredWorkUpdate, uid)
}

10.流程8的第16行
这里和上面的流程基本一样，需要看的是最后一个处理，将最后一个未更新的状态，变为当前pod，并且状态为已删除，这样下次再循环到这个pod的时候，就是进行彻底删除了

func (p *podWorkers) completeTerminating(pod *v1.Pod) {
	p.podLock.Lock()
	defer p.podLock.Unlock()

	klog.V(4).InfoS("Pod terminated all containers successfully", "pod", klog.KObj(pod), "podUID", pod.UID)

	if status, ok := p.podSyncStatuses[pod.UID]; ok {
		if status.terminatingAt.IsZero() {
			klog.V(4).InfoS("Pod worker was terminated but did not have terminatingAt set, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		status.terminatedAt = time.Now()
		for _, ch := range status.notifyPostTerminating {
			close(ch)
		}
		status.notifyPostTerminating = nil
		status.statusPostTerminating = nil
	}

	p.lastUndeliveredWorkUpdate[pod.UID] = podWork{
		WorkType: TerminatedPodWork,
		Options: UpdatePodOptions{
			Pod: pod,
		},
	}
}

11.流程8的第29行，与上方大同小异

func (p *podWorkers) completeSync(pod *v1.Pod) {
	p.podLock.Lock()
	defer p.podLock.Unlock()

	klog.V(4).InfoS("Pod indicated lifecycle completed naturally and should now terminate", "pod", klog.KObj(pod), "podUID", pod.UID)

	if status, ok := p.podSyncStatuses[pod.UID]; ok {
		if status.terminatingAt.IsZero() {
			status.terminatingAt = time.Now()
		} else {
			klog.V(4).InfoS("Pod worker attempted to set terminatingAt twice, likely programmer error", "pod", klog.KObj(pod), "podUID", pod.UID)
		}
		status.startedTerminating = true
	}

	p.lastUndeliveredWorkUpdate[pod.UID] = podWork{
		WorkType: TerminatingPodWork,
		Options: UpdatePodOptions{
			Pod: pod,
		},
	}
}

12.最后的工作

  • 第9行，如果状态转换成功了，添加到woekqueue队列，这个队列后续kubelt会读取，然后执行syncCh函数
  • 第11行，如果没有错误，写入队列
  • 第13行，如果错误是network is not ready网络原因，暂时退出过一会重试。写入队列
  • 第15行 在同步过程中发生错误；写入队列
  • 第18行为主要 （流程13）
  • 第3行，记录一下这个pod此次处理的开始时间到现在的秒数做记录
		p.completeWork(pod, phaseTransition, err)
		if start := update.Options.StartTime; !start.IsZero() {
			metrics.PodWorkerDuration.WithLabelValues(update.Options.UpdateType.String()).Observe(metrics.SinceInSeconds(start))
		}


//上面第一行函数
func (p *podWorkers) completeWork(pod *v1.Pod, phaseTransition bool, syncErr error) {
	switch {
	case phaseTransition:
		p.workQueue.Enqueue(pod.UID, 0)
	case syncErr == nil:
		p.workQueue.Enqueue(pod.UID, wait.Jitter(p.resyncInterval, workerResyncIntervalJitterFactor))
	case strings.Contains(syncErr.Error(), NetworkNotReadyErrorMsg):
		p.workQueue.Enqueue(pod.UID, wait.Jitter(backOffOnTransientErrorPeriod, workerBackOffPeriodJitterFactor))
	default:
		p.workQueue.Enqueue(pod.UID, wait.Jitter(p.backOffPeriod, workerBackOffPeriodJitterFactor))
	}
	p.completeWorkQueueNext(pod.UID)
}

13.这里是对pod的goroutine进行一些处理

  • 如果这个pod还有排队阻塞中的请求，就把这个请求推入到这个pod的goroutine中。
  • 如果没有了最新请求，让这个goroutine工作状态变为没有工作中。这样后续的数据才不会阻塞继续执行
func (p *podWorkers) completeWorkQueueNext(uid types.UID) {
	p.podLock.Lock()
	defer p.podLock.Unlock()
	if workUpdate, exists := p.lastUndeliveredWorkUpdate[uid]; exists {
		p.podUpdates[uid] <- workUpdate
		delete(p.lastUndeliveredWorkUpdate, uid)
	} else {
		p.podSyncStatuses[uid].working = false
	}
}

上一篇 kubelet源码 删除pod（二）

下一篇 kubelet源码 删除pod(SyncTerminatingPod函数)

Seaiio
关注
专栏目录
K8S集群中如何删除并重新部署pod
分享式获得也是一种学习的态度
02-27 2243
每个人都有惰性，但不断学习是好好生活的根本，共勉！
【K8S源码之Pod漂移】整体概况分析 controller-manager 中的 nodelifecycle controller（Pod的驱逐）
叮当猫的喵i
08-18 1313
有的话，进行 Pod 的逐个驱逐，检查 Pod 是否有该 Taint 的 toleration，有的话，就根据 toleration 设置 pod 的定时删除；zonePodEvictor 后续用于该 zone 中失联的 Node，用于 Node 级别驱逐（就是驱逐 Node 上所有 Pod，并设置为 evicted 状态，此部分参见）每个 zone 有不同数量的 Node，根据该 zone 中 Node 失联数量的占比，设置不同的驱逐速率。TainManager 的驱逐逻辑，看代码不难理解，大概说明。
kubelet源码 删除pod（一）
qq_35679620的博客
11-22 2494
kubelet删除pod源码分析
kubelet源码 删除pod pod_workers.go（二）
qq_35679620的博客
11-22 763
kubelet源码 删除pod（二）
Kubernetes源码分析之Pod的删除
weixin_34378922的博客
05-12 765
本文主要梳理删除Pod时，Pod的执行流程 kube-apiserver的任务 我们通常使用kubectl命令删除Pod，或者通过http协议直接调用apiserver暴露的接口去删除Pod。所以，删除Pod的起源肯定在apiserver这儿。 在之前分析kube-apiserver部分有分析到，kube-apiserver的http处理架构使用的是go-restful。其中，对于删除，调用的自然...
kubernetes/k8s CRI 分析-kubelet删除pod分析
良凯尔的博客
08-15 669
kubernetes CRI分析-k8s CRI分析。kubelet删除pod分析。kubelet调用CRI删除pod分析。kubernetes中有3个功能接口，分别是容器网络接口CNI、容器运行时接口CRI和容器存储接口CSI。本文会对kubelet调用CRI删除pod分析。
518. 【kubernetes】kubelet-之-Pod-管理
七镜的博客
06-10 132
如果发现本地的 Pod 需要被修改，则 kubelet 会做出对应的修改，比如在删除 Pod 中的某个容器时，会删除该容器。如果发现本地的 Pod 需要被删除，则 kubelet 会删除相应的 Pod，并删除 Pod 里的容器。kubelet 监听 etcd，所有针对 pod 的操作都会被 kubelet 监听。如果发现有新的绑定到本节点的 Pod，则按照 Pod 清单的要求创建该 Pod。kubelet 读取监听到的信息，如果是创建和修改 Pod 任务，则做如下处理。
kubelet源码-Pod处理流程
u014152978的博客
07-14 537
一、启动入口 kubelet启动时启动了syncLoop来处理pod的更新事件，podUpdate这个channel会wathch三个来源的pod变化，分别是file（本地静态pod）、apiserver、http。 // Run starts the kubelet reacting to config updates func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) { // 省略 .... // Sta.
kubelet源码解析-启动流程与POD处理(上)
ThinkMo的专栏
01-10 910
kubelet介绍 在k8s集群中的每个节点上都运行着一个kubelet服务进程，其主要负责向apiserver注册节点、管理pod及pod中的容器，并通过 cAdvisor 监控节点和容器的资源。 节点管理：节点注册、节点状态更新(定期心跳) pod管理：接受来自apiserver、file、http等PodSpec，并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好 容器健康检查：通过ReadinessProbe、LivenessProbe两种探针检查容器健康状态 资源监控：通过 cA
Kubernetes Eviction Manager源码分析
热门推荐
WaltonWang's Blog
02-21 1万+
本文作为Kubernetes Eviction Manager工作机制分析的后续篇，主要通过源码分析对其工作机制进行解读。
Kubernetes Node Controller源码分析之Taint Controller
WaltonWang's Blog
08-01 1万+
Node Controller是Kubernetes几十个Controller中最为重要的Controller之一，其重要程度在Top3，然而这可能也是最为复杂的一个Controller，因此对其的源码分析，我将做一个系列文章。本博文主要对Node Controller触发的Taint Controller进行源码分析，看看NoExecuteTaintManager是如何进行Taint Pod Evictions的。
kubectl delete
weixin_30522095的博客
10-23 908
kubectl delete通过配置文件名、stdin、资源名称或label选择器来删除资源。支持JSON和YAML格式文件。可以只指定一种类型的参数：文件名、资源名称或label选择器。有些资源，如pod，支持优雅的（graceful）删除，因为这些资源一般是集群中的实体，所以删除不可能会立即生效，这些资源在强制终止之前默认定义了一个周期（宽限期），但是你可以使用--grace-period f...
kubelet源码分析 添加 /删除pod (SyncPod、SyncTerminatingPod、SyncTerminatedPod)篇
qq_35679620的博客
05-24 1397
这篇文章是当pod_workers.go流程结束后，重新触发kubelet.go文件的SyncPod、SyncTerminatingPod、SyncTerminatedPod函数进行处理。 这三个函数主要是对kubelet这一层最后的校验，然后将要调用CRI部分进行创建容器了。
PodWorkers
韦远科的专栏
11-20 611
PodWorkers是最终“同步”pod状态的一块逻辑， “同步”在这里的含义是：确保kubelet所在节点的Pod状态和etcd中的状态一致，该增加的增加，该删除的删除，该更新的更新。 “同步”动作的触发有几个方式： （1）通过文件、apiserver、http方式监听到的变化 （2）定时器触发，例如每隔10s PodWorkers的入口是UpdatePod type podWorkers st...
云原生 | kubernetes - Pod创建/删除的原理及操作
Trollz的博客
10-19 3032
Cloud Native | The principle and operation of creating/deleting kubernetes - Pod
k8s源码分析-----kubelet pod处理流程
程序源234的专栏
09-10 3257
源码为k8s v1.3.0稳定版本 Go语言中通过chann进行跨协程通信，基于这点我们先找到通信的协程创建的流程 (1) UpdatePod channel的创建 CreateAndInitKubelet函数中，调用makePodSourceConfig创建。 k8s.io\kubernetes\cmd\kubelet\app\se
POD创建与删除简单描述
最新发布
weixin_42562106的博客
11-10 560
Pending：Pod 尚未被调度到任何节点。Running：Pod 已被调度到一个节点，并且所有容器都已启动并正在运行。Succeeded：Pod 中的所有容器都已成功终止。Failed：Pod 中的至少一个容器已失败。Unknown：Pod 的状态无法确定。Pending 阶段在 Pending 阶段，Pod 尚未被调度到任何节点。Pod 尚未被用户创建。Pod 已被创建，但调度器尚未将其调度到任何节点。Pod 已被调度到一个节点，但该节点尚未准备好运行 Pod。
docker内存溢出异常
默子昂
07-06 3668
E0630 15:40:19.507103 3953 pod_workers.go:191] Error syncing pod 2b0e72a7-3678-4554-aa27-45734035b5d6 ("chaosblade-tool-pv9sz_default(2b0e72a7-3678-4554-aa27-45734035b5d6)"), skipping: failed to "CreatePodSandbox" for "chaosblade-tool-pv9sz_default(2b0.
云原生|kubernetes部署和运行维护中的错误汇总（不定时更新）
zsk_john的技术分享专用博客
08-29 3796
两个文件都写了initial初始化，就冲突啦，而etcd-3.3以及之前的版本不会报错，两个文件可以重复配置。
μCOS-II任务管理源码解析：OS_TASK.C关键函数详解
本文档详细解读了μCOS-II的核心模块之一——OS_TASK.C源码，这在深入理解任务管理和调度机制方面提供了宝贵的教育资源。OS_TASK.C是μCOS-II中的关键文件，主要负责处理任务（tasks）的创建、调度、优先级管理和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值