Knative Serving Revision 开发者配置指南：垃圾回收机制与 no-gc 注解详解-平芜编程栈

文档
教程
云原生

【免费下载链接】docs

User 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配置（例如更换镜像、调整资源配额或环境变量），控制器都会生成一个新的 Revision；Kubernetes 底层 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-gc`ConfigMap

也就是说，管理员设定的config-gc是集群级默认策略，而开发者可以在单个 Revision 上做"例外处理"。

全局策略中的保留规则

管理员在 Revision 管理员配置选项中可以通过修改knative-serving命名空间下的config-gcConfigMap，来控制集群内所有 Revisions 的回收行为，可配置项如下：

配置键	含义
`retain-since-create-time`	Revision 被创建后必须经过多长时间，才会进入垃圾回收的候选名单
`retain-since-last-active-time`	Revision 最后一次活跃后必须经过多长时间，才会进入垃圾回收的候选名单
`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）：

立即清理所有不活跃 Revision：

apiVersion: 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 个不活跃 Revision：

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: "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: "true"：

apiVersion: 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.18：Responsive 式 Revision 垃圾回收默认开启（见 v0.18 发布说明）；
v0.19：ResponsiveRevisionGC默认启用（见 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的调整应谨慎评估对集群资源水位的影响。