K8S从懵圈到熟练 - 我们为什么会删除不了集群的命名空间？

阿里云售后技术团队的同学，每天都在处理各式各样千奇百怪的线上问题。常见的有，网络连接失败，服务器宕机，性能不达标，请求响应慢等。但如果要评选，什么问题看起来微不足道事实上却足以让人绞尽脑汁，我相信答案肯定是“删不掉”的问题。比如文件删不掉，进程结束不掉，驱动卸载不了等。

这样的问题就像冰山，影藏在它们背后的复杂逻辑，往往超过我们的预想。

背景

今天我们讨论的这个问题，跟K8S集群的命名空间有关。命名空间是K8S集群资源的“收纳”机制。我们可以把相关的资源，“收纳”到同一个命名空间里，以避免不相关资源之间不必要的影响。

命名空间本身也是一种资源。通过集群API Server入口，我们可以新建命名空间，而对于不再使用的命名空间，我们需要清理掉。命名空间的Controller会通过API Server，监视集群中命名空间的变化，然后根据变化来执行预先定义的动作。

有时候，我们会遇到下图中的问题，即命名空间的状态被标记成了“Terminating”，但却没有办法被完全删除。

从集群入口开始

因为删除操作是通过集群API Server来执行的，所以我们要分析API Server的行为。跟大多数集群组件类似，API Server提供了不同级别的日志输出。为了理解API Server的行为，我们将日志级别调整到最高级。然后，通过创建删除tobedeletedb这个命名空间来重现问题。

但可惜的是，API Server并没有输出太多和这个问题有关的日志。

相关的日志，可以分为两部分。一部分是命名空间被删除的记录，记录显示客户端工具是kubectl，以及发起操作的源IP地址是192.168.0.41，这符合预期；另外一部分是Kube Controller Manager在重复的获取这个命名空间的信息。

Kube Controller Manager实现了集群中大多数的Controller，它在重复获取tobedeletedb的信息，基本上可以判断，是命名空间的Controller在获取这个命名空间的信息。

Controller在做什么？

和上一节类似，我们通过开启Kube Controller Manager最高级别日志，来研究这个组件的行为。在Kube Controller Manager的日志里，可以看到命名空间的Controller在不断地尝试一个失败了的操作，就是清理tobedeletedb这个命名空间里“收纳”的资源。