Namespace 一直 Terminating：先修复 APIService 发现失败
Namespace 删除一直 Terminating 且发现失败时，按 conditions 定位 APIService 与后端发现路径，区分旧兼容缺陷和当前服务故障，不直接清空 finalizer。
删除 Namespace 后一直停在 Terminating，状态中 NamespaceDeletionDiscoveryFailure 为 True，消息还包含 stale GroupVersion discovery 或无法取得某个 API 分组。应先处理那项 API 发现失败，不要直接清空命名空间的 finalizer。
删除控制器需要发现命名空间中的资源类型，才能完成清理。一项扩展 API 发现不完整时，即使 Pod 列表已经为空，也不能据此认定所有资源均已清除。下面针对聚合 APIService 参与发现失败的分支；若状态主要报告资源仍在或业务 finalizer 未结束，应按对应条件处理。
从 conditions 找失败的分组
先确认当前集群，再读取目标命名空间。名称是示例：
kubectl config current-context
kubectl get namespace example-ns -o yaml
kubectl get apiservice
对照 status.conditions 中的类型、状态、message 与更新时间。NamespaceContentRemaining 为 False，只说明已被控制器检查到的内容情况，不能消除另一个 DiscoveryFailure。删除过程已开始时，不能继续向这个命名空间部署新资源来测试。
错误若点名 allocation.agones.dev/v1，查相应的聚合 APIService，例如：
kubectl describe apiservice v1.allocation.agones.dev
kubectl get --raw /apis/allocation.agones.dev/v1
分组、版本与 APIService 名称需按真实错误替换。APIService 是集群级注册，描述中的 spec.service.namespace 才是后端 Service 所在命名空间，不一定等于正在删除的命名空间。经 Kubernetes API 发出原始读取请求，也能帮助确认失败出现在 API 服务端路径上。
如果实际资源是 CRD，不能硬找一个同名 APIService；两种扩展方式的提供方不同。读取请求的权限错误也应先核对诊断账户权限，避免把它当成服务器发现失败。
Available 为 True，还要检查实际发现响应
聚合层把 APIService 注册的路径代理到扩展 API 服务。Available 为 False 时，结合 condition 的原因检查后端 Service、EndpointSlice、Pod 状态、控制平面到后端的网络，以及证书信任和授权设置。
不要为减少错误直接启用 insecureSkipTLSVerify。先核对服务证书、CA 配置和实际连接路径。聚合 API 的发现请求要求较低延迟，响应过慢也需要处理，不能只证明普通业务接口偶尔能返回。
Available 为 True 也不保证所有发现协商都正常。Kubernetes 1.27 的历史兼容问题中，部分扩展服务未正确响应聚合发现请求，常规健康检查通过，命名空间删除仍被阻塞。这个问题的修复不能泛化成当前所有 stale GroupVersion 都是同一个版本缺陷。
核对 Kubernetes 的具体补丁版本、供应方修复情况及扩展服务版本。处于旧受影响组合时，按平台支持路径更新集群或扩展服务；当前版本仍失败，应继续检查真实发现路径、后端状态和返回内容。不要把某次 HTTP 406 临时兼容处理写成所有扩展服务的通用响应。
保留注册时修后端，退役时先查清依赖
扩展 API 仍被业务使用时，应恢复它的服务和发现能力。APIService 注册是集群范围的，删除它会让其他命名空间也无法通过该分组访问资源，并可能影响依赖控制器。
只有确认产品确已退役、相关资源和依赖已按产品卸载流程处理，才考虑移除残留注册。变更前保存 APIService、扩展服务部署配置和对应产品数据，确认谁负责该注册；Helm 或控制器管理的对象还可能被自动重新建立。
不能因目标 Namespace 看着已经空了，就删掉所有不可用 APIService。它们可能是其他业务暂时故障的服务。也不能绕过删除控制器直接提交空 finalizer，把未能发现的内容留成孤立资源。
恢复发现后，让删除流程自行继续
验收包括失败分组的发现请求按预期返回、相关 APIService 与扩展工作负载恢复，以及目标 Namespace 的发现失败条件更新，最终由正常清理流程完成删除。若随后条件转成 ContentRemaining 或 FinalizersRemaining，应处理新暴露的资源和控制器，不再用同一项发现修复解释全部阻塞。
已经提交的删除请求会在阻塞解除后继续，恢复服务不能把命名空间变回未删除状态；需提前确认业务资源备份和恢复安排。配置修复不符预期时，可恢复保存的服务与注册配置，但这不会恢复已经删除的数据。命名空间同名重建也不等于旧资源已经回来了。