文章转载自:https://www.kuboard.cn/learning/k8s-advanced/gc.html

Kubelet的垃圾回收功能可以清理不再使用的容器和镜像,kubelet对容器进行垃圾回收的频率是每分钟一次,对镜像进行垃圾回收的频率是每五分钟一次。

不推荐使用外部的垃圾回收工具,因为这些工具有可能会删除 kubelet 仍然需要的容器或者镜像。

镜像回收

Kubernetes 通过 imageManager 配合 cadvisor 管理所有镜像的生命周期。

镜像的垃圾回收策略主要考虑两方面因素: HighThresholdPercent 和 LowThresholdPercent。

  • 磁盘利用率超过 high threshold 将触发垃圾回收动作
  • 垃圾回收功能将删除最近最少使用的镜像,直到磁盘利用率低于 low threshold

容器回收

容器的垃圾回收侧率主要考虑三个用户自定义的变量:

  • MinAge: 容器创建到现在的最小时长,低于此时长的不能被垃圾回收;如果设置为 0,则禁用该选项
  • MaxPerPodContainer:以 Pod UID + 容器名 作为组合键,MaxPerPodContainer 指定了同一个 Pod UID + 容器名 组合键下可以包含的已停止容器的最大数量。如果设置为小于 0 的数值,则禁用该选项
  • MaxContainers: 指定了最大的已停止容器的数量。如果设置为小于 0 的数值,则禁用该选项

Kubelet 将对满足上述三个条件,且已经停止的容器执行垃圾回收的动作。通常,创建时间最长的容器将被最早移除。 MaxPerPodContainer 和 MaxContainer 这两个参数可能会相互冲突,例如, 如果要为每个 Pod 保存 MaxPerPodContainer 个已停止容器的话,可能最终总的已停止的容器的数量要超过 MaxContainers 的定义。 此时,优先保证 MaxContainers 的限定, MaxPerPodContainer 将被重新调整:最坏的情况下,kubelet 将 MaxPerPodContainer 的要求降低到 1,并删除创建时间最久的已停止的容器。此外,当 Pod 的已停止容器创建时长超过 MinAge 时,该容器将被即刻删除。

对于那些不是通过 kubelet 创建的容器,kubelet 不能对其进行垃圾回收操作。

配置

通过以下 kubelet 启动参数,可以调整镜像垃圾回收的变量:

  • image-gc-high-threshold,磁盘利用率高于此参数时,将触发镜像的垃圾回收。默认值为 85%
  • iamge-gc-low-threshold,磁盘利用率低于此参数时,镜像的垃圾回收将停止。默认值为 80%

通过以下 kubelet 启动参数,可以调整容器的垃圾回收的变量:

  • minimum-container-ttl-duration,容器创建到现在的最小时长,低于此时长的不能被垃圾回收。默认值为 0 分钟,即,每一个已停止的容器都可以被垃圾回收
  • maximum-dead-containers-per-container,对于每个容器的旧实例,最多可以保留的个数。默认值为 1
  • maximum-dead-containers,全局最大可以保留的已停止的容器数量。默认值为 -1,即,不做全局性限制

容器在被垃圾回收时,也许仍然是有用的。例如,这些容器可能包含了对于问题诊断(trouble shooting)来说非常有用的日志和数据。强烈建议将 maximum-dead-containers-per-container 设置为足够大的数值,至少不能小于1,以便为每一个容器至少保留一个已停止的容器。同样的,也建议为 maximum-dead-containers 设置一个比较大的数值。 参考 issue #13287

Deprecation

此文档的某些特性已经不推荐使用,未来将被 kubelet eviction 替代。

包括:

Existing Flag New Flag Rationale
--image-gc-high-threshold --eviction-hard or --eviction-soft 已有的 eviction 信号可以触发镜像的垃圾回收
--image-gc-low-threshold --eviction-minimum-reclaim eviction reclaims 可实现相同的效果
--maximum-dead-containers 如果日志被存储在容器外部,就不推荐使用此特性
--maximum-dead-containers-per-container 如果日志被存储在容器外部,就不推荐使用此特性
--minimum-container-ttl-duration 如果日志被存储在容器外部,就不推荐使用此特性
--low-diskspace-threshold-mb --eviction-hard or eviction-soft eviction 通过其他资源判断是否要垃圾回收,而不再通过磁盘利用率这个参数
--outofdisk-transition-frequency --eviction-pressure-transition-period eviction generalizes disk pressure transition to other resources

配置Kubelet的垃圾回收的更多相关文章

  1. JVM垃圾回收机制总结(3) :按代垃圾收集器

    为什么要分代 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的 . 因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率. 在Java程序运行的过程中,会产生大量的对 ...

  2. JVM调优总结(六)-分代垃圾回收详述2

    分代垃圾回收流程示意 选择合适的垃圾收集算法 串行收集器 用单线程处理所有垃圾回收工作,因为无需多线程交互,所以效率比较高.但是,也无法使用多处理器的优势,所以此收集器适合单处理器机器.当然,此收集器 ...

  3. java虚拟机学习-JVM调优总结-分代垃圾回收详述(9)

    为什么要分代 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的.因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率. 在Java程序运行的过程中,会产生大量的对象, ...

  4. JVM虚拟机学习一:垃圾回收算法总结

    1.java虚拟机中涉及到的数据类型 Java虚拟机中,数据类型可以分为两类:基本类型和引用类型. 基本类型的变量保存原始值,即:他代表的值就是数值本身:而引用类型的变量保存引用值.“引用值”代表了某 ...

  5. JVM调优总结(4):分代垃圾回收

    为什么要分代 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的.因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率. 在Java程序运行的过程中,会产生大量的对象, ...

  6. JVM垃圾回收(GC)整理总结学习

    基本回收算法 1. 引用计数(Reference Counting)比较古老的回收算法.原理是此对象有一个引用,即增加一个计数,删除一个引用则减少一个计数.垃圾回收时,只用收集计数为0的对象.此算法最 ...

  7. java虚拟机垃圾回收机制详解

    首先,看一下java虚拟机运行的时候内存分配图: jvm虚拟机栈:一个是线程独有的,每次启动一个线程,就创建一个jvm虚拟机栈,线程退出的时候就销毁.这里面主要保存线程本地变量名和局部变量值. 本地方 ...

  8. JVM垃圾回收原理

    原文地址:http://chenchendefeng.iteye.com/blog/455883 一.相关概念 基本回收算法 1. 引用计数(Reference Counting) 比较古老的回收算法 ...

  9. JVM调优总结(四)-分代垃圾回收详述

    为什么要分代 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的.因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率. 在Java程序运行的过程中,会产生大量的对象, ...

随机推荐

  1. API管理之利剑 -- Eolink

    随着信息化飞速增长的还有各信息系统中的应用接口( API ),API 作为信息系统内部及不同信息系统之间进行数据传输的渠道,其数量随着软件系统的不断庞大而呈指数型增长,如何管理这些 API 已经在业界 ...

  2. APISpace 空号检测API接口 免费好用

    空号检测也称空号在线过滤,在线筛号,号码在线清洗.空号检测平台借助第五代大数据空号检测系统,为用户提供高精准的空号检测.号码过滤.号码筛选.号码清洗等众多号码检测功能,让用户快速准确的检测出活跃号.空 ...

  3. vue发布自定义组件到npm

    一.使用 vue create currentdatetime创建项目(可查考https://cli.vuejs.org/zh/guide/creating-a-project.html),创建成功后 ...

  4. 加强版:合并果子[NOIP2004]

    题目 链接:https://ac.nowcoder.com/acm/contest/26887/1001 来源:牛客网 时间限制:C/C++ 1秒,其他语言2秒 空间限制:C/C++ 131072K, ...

  5. 【高并发】通过源码深度分析线程池中Worker线程的执行流程

    大家好,我是冰河~~ 在<高并发之--通过ThreadPoolExecutor类的源码深度解析线程池执行任务的核心流程>一文中我们深度分析了线程池执行任务的核心流程,在ThreadPool ...

  6. 基于gitlab 15.1 pages 搭建内部博客一定行版本

    背景 基于 gitlab 15.1版 pages 搭建内部博客,参考官方文档,遇到一个又一个坑.之前看到别人吐槽说 gitlab 官方文档很差,我算是理解了.下面一个个说. 开始 按照官方文档的说法, ...

  7. .netcore 定制化项目开发的思考和实现

    今年年初进了一家新公司,进入之后一边维护老项目一边了解项目流程,为了接下来的项目重做积累点经验. 先说下老项目吧,.net fx 3.5+oracle...... 在实际维护中逐渐发现,老项目有标准版 ...

  8. 学会使用MySQL的Explain执行计划,SQL性能调优从此不再困难

    上篇文章讲了MySQL架构体系,了解到MySQL Server端的优化器可以生成Explain执行计划,而执行计划可以帮助我们分析SQL语句性能瓶颈,优化SQL查询逻辑,今天就一块学习Explain执 ...

  9. 1000-ms-HashMap 线程安全安全问题

    问题: HashMap是否是线程安全 详解 http://www.importnew.com/21396.html 有源码分析 和代码性能比较 CHM性能最好 HashMap不是线程安全的:Hasht ...

  10. git使用的一些坑和新得(一)

    这是一个坑 你要知道作为一个新手对git的使用还处于摸索状态 今天就将这样的坑分享给大家 昨天,接到任务将代码发到远程仓库里.于是,我就天真的按步骤提交了! 然后就: To https: ! [rej ...