文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载导读Knative Serving 中每一次对 Service 配置的变更都会生成一个不可变的 Revision 快照而长期堆积的旧 Revision 会被系统自动垃圾回收Garbage Collection以回收集群资源。本文基于 Knative 官方文档的开发者配置参考聚焦开发者如何按需修改 Revision 行为重点讲解 Revision 的基本模型、垃圾回收的默认策略以及如何通过serving.knative.dev/no-gc: true注解让某个 Revision 永不被回收并横向对比集群管理员使用的config-gcConfigMap 全局策略。读完本文你将能够自主决定哪些 Revision 必须保留、哪些可以交给系统自动清理并理解底层 GC 控制器的工作方式。Revision 是什么不可变的点状快照在 Knative Serving 中Revision 是承载应用代码与配置点状快照point-in-time snapshot的核心资源。每次修改 Knative Service 的Configuration配置例如更换镜像、调整资源配额或环境变量控制器都会生成一个新的 RevisionKubernetes 底层 Pod 的数量则根据 Revision 承接的流量进行扩缩容。需要特别注意的是Revision 无法被手动创建也不允许直接修改其 spec——它总是由Configuration的更新而派生Revision 总体上是不可变的immutable唯一的例外是它可以引用可变的 Kubernetes 核心资源如 ConfigMap、Secret以及可能被默认值变更所改写这类变更通常是语法层面而非语义层面的开发者能够做的是直接修改已存在 Revision 的 spec 来改变其行为这正是本篇文章Developer configuration options的主题。围绕 Revision 还有两个高频使用场景可帮助理解其定位流量管理通过 Service 的trafficspec可以把流量按百分比切分给多个固定 Revision或通过latestRevision: true将流量导向最新 Revision实现渐进式发布与蓝绿发布详见 Traffic management自动扩缩容Revision 会依据流量自动扩缩支持缩容到零详见 Autoscaling 相关文档。垃圾回收不活跃 Revision 的自动清理默认行为当 Knative Service 的某些 Revision 不再活跃inactive时系统会在设定的时间过后自动将其清理并回收对应的集群资源。这一过程在 Knative 文档中被明确定义为garbage collection详见片段 about-revisions-garbage-collection.md其语义与 Kubernetes 的垃圾回收 一脉相承。垃圾回收的配置权限分两层角色配置范围配置手段开发者Developer仅针对某个具体 Revision在 Revision 的 metadata 上添加注解集群管理员Administrator集群内所有 Service 的所有 Revision全局默认值修改config-gcConfigMap也就是说管理员设定的config-gc是集群级默认策略而开发者可以在单个 Revision 上做例外处理。全局策略中的保留规则管理员在 Revision 管理员配置选项 中可以通过修改knative-serving命名空间下的config-gcConfigMap来控制集群内所有 Revisions 的回收行为可配置项如下配置键含义retain-since-create-timeRevision 被创建后必须经过多长时间才会进入垃圾回收的候选名单retain-since-last-active-timeRevision 最后一次活跃后必须经过多长时间才会进入垃圾回收的候选名单min-non-active-revisions至少要保留的不活跃 Revision 数量max-non-active-revisions最多保留的不活跃 Revision 数量无论上述参数如何设置只要 Revision 属于以下任意一种情况就始终会被保留该 Revision 是活跃的并且正被某条 Route 引用该 Revision 的创建时间在retain-since-create-time指定的时间窗口内该 Revision 在retain-since-last-active-time指定的时间窗口内最后一次被 Route 引用当前存在的 Revision 数量少于min-non-active-revisions指定的数量。管理员常用配置示例来自 revision-admin-config-options.md立即清理所有不活跃 RevisionapiVersion: v1 kind: ConfigMap metadata: name: config-gc namespace: knative-serving data: min-non-active-revisions: 0 max-non-active-revisions: 0 retain-since-create-time: disabled retain-since-last-active-time: disabled ...保留最近 10 个不活跃 RevisionapiVersion: v1 kind: ConfigMap metadata: name: config-gc namespace: knative-serving data: retain-since-create-time: disabled retain-since-last-active-time: disabled max-non-active-revisions: 10 ...在集群上完全禁用垃圾回收apiVersion: v1 kind: ConfigMap metadata: name: config-gc namespace: knative-serving data: retain-since-create-time: disabled retain-since-last-active-time: disabled max-non-active-revisions: disabled ...关于 ConfigMap 的编辑方式与最佳实践可参考 Working with ConfigMaps这些 Serving 配置在 管理员总览 中也有系统化归纳。为单个 Revision 禁用垃圾回收no-gc 注解这是本文关联文档 revision-developer-config-options.md 给出的核心开发者级操作为某个 Revision 添加注解serving.knative.dev/no-gc: true即可让它永不被垃圾回收。apiVersion: serving.knative.dev/v1 kind: Revision metadata: annotations: serving.knative.dev/no-gc: true ...使用要点注解的键serving.knative.dev/no-gc注解的值字符串true注意 YAML 中需要加引号因为它是字符串值作用范围仅作用于被标注的单个 Revision不影响其他 Revision也不受集群级config-gc策略影响典型使用场景需要长期保留某个特定版本用于审计、回滚基准、灰度对照或合规留存时避免它被系统当作不活跃 Revision清理掉。通过 Service 模板间接标注虽然注解加在 Revision 上但在实际业务中Revision 往往由 Service 自动派生。你可以在部署 Service 时把该注解写入 Service 的template.metadata.annotations这样每次生成的 Revision 都会携带serving.knative.dev/no-gc: trueapiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-service namespace: default spec: template: metadata: annotations: serving.knative.dev/no-gc: true spec: containers: - image: ghcr.io/knative/helloworld-go:latest ...说明Service 中任何对 spec、metadata 标签或注解的变更都会同步复制到其拥有的 Route 与 Configuration详见 Knative Services并进一步触发新 Revision 的生成因此通过模板注入注解是最符合声明式工作流的方式。查看与验证你可以使用kubectl查看 Revision 的完整定义确认注解是否生效kubectl get revision revision-name --output yaml输出中的metadata.annotations应包含serving.knative.dev/no-gc: true。关于 Revision 状态的进一步排查如检查 Revision 是否 Ready可参考 调试应用问题。底层视角GC 控制器的实现演进从仓库中的版本发布记录可以还原 Knative Serving 垃圾回收能力的演进脉络这有助于理解config-gc参数与no-gc注解背后的实现逻辑v0.17实现了新的垃圾回收器支持基于时间或基于 min/max 数量边界两种自动删除旧 Revision 的策略见 v0.17 发布说明同时引入 ResponsiveGC 特性开关开启后停止刷新 Revision 上的lastPinned注解时间戳v0.18Responsive 式 Revision 垃圾回收默认开启见 v0.18 发布说明v0.19ResponsiveRevisionGC默认启用见 v0.19 发布说明v0.20 / v0.21移除了 GC 特性开关及 v1 GC/Labeler 相关代码见 v0.20 发布说明 与 v0.21 发布说明GC 机制走向成熟与稳定。从上述演进可以推断当前 GC 控制器同时依据创建时间 / 最近活跃时间以及不活跃数量上下限两类判定维度工作这与管理员在config-gc中看到的retain-since-create-time、retain-since-last-active-time、min-non-active-revisions、max-non-active-revisions四个参数一一对应而no-gc注解则是在此判定之上提供白名单式的强制保留能力。小结开发者与管理员如何协同管理 Revision 生命周期综合来看Knative Serving 对 Revision 生命周期的管理遵循全局默认 局部例外的分层设计默认层集群管理员通过knative-serving命名空间下的config-gcConfigMap 设定全局回收参数控制所有 Service 的 Revision 保留时长与数量例外层开发者对需要长期保留的 Revision 添加serving.knative.dev/no-gc: true注解使其永久豁免于垃圾回收判定原则无论全局参数如何被 Route 引用的活跃 Revision、处于保留时间窗口内的 Revision、以及数量低于min-non-active-revisions阈值时的 Revision都始终被保留。实践中建议仅在确有回滚、审计或对照需求时才使用no-gc注解避免无节制保留导致集群资源泄漏同时对全局config-gc的调整应谨慎评估对集群资源水位的影响。相关资源Revision 开发者配置选项本主题原文Revision 管理员配置选项全局 GC 策略Revision 概述Revision 垃圾回收片段说明Knative Service 概述流量管理Revision 之间的流量切分默认配置 ConfigMapconfig-defaults赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative Serving Revision 垃圾回收机制解析config-gc 配置与 no-gc 注解实战指南Knative Serving Revision 垃圾回收机制解析config gc 配置与 no gc 注解实战指南 本文以 Knative Serving文档教程云原生Knative Serving Revision 深入解析不可变快照、流量切分与垃圾回收机制Knative Serving Revision 深入解析不可变快照、流量切分与垃圾回收机制 Revision修订版本是 Knative Serving文档教程云原生Julia垃圾回收终极指南分代GC与内存管理机制详解Julia垃圾回收终极指南分代GC与内存管理机制详解 Julia作为一款高性能动态编程语言其垃圾回收GC机制是实现卓越性能的关键所在。Julia的GC采编程语言编译器语言运行时JIT编译标准库解释器上一篇3分钟让Figma说中文设计师必备的界面汉化神器下一篇如何在3分钟内将Figma界面完全汉化设计师必备的中文翻译插件终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考