k8s namespace一直显示terminating

当Kubernetes的namespace无法删除时,通过kubectl命令会被卡住。文章中提到两种临时解决方案,包括使用API Raw方法。作者通过查看API-server日志和kubectl的verbose选项找到问题根源,发现是Prometheus Adapter在读取configmap时失败导致。重启Prometheus Adapter Deployment后,问题得到解决。

问题描述:
在某个时候开始,k8s的namespace就一直delete不掉,kubectl delete ns xxx命令也会被卡住,久久不能解脱。不管哪个namespace都是这样。但问题总有人解决,网上百度到两个raw API的方法,屡试不爽。先将这两个方法的链接帖到下面,每一个都是OK的,都可以临时解决这个问题:
a. https://blog.youkuaiyun.com/Michaelwubo/article/details/110878183
b. https://craignewtondev.medium.com/how-to-fix-kubernetes-namespace-deleting-stuck-in-terminating-state-5ed75792647e
第一个需要开启proxy,第二个不需要,但是可能需要科学上网。

问题定位和处理:
但这两个办法都是临时解决,总不能每次都手动删除或者脚本删除吧。所以,还需要查找根因。
我的第一个想法是,我要看看api-server的日志,因为kubectl直接和api-server打交道,如果有问题,就会直接反映出来。这一看果然是有问题的,但是这个log并不是和我的命令同步的,也就是说,并不是我执行以下,这个log就出一次。所以这个不是因果关系,目前没有参考价值。
api-server报错日志
然后我想要不从kubectl这个客户端入手,看一下日志,想到了verbose。然后kubectl options发现有-v的选项,于是指定kubectl -v 1 delete ns xxx。果然出现Error日志了,也是上面这个信息。于是,就查看相关的信息。
我们的集群内都没有装metrics-server,但是其它集群就是好的。这个ip很特别,我查看了api-server的启动参数,没有这个ip。而且看样子,是个集群内的ip。习惯性的ping了一下,是通的。我就知道事情没这么简单了。于是我grep了所有namespace的ip,发现Prometheus的Adapter是这个ip。我感觉应该就是这个pod的问题。pod是running的,所以我就看了adapter的日志,果然发现了端倪。Adapter在读某个configmap的时候Failed了。
对Prometheus Adapter不熟悉,它是个Deployment,于是我直接重启这个Deployment,再看日志,没有那个Failed了。
我再尝试创建和删除namespace,已经一切OK了。

<think>好的,我现在要处理用户关于Kubernetes 1.23版本中Namespace处于Terminating状态的问题。首先,我需要回忆一下Namespace终止的机制。当用户删除一个Namespace时,Kubernetes会先将其状态标记为Terminating,然后开始清理其中的资源。这个过程需要等待所有资源都被删除后,Namespace才会被完全移除。 接下来,用户提到的Terminating状态可能住的情况。常见的几个原因应该包括:资源未被正确删除、Finalizers阻塞、API扩展问题或权限不足。比如,有些自定义资源或CRD可能没有被正确清理,或者Finalizers列表中存在未完成的操作,导致Namespace无法完成删除。 然后,我需要考虑解决方法。首先检查残留资源,使用kubectl命令列出所有资源,确认是否有残留。如果有,手动删除它们。然后,处理Finalizers,可能需要编辑Namespace的配置,移除阻塞的Finalizer。这里需要注意强制删除的方法,比如使用--force和--grace-period=0参数,但需要谨慎操作,避免影响集群稳定性。 另外,API扩展问题,比如某些APIService不可用,可能导致控制器无法完成清理。这时候需要检查APIService的状态,必要时重启相关控制器或修复API服务。权限问题也需要检查,确保有足够的权限删除资源。 在解释这些步骤时,要确保结构清晰,分点说明,让用户能够一步步排查问题。同时,提醒用户注意强制删除的风险,以及可能需要联系集群管理员处理权限或APIService的问题。需要确认所有的命令示例正确无误,比如kubectl get all -n <namespace>和kubectl edit namespace <namespace>。 最后,总结处理流程,帮助用户理清思路。确保回答符合用户的要求,使用中文,避免使用Markdown格式,行内公式用$包裹,独立公式用$$。同时,保持口语化,但不过于随意,确保专业性和易懂性。</think>在Kubernetes 1.23版本中,当删除一个Namespace时,如果它长时间停留在$Terminating$状态,通常是由于以下原因及解决方法: ### 原因分析 1. **残留资源未清理** Kubernetes会等待Namespace内所有资源(如Pod、Service、CRD等)被删除。如果有资源因$finalizer$未解除或控制器故障未被清理,Namespace会阻塞。 2. **Finalizers未完成** Namespace的`.spec.finalizers`字段可能包含自定义控制器逻辑(如$kubernetes$默认的finalizer),若控制器未响应或逻辑异常,会导致删除流程中断。 3. **APIService不可用** 如果Namespace依赖的APIService(如metrics-server、自定义CRD的API)不可用,相关资源清理可能失败。 4. **权限不足** 执行删除操作的体(如用户或ServiceAccount)缺乏删除某些资源的权限。 --- ### 解决步骤 #### 1. 检查残留资源 ```bash kubectl api-resources --verbs=list --namespaced -o name | xargs -n1 kubectl get -n <namespace> ``` 若发现未删除的资源,手动清理: ```bash kubectl delete <resource-type>/<name> -n <namespace> --force --grace-period=0 ``` #### 2. 移除Finalizers 编辑Namespace配置以删除finalizers: ```bash kubectl get namespace <namespace> -o json > tmp.json ``` 修改`tmp.json`,删除`.spec.finalizers`字段内容,然后执行: ```bash kubectl replace --raw "/api/v1/namespaces/<namespace>/finalize" -f tmp.json ``` #### 3. 检查APIService状态 ```bash kubectl get apiservice ``` 若发现状态为$False$的APIService(如$v1beta1.metrics.k8s.io$),尝试重启相关控制器或修复其部署。 #### 4. 强制删除(慎用) 通过API直接强制删除: ```bash kubectl delete namespace <namespace> --force --grace-period=0 ``` --- ### 注意事项 - **数据风险**:强制删除可能残留etcd中的数据,需后续手动清理。 - **控制器影响**:若因控制器故障导致问题,需修复控制器逻辑。 - **权限验证**:确保操作账户具有`delete`权限,可通过: ```bash kubectl auth can-i delete namespaces ``` 通过以上步骤,可解决Namespace在$Terminating$状态的问题。若仍不成功,需结合具体日志(如kube-controller-manager日志)进一步分析。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值