如何卸载日志堆栈

移除 ACP 4.4 日志堆栈分为三个步骤:删除 PlatformLogForward 自定义资源,卸载 Log Storage operator,然后清理按设计由用户拥有的部分(外部 Kafka、外部 ClickHouse 或 OpenSearch,以及存储集群写入的持久卷)。

operator 经过设计,确保第 1 步可随时安全执行且不会留下孤立资源,但第 2 步和第 3 步存在下文所述的手动边界。operator 写入的所有内容都位于存储集群上的 cpaas-system 下;除了一个 webhook Secret 外,不存在需要清理的集群范围状态。

operator 不会删除存储后端上的数据

无论 operator 向外部 Kafka topic、外部 ClickHouse 数据库还是外部 OpenSearch 租户写入了什么内容,卸载后这些内容都会保留。这些资源由用户拥有。如果卸载目标包括回收这些存储空间,则必须执行下方最后一节中的删除命令。

1. 删除 PlatformLogForward/platform-default

这条命令会驱动 operator 的 handlePLFTerminating handler,清理 operator 自身创建的所有关联资源:

kubectl delete platformlogforward platform-default

handlePLFTerminating 按以下顺序删除资源:

  1. 尽力清理 operator 曾创建的 KafkaTopic CR。在设置了 spec.externalMessageQueue.type 的安装中(默认设置),此步骤为空操作——topic 由用户拥有。
  2. 尽力清理 KafkaUser/platform-logging。当 mq-conn Secret 由用户创建时跳过。
  3. Deployment/razor、Deployment/aggregate-vector、同级的 Service 资源、ServiceAccount/razor,以及其 Role / RoleBinding。
  4. ConfigMap/aggregate-vector-config 和 ConfigMap/aiops-logging-migrations。
  5. Job/schema-migrations 和 Job/opensearch-init。
  6. 本地集群上的 Feature/log-center。

上方列表中的每个关联资源都带有一个指向 PlatformLogForward 的 ownerReference,因此即使 operator 在删除过程中崩溃,K8s 也会对其执行垃圾回收。handlePLFTerminating 完成后,会移除 logging.platform.alauda.io/plf-finalizer finalizer,PLF 随即消失。在正常负载下,此过程会在 60 秒内完成。

验证:

kubectl get platformlogforward platform-default
# should return NotFound

2. 卸载 Log Storage operator

PLF 消失后,即可卸载 operator 本身。如果通过 OLM 安装,请删除 Subscription 和 ClusterServiceVersion:

kubectl -n cpaas-system delete subscription log-storage-operator
kubectl -n cpaas-system delete csv $(kubectl -n cpaas-system get csv -o name | grep log-storage-operator)

如果通过 chart 安装,helm uninstall log-storage-operator -n cpaas-system 是等效操作。

卸载 operator 不会删除:

  • Secret/log-storage-operator-webhook-server-cert(有意保留,以便 cert-manager 在重新安装时可以将其交还)。
  • ClickHouse 安装中的 Secret/platform-default-ch-conn,或 OpenSearch 安装中的 Secret/platform-default-os-conn(予以保留,因为你可能会重新安装,并希望保留 endpoint 凭据)。
  • Secret/platform-default-mq-conn(出于同样的原因予以保留)。
  • 任何携带 helm.sh/resource-policy: keep 和 persistentVolumeReclaimPolicy: Retain 的旧版 chart 所有 PersistentVolume。请参见第 3 节。

如果你的卸载目标是完全回收命名空间,请按名称删除这些资源(根据所安装的后端进行调整):

kubectl -n cpaas-system delete secret \
  log-storage-operator-webhook-server-cert \
  platform-default-ch-conn \
  platform-default-mq-conn

3. 回收持久卷(可选)

PersistentVolume 和 PersistentVolumeClaim 从不会由 operator 自动删除。在全新安装的 4.4 中,底层存储位于外部 ClickHouse 或 OpenSearch 集群上,因此 ACP 上没有可回收的内容。对于从基于 ACP 4.3 chart 的部署开始、随后升级到 4.4 的安装,旧版 chi-cpaas-clickhouse-*、data-cpaas-kafka-* 和 razor-data-* PVC 仍然存在,并带有 helm.sh/resource-policy: keep。

如果要回收这些资源:

kubectl -n cpaas-system get pvc -l 'app.kubernetes.io/instance in (chart-alauda-log-clickhouse,chart-alauda-log-agent,chart-alauda-log-center)'
# review the list, then delete
kubectl -n cpaas-system delete pvc <name-1> <name-2> ...

如果这些 PVC 由带有 persistentVolumeReclaimPolicy: Retain 的 PV 提供支持(这是 Bug 58 v7 之后 operator 的默认设置),则 PVC 删除后,底层数据仍然保留在物理卷上。确认确实不再需要这些数据后,使用 kubectl delete pv 回收这些资源。

4. 清理用户所有的存储侧

外部 Kafka、外部 ClickHouse 和外部 OpenSearch 均由 SRE 团队而非 operator 所有。在删除其数据库和 topic 后,operator 执行的任何操作都不会残留在这些系统上,并且 operator 没有可用于自动执行此操作的集群凭据。

外部 Kafka

# Delete the log topics
kubectl -n cpaas-system exec sts/cpaas-kafka -- bin/kafka-topics.sh \
  --bootstrap-server localhost:9092 --delete --topic 'ALAUDA_LOG_DATA'
kubectl -n cpaas-system exec sts/cpaas-kafka -- bin/kafka-topics.sh \
  --bootstrap-server localhost:9092 --delete --topic 'ALAUDA_EVENT'
kubectl -n cpaas-system exec sts/cpaas-kafka -- bin/kafka-topics.sh \
  --bootstrap-server localhost:9092 --delete --topic 'ALAUDA_AUDIT'
# Delete the SASL user (Alauda Kafka Operator variant)
kubectl -n cpaas-system delete rdskafkauser platform-logging

如果你的 Kafka 集群是独立的 Alauda Kafka Operator 安装,并且专门为日志堆栈启动,那么卸载该 operator 及其 RdsKafka CR 会一次性关闭整个 Kafka 侧。

外部 ClickHouse

使用管理员帐户(而不是 platform-default-ch-conn Secret 中的 DML 用户)连接到 ClickHouse 集群,然后删除数据库:

clickhouse-client --host <endpoint> --user admin --password <pw> \
  --query "DROP DATABASE IF EXISTS alauda_log ON CLUSTER '{cluster}'"
clickhouse-client --host <endpoint> --user admin --password <pw> \
  --query "DROP DATABASE IF EXISTS alauda_event ON CLUSTER '{cluster}'"
clickhouse-client --host <endpoint> --user admin --password <pw> \
  --query "DROP DATABASE IF EXISTS alauda_audit ON CLUSTER '{cluster}'"

如果在 PLF 上设置了 spec.storage.databaseNameOverride,请替换为你设置的值。system.schema_migrations 表位于日志数据库中,会随数据库一同删除。

如果 ClickHouse 集群专用于日志记录,也可以直接停用该集群。

外部 OpenSearch

# Delete the indices
curl -sk -u admin:admin -XDELETE 'https://<endpoint>/log-*'
curl -sk -u admin:admin -XDELETE 'https://<endpoint>/event-*'
curl -sk -u admin:admin -XDELETE 'https://<endpoint>/audit-*'
# Delete the ISM policies (seven policies embedded by the operator)
for p in log-hot-warm-delete log-hot-delete event-hot-warm-delete event-hot-delete audit-hot-warm-delete audit-hot-delete rollover; do
  curl -sk -u admin:admin -XDELETE "https://<endpoint>/_plugins/_ism/policies/${p}"
done
# Delete the composable and component templates
curl -sk -u admin:admin 'https://<endpoint>/_index_template' \
  | jq -r '.index_templates[].name' \
  | grep -E '^(log|event|audit|cpaas-native-)' \
  | xargs -I{} curl -sk -u admin:admin -XDELETE "https://<endpoint>/_index_template/{}"

5. 在采集集群上卸载 Log Collector 插件

如果你要停用的存储集群是平台中的最后一个存储集群,请随后从每个采集集群中移除 Log Collector 插件。对每个集群执行:

# In the workload cluster
kubectl -n cpaas-system delete subscription log-collector
kubectl -n cpaas-system delete csv $(kubectl -n cpaas-system get csv -o name | grep log-collector)

Log Collector 插件不会持久化超出其自身命名空间资源生命周期的状态,因此这是一次干净的移除。

6. 最终检查清单

完成卸载前,请确认:

  • kubectl -n cpaas-system get platformlogforward 返回 No resources found。
  • kubectl -n cpaas-system get pods -l 'app in (aggregate-vector,razor,log-storage-operator)' 返回 No resources found。
  • 在存储集群上,kubectl get feature log-center 返回 NotFound(该 CR 由 operator 在存储集群上创建,并由 finalizer 清理)。
  • 上述三个外部系统均已删除,或已明确保留以供历史留存。

如果其中任何一项失败,请使用 False 条件检查故障排除:PlatformLogForward 一直处于 Provisioning 状态表——finalizer 流程在退出时使用的名称与进入时相同。