Knative 卸载实战指南：YAML 与 Operator 两种安装方式的完整清理流程-平芜编程栈

文档
教程
云原生

【免费下载链接】docs

User documentation for Knative components.

项目地址：https://gitcode.com/gh_mirrors/docs1/docs

导读

本文面向 Kubernetes 管理员，系统讲解如何安全、完整地卸载 Knative 集群组件。Knative 提供了 YAML 清单与 Knative Operator 两种安装方式，卸载流程也因此分为两条主线：YAML 方式需要按"先插件扩展、后核心组件、最后 CRD"的顺序逐层删除清单；Operator 方式则通过删除自定义资源（CR）触发控制器的清理逻辑。读完本文，你将掌握两种安装方式下 Serving、Eventing 及其网络层、消息层、事件源扩展的完整卸载命令、执行顺序与验证方法，并理解 Operator 卸载机制中"CRD 保留"这一关键安全设计。

卸载前准备：确认安装方式与当前版本

卸载前必须先确认 Knative 是以哪种方式安装的，因为后续命令完全不同：

YAML 方式：通过kubectl apply -f直接应用清单（GitOps 场景常用），卸载时使用kubectl delete -f逆序删除对应清单；
Operator 方式：通过KnativeServing/KnativeEventing自定义资源管理，卸载时删除 CR 即可，由 Operator 控制器完成清理。

可通过检查 Knative 版本中的命令确认当前组件版本。例如 YAML 方式安装时，查询命名空间上的版本标签：

# Knative Serving kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "app.kubernetes.io/version"}}' # Knative Eventing kubectl get namespace knative-eventing -o 'go-template={{index .metadata.labels "app.kubernetes.io/version"}}'

Operator 方式安装时，则直接查看 CR 的状态：

kubectl get KnativeServing knative-serving -n knative-serving kubectl get KnativeEventing knative-eventing -n knative-eventing

版本信息不仅能帮助你确认安装方式，也能在卸载前判断是否需要参考对应版本的升级与迁移说明处理存量自定义资源。

卸载 YAML 方式安装的 Knative

YAML 方式的卸载与安装互为逆过程。核心原则是：先卸载可选扩展（网络层、事件源、Broker、Channel），再卸载核心组件，最后删除 CRD。如果先删除了 CRD，依赖这些 CRD 的控制器可能报错或产生孤儿资源。

第一步：卸载可选的 Serving 扩展

如果安装过 HPA 类自动扩缩容扩展（对应安装文档中的serving-hpa.yaml），先将其卸载：

kubectl delete -f serving-hpa.yaml

该清单提供的是通过 Kubernetes Horizontal Pod Autoscaler（HPA）驱动自动扩缩容决策所需的组件。若你同时使用了 Knative 默认的 KPA 自动扩缩容，二者互不影响，此处只需删除 HPA 扩展。

第二步：卸载网络层（Networking Layer）

Knative Serving 依赖一个网络层（Ingress）对外提供流量入口。请根据实际安装的网络层选择对应命令：

Contour

# 1. 卸载 Knative Contour 控制器 kubectl delete -f net-contour.yaml # 2. 卸载 Contour 本身 kubectl delete -f contour.yaml

Istio

# 1. 卸载 Knative Istio 控制器 kubectl delete -f net-istio.yaml # 2. 可选：如果不再需要 Istio，继续卸载它 kubectl delete -f istio.yaml

注意：net-istio.yaml属于 Knative 的 Istio 集成清单，istio.yaml才是 Istio 服务网格本体。如果集群中其他工作负载仍在依赖 Istio，第二步应跳过。卸载 Istio 的更多细节可参考安装 Istio 文档中对应的回滚说明。

Kourier

kubectl delete -f kourier.yaml

网络层文件分别对应 Knative 扩展仓库中的net-contour、net-istio、net-kourier组件清单。卸载完成后，Serving 将失去对外提供 HTTP 流量的能力，因此在卸载核心组件之前完成此步是必要的。

第三步：卸载 Serving 核心组件

按以下顺序执行：

# 1. 卸载 Serving 核心组件 kubectl delete -f serving-core.yaml # 2. 卸载必需的 CRD kubectl delete -f serving-crds.yaml

其中serving-core.yaml包含 Serving 的核心控制器（controller、webhook、activator、autoscaler 等），serving-crds.yaml包含 Service、Route、Revision、Configuration 等核心 CRD。仓库中的 Knative Serving 安装文件说明对这些清单的依赖关系给出了明确参考：serving-core.yaml依赖serving-crds.yaml，卸载时顺序正好相反。该参考表还列出了serving-default-domain.yaml（默认 DNS 后缀 sslip.io）、serving-hpa.yaml（HPA 扩展）、serving-post-install-jobs.yaml等可选清单，如已安装需一并清理。

第四步：卸载可选的 Eventing 扩展

按实际安装的事件源扩展逐项卸载：

Apache Kafka Sink

# 1. 卸载 Kafka Sink 数据平面 kubectl delete -f eventing-kafka-sink.yaml # 2. 卸载 Kafka 控制器 kubectl delete -f eventing-kafka-controller.yaml

GitHub Source

# 单租户 GitHub Source kubectl delete -f github.yaml # 多租户 GitHub Source kubectl delete -f mt-github.yaml

单租户实现会为每个 GitHub Source 创建一个 Knative Service；多租户实现只创建一个处理集群内所有 GitHub Source 的 Service（不支持日志与追踪配置）。卸载时务必与你安装时的清单一一对应。

Apache Kafka Source

kubectl delete -f eventing-kafka-source.yaml

GCP Sources

kubectl delete -f cloud-run-events.yaml

Apache CouchDB Source

kubectl delete -f couchdb.yaml

VMware Sources and Bindings

kubectl delete -f release.yaml

这些扩展分别对应eventing-kafka-broker、eventing-github、knative-gcp、eventing-couchdb、sources-for-knative等扩展仓库的发布清单，与 Eventing 安装文档中"Install optional Eventing extensions"一节的应用清单一一对应。

第五步：卸载可选的 Broker 层

Apache Kafka Broker

# 1. 卸载 Kafka Broker 数据平面 kubectl delete -f eventing-kafka-broker.yaml # 2. 卸载 Kafka 控制器 kubectl delete -f eventing-kafka-controller.yaml

MT-Channel-based Broker

kubectl delete -f mt-channel-broker.yaml

MT-Channel 基于 Channel 实现，会在系统命名空间运行事件路由组件，是一种更轻量的 Broker 实现。

第六步：卸载可选的 Channel（消息）层

Apache Kafka Channel

kubectl delete -f eventing-kafka-channel.yaml

Google Cloud Pub/Sub Channel

kubectl delete -f cloud-run-events.yaml

In-Memory（standalone）Channel

kubectl delete -f in-memory-channel.yaml

NATS Channel

# 1. 卸载 NATS Streaming Channel kubectl delete -f eventing-natss.yaml # 2. 卸载 NATS Streaming for Kubernetes

注意：in-memory-channel.yaml是 Knative Eventing 自带的轻量内存 Channel 实现，官方文档明确提示该实现仅适用于非生产场景。仓库中的 Knative Eventing 安装文件说明对eventing-core.yaml、eventing-crds.yaml、eventing.yaml（核心 + MT-Channel Broker + In-Memory Channel 的组合清单）、in-memory-channel.yaml、mt-channel-broker.yaml的依赖关系给出了完整参考表，可作为卸载清单的核对依据。

第七步：卸载 Eventing 核心组件

# 1. 卸载 Eventing 核心组件 kubectl delete -f eventing-core.yaml # 2. 卸载必需的 CRD kubectl delete -f eventing-crds.yaml

与 Serving 相同，eventing-core.yaml依赖eventing-crds.yaml，卸载时先删核心组件、后删 CRD。

卸载 Operator 方式安装的 Knative

Operator 方式的卸载要简单得多：核心思路是删除自定义资源，由 Operator 控制器负责清理底层部署。Knative Operator 本身就是一个扩展 Kubernetes API 的自定义控制器，安装与卸载细节可参考使用 Knative Operator 安装。

删除 Knative Serving 组件

删除KnativeServingCR：

kubectl delete KnativeServing knative-serving -n knative-serving

删除 Knative Eventing 组件

删除KnativeEventingCR：

kubectl delete KnativeEventing knative-eventing -n knative-eventing

理解 Operator 的安全卸载机制

Knative Operator 会阻止对 Knative 资源的不安全移除。即便KnativeServing和KnativeEventingCR 都被成功删除，集群中 Knative 的所有 CRD 仍然会保留，所有依赖这些 CRD 的既有资源（如 Service、Trigger、Broker 等）依然可以正常工作。这是卸载流程中非常关键的设计：CRD 是长期保留的 API 契约，删除 CR 只代表停止由 Operator 管理的组件部署，并不会破坏用户业务自定义资源的数据结构。

删除 Knative Operator 本体

只有确认不再需要 Operator 管理任何 Knative 组件后，才执行本步骤。

方式一：通过 Release 页面安装的 Operator

kubectl delete -f operator.yaml

方式二：从源码安装的 Operator

在源码根目录下执行：

ko delete -f config/

远程集群（Multi-cluster）场景的卸载

从 Knative Operator v1.22 起，可以通过spec.clusterProfileRef将组件部署到远程 spoke 集群。对于这种场景，多集群部署文档明确强调：必须在 hub 集群上删除 CR，让 finalizer 负责清理 spoke 上的资源，切勿直接删除 spoke 上的辅助资源，否则会级联删除所有命名空间级 Knative 资源：

kubectl delete knativeserving knative-serving -n knative-serving

finalizer 会等待 spoke 可达后，移除所有由 Operator 管理的资源。如果 spoke 永久不可达，finalizer 无法完成，CR 会一直停留在 terminating 状态。此时如需强制删除，可移除 finalizer（代价是 spoke 上会遗留孤儿资源）：

kubectl patch knativeserving <name> -n <namespace> \ --type=merge -p '{"metadata":{"finalizers":null}}'

卸载后的验证与注意事项

卸载完成后，可通过以下方式确认清理状态：

# 确认 Serving 命名空间下的 Pod 已清空 kubectl get pods -n knative-serving # 确认 Eventing 命名空间下的 Pod 已清空 kubectl get pods -n knative-eventing # 确认 Operator 已删除 kubectl get deployment knative-operator

最后再强调几点实操注意事项：

顺序不能乱：YAML 方式务必遵循"扩展 → 网络层/Broker/Channel → 核心组件 → CRD"的顺序，避免 CRD 提前删除导致控制器异常；
清单版本要匹配：卸载清单应与安装时使用的组件版本一致，混用不同版本清单可能导致部分资源残留；
插件与组件同步：网络层（如 Istio、Contour、Kourier）可能被集群内其他业务共享，卸载前需确认无其他依赖；
Operator 的 CRD 保留策略：如果只是暂时停用 Knative 组件而非彻底移除 API，Operator 方式（保留 CRD）比 YAML 方式（删除 CRD）更适合你——这与安装方式对比中描述的两种方式定位一致：YAML 方式粒度可控、所见即所得；Operator 方式高层抽象、易于管理与定制分离。