背景

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

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

图片

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

图片

从集群入口开始

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

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

相关的日志，可以分为两部分：

• 一部分是 Namespace 被删除的记录，记录显示客户端工具是 kubectl，以及发起操作的源 IP 地址是 192.168.0.41，这符合预期；

• 另外一部分是 Kube Controller Manager 在重复地获取这个 Namespace 的信息。

图片

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

Controller 在做什么？

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

1. 怎么样删除“收纳盒”里的资源？

这里我们需要理解一点，就是 Namespace 作为资源的“收纳盒”，其实是逻辑意义上的概念。它并不像现实中的收纳工具，可以把小的物件收纳其中。Namespace 的“收纳”实际上是一种映射关系。

图片

这一点之所以重要，是因为它直接决定了，删除 Namespace 内部资源的方法。如果是物理意义上的“收纳”，那我们只需要删除“收纳盒”，里边的资源就一并被删除了。而对于逻辑意义上的关系，我们则需要罗列所有资源，并删除那些指向需要删除的 Namespace 的资源。

2. API、Group、Version

怎么样罗列集群中的所有资源呢？这个问题需要从集群 API 的组织方式说起。

K8s 集群的 API 不是铁板一块的，它是用分组和版本来组织的。这样做的好处显而易见，就是不同分组的 API 可以独立迭代，互不影响。常见的分组如 apps，它有 v1、v1beta1 和 v1beta2 三个版本。完整的分组/版本列表，可以使用 kubectl api-versions 命令看到。

图片

我们创建的每一个资源，都必然属于某一个 API 分组/版本。以下边 Ingress 为例，我们指定 Ingress 资源的分组/版本为 networking.k8s.io/v1beta1。

kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80