GC控制器(Garbagecollector)源码解析

已于 2023-12-28 17:07:52 修改
阅读量1k 收藏 19
点赞数 21
分类专栏： 云原生 kubernetes 文章标签： kubernetes 云原生 controller gc
于 2023-12-28 17:05:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/q1403539144/article/details/135273951
版权

KubeController Garbagecollector

本文从源码的角度分析KubeController Garbagecollector相关功能的实现。

本篇kubernetes版本为v1.27.3。

kubernetes项目地址: https://github.com/kubernetes/kubernetes

controller命令main入口: cmd/kube-controller-manager/controller-manager.go

controller相关代码目录: pkg/controller
更多文章访问 https://www.cyisme.top

在k8s中， 像deployment、statefulset等这些资源都是属于higher-level的资源; 比如deployment会控制replicaset， replicaset会控制pod， 它们的创建、更新、删除等操作都是通过controller来完成的。
deployment
replicaset
pod

这些对象的关联关系， 会通过ownerReference来标识， 例如一个处于被控状态的replicaset的ownerReference会指向它的deployment，一个处于被控状态的pod的ownerReference会指向它的replicaset（在deployment的资源场景下）。

GC Controller的作用就是在资源被删除时， 通过ownerReference来生成一个“关联图”， 并利用这个“图”，来删除（或其他动作）它所控制的资源。

GC Controller启动时， 会调用RUN和Sync方法

func startGarbageCollectorController(ctx context.Context, controllerContext ControllerContext) (controller.Interface, bool, error) {
    // 省略部分代码
    // 用于创建metadata informer
    // finalizer的变动普通的informer是无法感知的， 所以需要使用metadata informer监听
	metadataClient, err := metadata.NewForConfig(config)
	if err != nil {
		return nil, true, err
	}
    // 创建GC Controller
	garbageCollector, err := garbagecollector.NewGarbageCollector(
		gcClientset,
		metadataClient,
		controllerContext.RESTMapper,
		ignoredResources,
		controllerContext.ObjectOrMetadataInformerFactory,
		controllerContext.InformersStarted,
	)
	if err != nil {
		return nil, true, fmt.Errorf("failed to start the generic garbage collector: %v", err)
	}

	// 启动gc进程
	go garbageCollector.Run(ctx, workers)

	// 定期刷新k8s中的资源列表， 并更新到informer监听中
    // 这里的作用是为了保证informer中的资源列表是最新的（全部的）
	go garbageCollector.Sync(ctx, discoveryClient, 30*time.Second)

	return garbageCollector, true, nil
}

组件信息

GC Controller从功能职责上，大致上可以分为两部分:

  • GarbageCollector: 负责执行清理动作
  • GraphBuilder: 负责list/watch资源， 更新并维护“关联图”
    GraphBuilder的作用是提供数据， GarbageCollector的作用是消费数据。从GarbageCollector定义可以看出：
type GarbageCollector struct {
    // 用于获取gvk
	restMapper     meta.ResettableRESTMapper
    // 用于获取资源
	metadataClient metadata.Interface
	// 待删除的队列
	attemptToDelete workqueue.RateLimitingInterface
	// 孤儿队列
	attemptToOrphan        workqueue.RateLimitingInterface
    // 生成“关联图”
	dependencyGraphBuilder *GraphBuilder
	// 缓存对象
	absentOwnerCache *ReferenceCache

	kubeClient       clientset.Interface
	eventBroadcaster record.EventBroadcaster
	workerLock sync.RWMutex
}

GraphBuilder

GraphBuilder代码文件: pkg/controller/garbagecollector/graph_builder.go

type GraphBuilder struct {
	restMapper meta.RESTMapper
    // list/watch资源
	monitors    monitors
	monitorLock sync.RWMutex
	informersStarted <-chan struct{}
	stopCh <-chan struct{}
	running bool
    // 事件记录
	eventRecorder record.EventRecorder
	metadataClient metadata.Interface
	// 存放发生变动的资源
	graphChanges workqueue.RateLimitingInterface
	// node是“图”中的节点， 存放关联信息
    // 这是一个map， key是资源的uid， value是一个node
	uidToNode *concurrentUIDToNode
	// 待删除资源
	attemptToDelete workqueue.RateLimitingInterface
    // 孤儿资源
	attemptToOrphan workqueue.RateLimitingInterface
	absentOwnerCache *ReferenceCache
	sharedInformers  informerfactory.InformerFactory
	ignoredResources map[schema.GroupResource]struct{}
}

monitor用于list/watch资源meta信息， 使用eventHandler机制， 将数据添加到graphChanges队列中。
informer
monitor
addHandler
graphChanges
updateHandler
deleteHandler

GraphBuilder的Run方法会启动monitors和graphChanges的处理。

func (gb *GraphBuilder) Run(ctx context.Context) {
    // 省略部分代码

    // 启动monitor， 数据list/watch
	gb.startMonitors(logger)
    // 启动数据处理
	wait.Until(func() { gb.runProcessGraphChanges(logger) }, 1*time.Second, ctx.Done())
    // 省略部分代码
}

最终资源间的关联关系会形成一个树状的关系图。
deployment
replicasetn new
replicaset old
pod1
pod2
pod1
pod2

Monitors

monitors是一个map类型，他以GVK为键，对应的informer为值.

type monitors map[schema.GroupVersionResource]*monitor
type monitor struct {
    // infomer的控制器和缓存
	controller cache.Controller
	store      cache.Store
	stopCh chan struct{}
}

gb.startMonitors其实就是对monitors中的所有infomer执行Run操作， 也就是启动list/watch,这里不展开说明。

gb.startMonitors除了在启动时调用， 还有一个resyncMonitors方法也调用了他。这个方法其实就是“整理”了一下monitors。 这个方法会被GarbageCollector.Sync调用。

func (gc *GarbageCollector) resyncMonitors(logger klog.Logger, deletableResources map[schema.GroupVersionResource]struct{}) error {
	if err := gc.dependencyGraphBuilder.syncMonitors(logger, deletableResources); err != nil {
		return err
	}
	gc.dependencyGraphBuilder.startMonitors(logger)
	return nil
}
func (gb *GraphBuilder) syncMonitors(logger klog.Logger, resources map[schema.GroupVersionResource]struct{}) error {
    // 省略部分代码
	toRemove := gb.monitors
	for resource := range resources {
		if _, ok := gb.ignoredResources[resource.GroupResource()]; ok {
			continue
		}
        // 如果已经存在， 则不需要再创建
		if m, ok := toRemove[resource]; ok {
			current[resource] = m
			delete(toRemove, resource)
			kept++
			continue
		}
        // 获取资源的GVK
		kind, err := gb.restMapper.KindFor(resource)
        // 创建informer
		c, s, err := gb.controllerFor(logger, resource, kind)
		current[resource] = &monitor{store: s, controller: c}
		added++
	}
	gb.monitors = current
    // 停止不需要的informer
	for _, monitor := range toRemove {
		if monitor.stopCh != nil {
			close(monitor.stopCh)
		}
	}
    // 省略部分代码
}

controllerFor中创建了infomer, 并添加handler，也就是将数据添加到graphChanges队列。

func (gb *GraphBuilder) controllerFor(logger klog.Logger, resource schema.GroupVersionResource, kind schema.GroupVersionKind) (cache.Controller, cache.Store, error) {
	handlers := cache.ResourceEventHandlerFuncs{
		// add the event to the dependencyGraphBuilder's graphChanges.
		AddFunc: func(obj interface{}) {
			event := &event{
				eventType: addEvent,
				obj:       obj,
				gvk:       kind,
			}
			gb.graphChanges.Add(event)
		},
        // 省略update和delete
        }
        // 省略创建informer
}

启动时调用的gb.startMonitors(logger)实际就是对所有monitor执行Run操作。

func (gb *GraphBuilder) startMonitors(logger klog.Logger) {
    // 省略部分代码
	for _, monitor := range monitors {
		if monitor.stopCh == nil {
			monitor.stopCh = make(chan struct{})
			gb.sharedInformers.Start(gb.stopCh)
			go monitor.Run()
			started++
		}
	}
}

runProcessGraphChanges

在执行资源的删除操作时， 会根据不同的删除策略更新finalizers， 从而触发update事件。

# 前台删除，finalizers中增加foregroundDeletion
kubectl delete deployment nginx-deployment --cascade=foreground
# 孤儿删除，finalizers中增加orphan
kubectl delete deployment nginx-deployment --cascade=orphan
# 后台删除，不更新finalizers
kubectl delete deployment nginx-deployment

后台/前台删除在感官上区别不大（在正常情况下，最终都会被删除）

  • 前台： 先删除从属对象，再删除主对象 （速度会慢一些， 从属对象的删除结果会影响主对象）
  • 后台： 先删除主对象，后台清理从属对象 （速度快一些， 从属对象的删除结果不会影响主对象）
  • 孤儿： 删除主对象，不清理从属对象
删除动作
更新finalizers
controller监听
级联处理
删除对象

对象变动被监听到后， 会由processGraphChanges函数处理， 这个函数会从graphChanges队列中获取数据， 并更新uidToNode， 然后分发到attemptToDelete和attemptToOrphan。
monitor
graphChanges
uidToNode
attemptToDelete
attemptToOrphan

一个资源有可能有多个owner, 所以需对每个owner的身份信息进行处理。

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-12-27T10:11:00Z"
  generateName: test-5f6778868d-
  labels:
    app: test
    pod-template-hash: 5f6778868d
  name: test-5f6778868d-6zt4h
  namespace: default
  ownerReferences:
  // ownerReferences是一个数组， 代表有多个owner
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: test-5f6778868d
    uid: a5a436cb-3212-4fbe-85d3-ec80ab9b4208
  resourceVersion: "50228752"
  uid: 0bce606e-1f1c-4f6f-bba0-229a55cb656b

先来看一个频繁出现的处理函数partitionDependents。这个函数用于判断给定的依赖列表，与给定的owner身份信息是否匹配， 最终返回匹配/不匹配两个列表。

  1. 检测当前依赖的ns与给定owner的ns是否一致
  2. 检测当前依赖的owners中，是否有与给定owner uid一致的
  3. 如果当前依赖中的某个owner与给定owner uid一致， 则检测ownerReference中的其他字段是否一致
func partitionDependents(dependents []*node, matchOwnerIdentity objectReference) (matching, nonmatching []*node) {
    // 判断是否有ns绑定
	ownerIsNamespaced := len(matchOwnerIdentity.Namespace) > 0
	for i := range dependents {
		dep := dependents[i]
		foundMatch := false
		foundMismatch := false
		// 如果命名空间不匹配， 则直接认为不匹配
		if ownerIsNamespaced && matchOwnerIdentity.Namespace != dep.identity.Namespace {
			// all references to the parent do not match, since the dependent namespace does not match the owner
			foundMismatch = true
		} else {
			for _, ownerRef := range dep.owners {
				// 如果uid匹配， 则进行更细致的判断
				if ownerRef.UID == matchOwnerIdentity.UID {
					// 对剩余的其他字段进行匹配检测， uid、name、apiVersion、kind
					if ownerReferenceMatchesCoordinates(ownerRef, matchOwnerIdentity.OwnerReference) {
						foundMatch = true
					} else {
						foundMismatch = true
					}
				}
			}
		}

		if foundMatch {
			matching = append(matching, dep)
		}
		if foundMismatch {
			nonmatching = append(nonmatching, dep)
		}
	}
	return matching, nonmatching
}

processGraphChanges中就用到了上述的partitionDependents来处理依赖关系。

func (gb *GraphBuilder) processGraphChanges(logger klog.Logger) bool {
    // 获取数据
	item, quit := gb.graphChanges.Get()
	if quit {
		return false
	}
	// 省略部分代码
    // item最终会被转换成accessor
	accessor, err := meta.Accessor(obj)
	
	existingNode, found := gb.uidToNode.Read(accessor.GetUID())
    // 不会以虚拟事件更新真实节点
    // 如果节点已经存在， 且已经存在的节点为虚拟节点、当前的事件非虚拟事件
	if found && !event.virtual && !existingNode.isObserved() {
		// 获取观察到的身份信息
		observedIdentity := identityFromEvent(event, accessor)
        // 如果观察到的身份信息和已经存在的节点身份信息不一致
		if observedIdentity != existingNode.identity {
			// 找到与当前观察到的身份信息不匹配的依赖
			_, potentiallyInvalidDependents := partitionDependents(existingNode.getDependents(), observedIdentity)
			// 不匹配的依赖会放到待删除的队列中
			for _, dep := range potentiallyInvalidDependents {
				if len(observedIdentity.Namespace) > 0 && dep.identity.Namespace != observedIdentity.Namespace {
					// 会记录事件
					gb.reportInvalidNamespaceOwnerRef(dep, observedIdentity.UID)
				}
                // 放到待清理队列中
				gb.attemptToDelete.Add(dep)
			}
            // 更新节点的身份信息
			existingNode = existingNode.clone()
			existingNode.identity = observedIdentity
			gb.uidToNode.Write(existingNode)
		}
        // 将virtual标记为false，代表是观察到的真实节点
		existingNode.markObserved()
	}
	switch {
	case (event.eventType == addEvent || event.eventType == updateEvent) && !found:
		newNode := &node{
			identity:           identityFromEvent(event, accessor),
			dependents:         make(map[*node]struct{}),
			owners:             accessor.GetOwnerReferences(),
			deletingDependents: beingDeleted(accessor) && hasDeleteDependentsFinalizer(accessor),
			beingDeleted:       beingDeleted(accessor),
		}
        // 将节点添加到uidToNode中，并解析其owners写入关联关系
        // 如果owner在uidToNode不存在， 则会创建一个虚拟节点
        // 虚拟节点将会被添加到待删除队列， 再后续的处理中将会对这个虚拟节点进行真实性核对
		gb.insertNode(logger, newNode)
		// 如果是更新事件， 需要处理ownerReference的变化
        // 判断对象中的fiinalizers的变化， 从而放到不同的队列中
        // 如果finalizers中有foregroundDeletion， 则放到attemptToDelete队列中. 并标记为isDeletingDependents
        // 如果finalizers中有forphan， 则放到attemptToOrphan队列中
		gb.processTransitions(logger, event.oldObj, accessor, newNode)
	case (event.eventType == addEvent || event.eventType == updateEvent) && found:
		// 对比差异， 并差异更新
		added, removed, changed := referencesDiffs(existingNode.owners, accessor.GetOwnerReferences())
		if len(added) != 0 || len(removed) != 0 || len(changed) != 0 {
			// 分别判断removed，和change的BlockOwnerDeletion的状态，决定是否放到attemptToDelete队列中
			gb.addUnblockedOwnersToDeleteQueue(logger, removed, changed)
			// 更新节点数据
			existingNode.owners = accessor.GetOwnerReferences()
			// 添加到从属列表
			gb.addDependentToOwners(logger, existingNode, added)
			// 删除关联关系
			gb.removeDependentFromOwners(existingNode, removed)
		}
        // 如果当前节点有DeletionTimestamp, 代表正在删除中， 更新其标记
		if beingDeleted(accessor) {
			existingNode.markBeingDeleted()
		}
		gb.processTransitions(logger, event.oldObj, accessor, existingNode)
	case event.eventType == deleteEvent:
        // 省略不存在则跳过的代码
		removeExistingNode := true
        // 虚拟事件代表不是从infomer监听到的
        // 如果查找的节点没有找到， 会生成一个虚拟节点， 并创建虚拟事件
		if event.virtual {
			// this is a virtual delete event, not one observed from an informer
			deletedIdentity := identityFromEvent(event, accessor)
			if existingNode.virtual {

				// 获取节点关联信息
				if matchingDependents, nonmatchingDependents := partitionDependents(existingNode.getDependents(), deletedIdentity); len(nonmatchingDependents) > 0 {
					removeExistingNode = false
                    // 匹配到的依赖会放到attemptToDelete队列中
                    // 将当前节点的身份信息放到absentOwnerCache
                    // absentOwnerCache用来存放未找到的节点
					if len(matchingDependents) > 0 {
						gb.absentOwnerCache.Add(deletedIdentity)
						for _, dep := range matchingDependents {
							gb.attemptToDelete.Add(dep)
						}
					}

					// 更新虚拟节点信息
					if existingNode.identity == deletedIdentity {
						replacementIdentity := getAlternateOwnerIdentity(nonmatchingDependents, deletedIdentity)
						if replacementIdentity != nil {
							replacementNode := existingNode.clone()
							replacementNode.identity = *replacementIdentity
							gb.uidToNode.Write(replacementNode)
							// 从新入队
							gb.attemptToDelete.AddRateLimited(replacementNode)
						}
					}
				}

			} else if existingNode.identity != deletedIdentity {
				// 不会根据因为虚拟事件删除真实节点
				removeExistingNode = false
            
				matchingDependents, _ := partitionDependents(existingNode.getDependents(), deletedIdentity)
                // 更新缺失缓存
                // 关联删除
				if len(matchingDependents) > 0 {
					// mark the observed deleted identity as absent
					gb.absentOwnerCache.Add(deletedIdentity)
					// attempt to delete dependents that do match the verified deleted identity
					for _, dep := range matchingDependents {
						gb.attemptToDelete.Add(dep)
					}
				}
			}
		}

		if removeExistingNode {
			// 删除节点
			gb.removeNode(existingNode)
			existingNode.dependentsLock.RLock()
			defer existingNode.dependentsLock.RUnlock()
			if len(existingNode.dependents) > 0 {
				gb.absentOwnerCache.Add(identityFromEvent(event, accessor))
			}
			for dep := range existingNode.dependents {
				gb.attemptToDelete.Add(dep)
			}
			for _, owner := range existingNode.owners {
                // 如果owner是正在删除的状态， 即等待从属节点删除结束， 则放到attemptToDelete队列中
                // isDeletingDependents状态是由processTransitions方法标记的
				ownerNode, found := gb.uidToNode.Read(owner.UID)
				if !found || !ownerNode.isDeletingDependents() {
					continue
				}
				gb.attemptToDelete.Add(ownerNode)
			}
		}
	}
	return true
}

GarbageCollector

在这里插入图片描述

GarbageCollector的Run方法会启动GraphBuilder和runAttemptToDeleteWorker、runAttemptToOrphanWorker。

  • attemptToDelete 处理待删除的资源
  • attemptToOrphan 处理孤儿资源
func (gc *GarbageCollector) Run(ctx context.Context, workers int) {
	// 省略部分代码
    // 启动GraphBuilder
	go gc.dependencyGraphBuilder.Run(ctx)
    // 省略部分代码

    // 启动工作进程
	for i := 0; i < workers; i++ {
		go wait.UntilWithContext(ctx, gc.runAttemptToDeleteWorker, 1*time.Second)
		go wait.Until(func() { gc.runAttemptToOrphanWorker(logger) }, 1*time.Second, ctx.Done())
	}
}

因为主要的数据处理逻辑都由GraphBuilder完成， 所以GarbageCollector的处理逻辑就简单一些

runAttemptToDeleteWorker

runAttemptToDeleteWorker处理待删除的资源

func (gc *GarbageCollector) processAttemptToDeleteWorker(ctx context.Context) bool {
	item, quit := gc.attemptToDelete.Get()
	gc.workerLock.RLock()
	defer gc.workerLock.RUnlock()
	if quit {
		return false
	}
	defer gc.attemptToDelete.Done(item)

	action := gc.attemptToDeleteWorker(ctx, item)
	switch action {
	case forgetItem:
        // 代表处理完成，从队列中删除
		gc.attemptToDelete.Forget(item)
	case requeueItem:
        // 代表处理失败，重新入队
		gc.attemptToDelete.AddRateLimited(item)
	}

	return true
}

这里跳过对gc.attemptToDeleteWorker的代码展开。

gc.attemptToDeleteWorker最终调用的是attemptToDeleteItem。

gc.attemptToDeleteWorker主要是做了一些状态判断和错误判断，用于返回action。

最终的删除动作是由gc.deleteObject执行的， 它会调用api删除资源， 以此实现递归删除。

attemptToDeleteItem中出现的gc.classifyReferences方法，是用于检查owner的状态， 并返回三个列表:

  • solid 代表存在的owner资源列表，这个owner不能处于"删除中"的状态
  • dangling 代表不存在的owner资源列表，这个owner已经不存在与集群中了
  • waitingForDependentsDeletion 代表存在的owner资源列表，这个owner处于"删除中"的状态
    当执行删除时， 会根据这三个列表的情况， 来决定删除策略。
func (gc *GarbageCollector) attemptToDeleteItem(ctx context.Context, item *node) error {
	// 省略部分代码

    // 从api中获取对象
	latest, err := gc.getObject(item.identity)
	switch {
    // 未找到时代表item是一个虚拟节点
	case errors.IsNotFound(err):
		// 会生成一个虚拟删除事件
		gc.dependencyGraphBuilder.enqueueVirtualDeleteEvent(item.identity)
		return enqueuedVirtualDeleteEventErr
	case err != nil:
		return err
	}
    // 如果uid不匹配，会生成一个虚拟删除事件
	if latest.GetUID() != item.identity.UID {
		gc.dependencyGraphBuilder.enqueueVirtualDeleteEvent(item.identity)
		return enqueuedVirtualDeleteEventErr
	}

    // 移除finalizers
	if item.isDeletingDependents() {
		return gc.processDeletingDependentsItem(logger, item)
	}
	ownerReferences := latest.GetOwnerReferences()
    // solid 代表有owner的资源
    // dangling 代表没有owner的资源
    // waitingForDependentsDeletion 代表有owner， 但是owner正在删除中,并且有finalizers
	solid, dangling, waitingForDependentsDeletion, err := gc.classifyReferences(ctx, item, ownerReferences)

	switch {
	case len(solid) != 0:
        // 如果有solid， 代表有owner， 还不能删除这个资源
        // 省略部分代码
        // 
        // 但是可以调用api更新资源ref信息，从ref中移除已经不存在的owner和正在删除中的owner
		ownerUIDs := append(ownerRefsToUIDs(dangling), ownerRefsToUIDs(waitingForDependentsDeletion)...)
		p, err := c.GenerateDeleteOwnerRefStrategicMergeBytes(item.identity.UID, ownerUIDs)
		_, err = gc.patch(item, p, func(n *node) ([]byte, error) {
			return gc.deleteOwnerRefJSONMergePatch(n, ownerUIDs...)
		})
		return err
	case len(waitingForDependentsDeletion) != 0 && item.dependentsLength() != 0:
		deps := item.getDependents()
		for _, dep := range deps {
			if dep.isDeletingDependents() {
				// 先调用api将其依赖的blockOwnerDeletion设置为false
				patch, err := item.unblockOwnerReferencesStrategicMergePatch()
				if err != nil {
					return err
				}
				if _, err := gc.patch(item, patch, gc.unblockOwnerReferencesJSONMergePatch); err != nil {
					return err
				}
				break
			}
		}
		// 所有owner都处于可删除的状态， 那么可以删除这个资源(进入递归删除)
        // 当这个资源再次被监听到时， 因为关联已经被清空（假如已清空）， 所以会直接删除
		policy := metav1.DeletePropagationForeground
		return gc.deleteObject(item.identity, &policy)
	default:
		// 如果没有owner则需要进行垃圾回收
        // 根据其finalizers中的信息， 选择不同的删除策略
		var policy metav1.DeletionPropagation
		switch {
		case hasOrphanFinalizer(latest):
			policy = metav1.DeletePropagationOrphan
		case hasDeleteDependentsFinalizer(latest):
			policy = metav1.DeletePropagationForeground
		default:
			policy = metav1.DeletePropagationBackground
		}
		return gc.deleteObject(item.identity, &policy)
	}
}

runAttemptToOrphanWorker

孤儿资源的处理就相对比较简:

  1. 对所有关联资源的ownerReference进行更新， 解除关联关系。 如删除deployments时指定孤儿删除， 那么关联的rs的ownerReference中会移除这个deployment。
  2. 删除finalizers使其可以被删除
  3. 等待再次被监听到时执行删除操作
func (gc *GarbageCollector) attemptToOrphanWorker(logger klog.Logger, item interface{}) workQueueItemAction {
	// 省略部分代码
    // 
    // 更新关联资源的ownerReference
	err := gc.orphanDependents(logger, owner.identity, dependents)
	if err != nil {
		utilruntime.HandleError(fmt.Errorf("orphanDependents for %s failed with %v", owner.identity, err))
		return requeueItem
	}
	// 删除finalizers
	err = gc.removeFinalizer(logger, owner, metav1.FinalizerOrphanDependents)
	if err != nil {
		utilruntime.HandleError(fmt.Errorf("removeOrphanFinalizer for %s failed with %v", owner.identity, err))
		return requeueItem
	}
	return forgetItem
}
func (gc *GarbageCollector) orphanDependents(logger klog.Logger, owner objectReference, dependents []*node) error {
    // 多线程处理
	wg := sync.WaitGroup{}
	wg.Add(len(dependents))
	for i := range dependents {
		go func(dependent *node) {
			defer wg.Done()
			// 生成patch的请求内容
			p, err := c.GenerateDeleteOwnerRefStrategicMergeBytes(dependent.identity.UID, []types.UID{owner.UID})
			// 执行patch, 删除对应的owner信息
			_, err = gc.patch(dependent, p, func(n *node) ([]byte, error) {
                // 这里是兼容处理， 实际干的是同一件事
				return gc.deleteOwnerRefJSONMergePatch(n, owner.UID)
			})
		}(dependents[i])
	}
	wg.Wait()
	close(errCh)
    // 省略部分代码
	return nil
}

总结

  1. 在执行删除资源时， 不同的删除策略会使资源在finalizers中增加不同的字段， 从而触发不同的处理逻辑。
  2. 想要删除一个资源需要满足几个条件：
    1. 清空关联关系
    2. 无owner
    3. finalizers为空
  3. 不同的删除策略决定了上述几个条件具体执行的方式， 但最终需要满足的条件是一致。
  4. 删除是按固定的逻辑执行的，整个流程可以理解为递归的处理方式。
随风奔跑尿飞扬
关注
专栏目录
JVM垃圾回收器介绍与调优技巧
程序员光剑
08-06 680
Java虚拟机(JVM)是运行Java应用程序的核心组件之一，其作用是负责字节码的编译、加载、运行等任务。JVM是一个庞大的体系结构，包括一个类装载器、解释器、JIT（即时编译器）优化器、垃圾回收系统、安全管理器等模块。随着Java技术的不断发展，越来越多的开发人员开始关注JVM性能调优，如何在不影响程序执行效率的前提下，提升JVM的运行速度、降低内存占用、减少GC频率、最大限度提高吞吐量等方面，都成为了大家追求的目标。
Kubernetes1.3新特性：新的资源回收控制器
weixin_30375247的博客
08-29 140
(一) 核心概念 在kubernetes1.3中新增了一个资源回收控制器GarbaseCollector，用这个控制器来替代kubernetes1.3中的资源回收控制器GC。 如下为kubernetes1.2中的资源回收控制器结构体： 如下为kubernetes1.3中的资源回收控制器结构体： 在kubernetes1.2中，如果要实现对资源级联回收功能，...
k8s controller-manager之podGc源码分析
polarwu的博客
06-08 534
源码基于k8s 1.9 release 源码目录结构 cmd/kube-controller-manager/app/core.go:237 // PodGc Controller的启动代码，包含很多其它controller的启动 /pkg/controller/podgc . ├── BUILD ├── OWNERS ├── doc.go ├── gc_controller....
Kubernetes PodGC Controller源码分析
weixin_34408717的博客
08-13 197
2019独角兽企业重金招聘Python工程师标准>>> ...
k8s控制器源码解读
wxd1234567890的博客
01-12 1733
replicaset 控制器 引用 https://draveness.me/kubernetes-replicaset/ https://cloud.tencent.com/developer/article/1554675 Kubernetes 中的 ReplicaSet 主要的作用是维持一组 Pod 副本的运行，它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行，它会持续监听这些 Pod 的运行状态，在 Pod 发生故障重启数量减少时重新运行新的 Pod 副本。这篇文章会介绍 Repli
lua源码解析
sinat_34382237的博客
01-16 2913
（一）概述： lua核心部分仅包括lua虚拟机的运转。lua虚拟机的行为是由一组组opcode控制的。这些opcode定义在lopcodes.h及lopcodes.c中。而虚拟机对opcode 的解析和运作在lvm.c中，其API以luaV为前缀。lua虚拟机的外在数据形式是一个lua_State结构体，取名State大概意为 Lua虚拟机的当前状态。全局State引用了整个虚拟机的所有数据。这
（学习总结）JDK源码解析
喻小清的博客
09-10 2828
目录 一、Jdk源码解析过程 二、java虚拟机运行时数据区 1、Java虚拟机的五大分区 三、OutOfMemory异常实践（OOM）  1、Java堆溢出 2、虚拟机栈和本地方法栈溢出 3、方法区和运行时常量池溢出 4、本机直接内存溢出 四、垃圾回收 （1）堆的回收 （2）方法区的回收 （3）垃圾回收算法 （4）如何回收  （5）垃圾收集器（七种） （6）内存分配...
Java ThreadLocalMap 源码解析
TinyCS
10-12 2342
1. 概述 ThreadLocalMap是一种类似java.util.HashMap的数据结构。 ThreadLocalMap是java.lang.ThreadLocal类的静态内部类。 ThreadLocalMap主要是作为成员变量，应用在java.lang.Thread类。 探索ThreadLocalMap，有助于理解多线程并发环境下ThreadLocal的实现原理。 本文涉及的源码为Orac...
JDK源码解析/深入理解Reference和ReferenceQueue
shi2huang的博客
04-27 625
一、Reference简介1.reference状态Active：新创建的实例状态，当被垃圾收集器回收时，如果实例注册时候指定了队列，则变成Pending状态，否则变成Inactive状态。Pending：pending-Reference列表的一个元素，等待被Reference-handler线程入队。解注册的实例不会是这种状态。Enqueued：实例创建的时候指定的queue的一个元素，当实例...
kubeadm加入master节点失败，报错 error execution phase check-etcd: etcd cluster is not healthy: context deadli
Extreme的博客
07-24 2523
出现这个报错，多是因为之前的集群信息没有清理干净。 解决办法如下： 执行命令，获取etcd节点列表。 kubectl get pod -n kube-system etcd节点名称为 “etcd”+hostname 这里以 etcd-k8s-master1 为例, 进入etcd容器内部 kubectl exec -ti etcd-k8s-master1 -n kube-system sh # k8s中etcd使用的是v3的api， 所以要先声明变量 export ETCDCTL_API=3 # 执行命令，
golang中对于docker sdk的使用
Extreme的博客
04-21 2418
本文涉及到使用golang docker sdk 进行 pull、exec、push、import等常见操作的教程，对官方文档缺失的示例进行了补充。 docker sdk 官方文档：https://docs.docker.com/engine/api/sdk/examples/ docker client 初始化 docker client 有多种初始化方法， 本文使用从env中读取的方式。 client, _ := client.NewClientWithOpts(client.FromEnv, clie
生产级kubernetes etcd数据目录更换
Extreme的博客
04-13 2224
使用kubeadm搭建的k8s集群，默认etcd的数据目录为 /var/lib/etcd 。 集群运行一段时间后， 发现在系统硬盘上的etcd即占空间，又影响速度。所以将其数据目录迁移到ssd中。 注意 修改配置文件后，etcd会自动重启，并且导致对应机器的kubectl不可用。 所以请一台一台修改，etcd leader 节点放到最后操作，并且确保其他机器的kubectl可用。 vim /etc...
解决k8s环境harbor无法上传大镜像的问题
Extreme的博客
07-20 2123
无法上传大镜像多半是ingress nginx 中超时限制和大小限制的原因。 ingress nginx 安装的namespace 一般为 ingress-nginx 执行 kubectl get cm -n ingress-nginx NAME DATA AGE custom-client-headers 5 101d custom-headers
如何实现一个K8S DevicePlugin?
Extreme的博客
02-21 1625
k8s允许限制容器对资源的使用，比如CPU和内存，并以此作为调度的依据。当其他非官方支持的设备类型需要参与到k8s的工作流程中时，就需要实现一个。Kubernetes提供了一个设备插件框架，你可以用它来将系统硬件资源发布到Kubelet。供应商可以实现设备插件，由你手动部署或作为 DaemonSet 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、 InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
Volcano Scheduler调度器源码解析
Extreme的博客
01-09 1569
本文从源码的角度分析Volcano Scheduler相关功能的实现。本篇Volcano版本为v1.8.0。Volcano项目地址:controller命令main入口: cmd/scheduler/main.gocontroller相关代码目录: pkg/scheduler更多文章访问:看过我之前文章的朋友应该已经大致了解了k8s原生调度器的运行逻辑了。大致运行流程:fill:#333;color:#333;color:#333;fill:none;
为 k8s nginx ingress controller添加错误页面
Extreme的博客
08-11 1476
创建错误页面 kubectl apply -f error-page.yaml -n ingress-nginx apiVersion: v1 kind: ConfigMap metadata: name: error-page namespace: ingress-nginx data: 404.html: |- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR
从源码解析Kruise(K8S)原地升级原理
Extreme的博客
02-21 1347
原地升级的原理比较简单， 主要还是利用了pod自身的特性和kubelet的拉起功能。kruise中仅对自己的支持原地升级， 其实也可以扩展到对原生资源的支持（如一开始的测试），但会存在一些问题和限制（如测试二中deployment的镜像版本不会发生改变）。
如何实现一个CSI？源码解析csi-nfs
最新发布
Extreme的博客
02-28 1194
/ 对于块设备的挂载与卸载// 文件系统的挂载与卸载// 状态获取// 扩容// 容量获取// 基本信息// grpc服务会调用此具体实现// 挂载指定路径，不可包含敏感项// 与mount一致， 但是可以包含敏感项（如密码）并不会被记录// 与MountSensitive一致，但禁用systemd// 与MountSensitiveWithoutSystemd一致， 但包含附加选项// 卸载// 返回挂载点列表。
Java虚拟机GC算法与收集器解析
9. 调优GC涉及到设置合适的JVM参数，例如-Xms、-Xmx控制堆内存大小，-XX:NewRatio调整新生代与老年代的比例，-XX:SurvivorRatio控制新生代 survivor 区域的比例，-XX:+UseConcMarkSweepGC启用特定的收集器等。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值