kubelet gc源码分析

2024-05-10 17:58
文章标签 分析 源码 gc kubelet

本文主要是介绍kubelet gc源码分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

kubelet是负载干活的组件,它会定期的清理多余死掉的容器和镜像,这篇blog基于kubernetes1.7.6的代码,关于gc的深入源码分析
好了,先看gc是随着kubelet启动而启动的pkg/kubelet/kubelet.go,

func (kl *Kubelet) StartGarbageCollection() {loggedContainerGCFailure := falsego wait.Until(func() {if err := kl.containerGC.GarbageCollect(); err != nil {glog.Errorf("Container garbage collection failed: %v", err)kl.recorder.Eventf(kl.nodeRef, v1.EventTypeWarning, events.ContainerGCFailed, err.Error())loggedContainerGCFailure = true} else {var vLevel glog.Level = 4if loggedContainerGCFailure {vLevel = 1loggedContainerGCFailure = false}glog.V(vLevel).Infof("Container garbage collection succeeded")}}, ContainerGCPeriod, wait.NeverStop)prevImageGCFailed := falsego wait.Until(func() {if err := kl.imageManager.GarbageCollect(); err != nil {if prevImageGCFailed {glog.Errorf("Image garbage collection failed multiple times in a row: %v", err)// Only create an event for repeated failureskl.recorder.Eventf(kl.nodeRef, v1.EventTypeWarning, events.ImageGCFailed, err.Error())} else {glog.Errorf("Image garbage collection failed once. Stats initialization may not have completed yet: %v", err)}prevImageGCFailed = true} else {var vLevel glog.Level = 4if prevImageGCFailed {vLevel = 1prevImageGCFailed = false}glog.V(vLevel).Infof("Image garbage collection succeeded")}}, ImageGCPeriod, wait.NeverStop)
}

上面代码分别启动的容器的gc(containerGC.GarbageCollect())和镜像的gc(imageManager.GarbageCollect()),
先看容器的gc pkg/kubelet/kuberuntime/kuberuntime_gc.go,

func (cgc *containerGC) GarbageCollect(gcPolicy kubecontainer.ContainerGCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {// Remove evictable containersif err := cgc.evictContainers(gcPolicy, allSourcesReady, evictNonDeletedPods); err != nil {return err}// Remove sandboxes with zero containersif err := cgc.evictSandboxes(evictNonDeletedPods); err != nil {return err}// Remove pod sandbox log directoryreturn cgc.evictPodLogsDirectories(allSourcesReady)
}

这里删除容器分为两个部分,一个是删除业务容器,一个是删除Sandbox容器,当然最后都会去删除他们的日志目录。

业务容器删除

先看删除业务容器的过程

func (cgc *containerGC) evictContainers(gcPolicy kubecontainer.ContainerGCPolicy, allSourcesReady bool, evictNonDeletedPods bool) error {// Separate containers by evict units.evictUnits, err := cgc.evictableContainers(gcPolicy.MinAge)if err != nil {return err}// Remove deleted pod containers if all sources are ready.if allSourcesReady {for key, unit := range evictUnits {if cgc.isPodDeleted(key.uid) || evictNonDeletedPods {cgc.removeOldestN(unit, len(unit)) // Remove all.delete(evictUnits, key)}}}// Enforce max containers per evict unit.if gcPolicy.MaxPerPodContainer >= 0 {cgc.enforceMaxContainersPerEvictUnit(evictUnits, gcPolicy.MaxPerPodContainer)}// Enforce max total number of containers.if gcPolicy.MaxContainers >= 0 && evictUnits.NumContainers() > gcPolicy.MaxContainers {// Leave an equal number of containers per evict unit (min: 1).numContainersPerEvictUnit := gcPolicy.MaxContainers / evictUnits.NumEvictUnits()if numContainersPerEvictUnit < 1 {numContainersPerEvictUnit = 1}cgc.enforceMaxContainersPerEvictUnit(evictUnits, numContainersPerEvictUnit)// If we still need to evict, evict oldest first.numContainers := evictUnits.NumContainers()if numContainers > gcPolicy.MaxContainers {flattened := make([]containerGCInfo, 0, numContainers)for key := range evictUnits {flattened = append(flattened, evictUnits[key]...)}sort.Sort(byCreated(flattened))cgc.removeOldestN(flattened, numContainers-gcPolicy.MaxContainers)}}return nil
}

上面的代码做的多层判断,首先是删除超过gcPolicy.MinAge时间死掉pod的容器,然后删除单个pod运行最大死亡容器gcPolicy.MaxPerPodContainer,最后是删除整个机器上面死亡容器的上限。
evictContainers是过去可以驱逐的容器(退出且超过gcPolicy.MinAge时间的容器)具体看下面:

func (cgc *containerGC) evictableContainers(minAge time.Duration) (containersByEvictUnit, error) {containers, err := cgc.manager.getKubeletContainers(true)...for _, container := range containers {if container.State == runtimeapi.ContainerState_CONTAINER_RUNNING {continue}createdAt := time.Unix(0, container.CreatedAt)if newestGCTime.Before(createdAt) {continue}...
}

然后是删除单个pod死亡容器上限的

func (cgc *containerGC) enforceMaxContainersPerEvictUnit(evictUnits containersByEvictUnit, MaxContainers int) {for key := range evictUnits {toRemove := len(evictUnits[key]) - MaxContainersif toRemove > 0 {evictUnits[key] = cgc.removeOldestN(evictUnits[key], toRemove)}}
}

最后是删除超过上限的死亡容器

numContainers := evictUnits.NumContainers()if numContainers > gcPolicy.MaxContainers {flattened := make([]containerGCInfo, 0, numContainers)for key := range evictUnits {flattened = append(flattened, evictUnits[key]...)}sort.Sort(byCreated(flattened))cgc.removeOldestN(flattened, numContainers-gcPolicy.MaxContainers)}

Sandbox容器删除

然后是删除Sandbox容器,这里pkg/kubelet/kuberuntime/kuberuntime_gc.go

func (cgc *containerGC) evictSandboxes(evictNonDeletedPods bool) error {containers, err := cgc.manager.getKubeletContainers(true)if err != nil {return err}sandboxes, err := cgc.manager.getKubeletSandboxes(true)if err != nil {return err}sandboxesByPod := make(sandboxesByPodUID)for _, sandbox := range sandboxes {podUID := types.UID(sandbox.Metadata.Uid)sandboxInfo := sandboxGCInfo{id:         sandbox.Id,createTime: time.Unix(0, sandbox.CreatedAt),}// Set ready sandboxes to be active.if sandbox.State == runtimeapi.PodSandboxState_SANDBOX_READY {sandboxInfo.active = true}// 查询这个Sandbox是否有关联容器hasContainers := falsesandboxID := sandbox.Idfor _, container := range containers {if container.PodSandboxId == sandboxID {hasContainers = truebreak}}if hasContainers {sandboxInfo.active = true}sandboxesByPod[podUID] = append(sandboxesByPod[podUID], sandboxInfo)}// Sort the sandboxes by age.for uid := range sandboxesByPod {sort.Sort(sandboxByCreated(sandboxesByPod[uid]))}for podUID, sandboxes := range sandboxesByPod {if cgc.isPodDeleted(podUID) || evictNonDeletedPods {// 如果这个pod是要被驱逐出这台机器的话,所以的Sandbox直接全部回收cgc.removeOldestNSandboxes(sandboxes, len(sandboxes))} else {// 如果不是则保留最新的一个cgc.removeOldestNSandboxes(sandboxes, len(sandboxes)-1)}}return nil
}

与上面业务容器不同的是,Sandbox的删除需要满足三个条件,缺一不可,第一是必须不能是ready状态的,第二Sandbox不能关联容器,第三如果pod不在这个节点上可以全部删除,如果仍然在这个节点上,则还需要保留最新的一个。

这篇关于kubelet gc源码分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/977152

相关文章

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式:MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录

最长公共子序列问题的深度分析与Java实现方式

《最长公共子序列问题的深度分析与Java实现方式》本文详细介绍了最长公共子序列(LCS)问题,包括其概念、暴力解法、动态规划解法,并提供了Java代码实现,暴力解法虽然简单,但在大数据处理中效率较低,... 目录最长公共子序列问题概述问题理解与示例分析暴力解法思路与示例代码动态规划解法DP 表的构建与意义动

C#使用DeepSeek API实现自然语言处理,文本分类和情感分析

《C#使用DeepSeekAPI实现自然语言处理,文本分类和情感分析》在C#中使用DeepSeekAPI可以实现多种功能,例如自然语言处理、文本分类、情感分析等,本文主要为大家介绍了具体实现步骤,... 目录准备工作文本生成文本分类问答系统代码生成翻译功能文本摘要文本校对图像描述生成总结在C#中使用Deep

Go中sync.Once源码的深度讲解

《Go中sync.Once源码的深度讲解》sync.Once是Go语言标准库中的一个同步原语,用于确保某个操作只执行一次,本文将从源码出发为大家详细介绍一下sync.Once的具体使用,x希望对大家有... 目录概念简单示例源码解读总结概念sync.Once是Go语言标准库中的一个同步原语,用于确保某个操

Redis主从/哨兵机制原理分析

《Redis主从/哨兵机制原理分析》本文介绍了Redis的主从复制和哨兵机制,主从复制实现了数据的热备份和负载均衡,而哨兵机制可以监控Redis集群,实现自动故障转移,哨兵机制通过监控、下线、选举和故... 目录一、主从复制1.1 什么是主从复制1.2 主从复制的作用1.3 主从复制原理1.3.1 全量复制

Redis主从复制的原理分析

《Redis主从复制的原理分析》Redis主从复制通过将数据镜像到多个从节点,实现高可用性和扩展性,主从复制包括初次全量同步和增量同步两个阶段,为优化复制性能,可以采用AOF持久化、调整复制超时时间、... 目录Redis主从复制的原理主从复制概述配置主从复制数据同步过程复制一致性与延迟故障转移机制监控与维

Redis连接失败:客户端IP不在白名单中的问题分析与解决方案

《Redis连接失败:客户端IP不在白名单中的问题分析与解决方案》在现代分布式系统中,Redis作为一种高性能的内存数据库,被广泛应用于缓存、消息队列、会话存储等场景,然而,在实际使用过程中,我们可能... 目录一、问题背景二、错误分析1. 错误信息解读2. 根本原因三、解决方案1. 将客户端IP添加到Re

Java汇编源码如何查看环境搭建

《Java汇编源码如何查看环境搭建》:本文主要介绍如何在IntelliJIDEA开发环境中搭建字节码和汇编环境,以便更好地进行代码调优和JVM学习,首先,介绍了如何配置IntelliJIDEA以方... 目录一、简介二、在IDEA开发环境中搭建汇编环境2.1 在IDEA中搭建字节码查看环境2.1.1 搭建步

Redis主从复制实现原理分析

《Redis主从复制实现原理分析》Redis主从复制通过Sync和CommandPropagate阶段实现数据同步,2.8版本后引入Psync指令,根据复制偏移量进行全量或部分同步,优化了数据传输效率... 目录Redis主DodMIK从复制实现原理实现原理Psync: 2.8版本后总结Redis主从复制实

锐捷和腾达哪个好? 两个品牌路由器对比分析

《锐捷和腾达哪个好?两个品牌路由器对比分析》在选择路由器时,Tenda和锐捷都是备受关注的品牌,各自有独特的产品特点和市场定位,选择哪个品牌的路由器更合适,实际上取决于你的具体需求和使用场景,我们从... 在选购路由器时,锐捷和腾达都是市场上备受关注的品牌,但它们的定位和特点却有所不同。锐捷更偏向企业级和专