背景

今天我們討論的這個(gè)問題，跟 K8s 集群的 Namespace 有關(guān)。Namespace 是 K8s 集群資源的“收納”機(jī)制。我們可以把相關(guān)的資源“收納”到同一個(gè) Namespace 里，以避免不相關(guān)資源之間不必要的影響。

Namespace 本身也是一種資源。通過集群 API Server 入口，我們可以新建 Namespace，而對(duì)于不再使用的 Namespace，我們需要清理掉。Namespace 的 Controller 會(huì)通過 API Server，監(jiān)視集群中 Namespace 的變化，然后根據(jù)變化來執(zhí)行預(yù)先定義的動(dòng)作。

圖片

有時(shí)候，我們會(huì)遇到下圖中的問題，即 Namespace 的狀態(tài)被標(biāo)記成了 "Terminating"，但卻沒有辦法被完全刪除。

圖片

從集群入口開始

因?yàn)閯h除操作是通過集群 API Server 來執(zhí)行的，所以我們要分析 API Server 的行為。跟大多數(shù)集群組件類似，API Server 提供了不同級(jí)別的日志輸出。為了理解 API Server 的行為，我們將日志級(jí)別調(diào)整到最高級(jí)。然后，通過創(chuàng)建刪除 tobedeletedb 這個(gè) Namespace 來重現(xiàn)問題。

但可惜的是，API Server 并沒有輸出太多和這個(gè)問題有關(guān)的日志。

相關(guān)的日志，可以分為兩部分：

• 一部分是 Namespace 被刪除的記錄，記錄顯示客戶端工具是 kubectl，以及發(fā)起操作的源 IP 地址是 192.168.0.41，這符合預(yù)期；

• 另外一部分是 Kube Controller Manager 在重復(fù)地獲取這個(gè) Namespace 的信息。

圖片

Kube Controller Manager 實(shí)現(xiàn)了集群中大多數(shù)的 Controller，它在重復(fù)獲取 tobedeletedb 的信息，基本上可以判斷，是 Namespace 的 Controller 在獲取這個(gè) Namespace 的信息。

Controller 在做什么？

和上一節(jié)類似，我們通過開啟 Kube Controller Manager 最高級(jí)別日志，來研究這個(gè)組件的行為。在 Kube Controller Manager 的日志里，可以看到 Namespace 的 Controller 在不斷地嘗試一個(gè)失敗了的操作，就是清理 tobedeletedb 這個(gè) Namespace 里“收納”的資源。

1. 怎么樣刪除“收納盒”里的資源？

這里我們需要理解一點(diǎn)，就是 Namespace 作為資源的“收納盒”，其實(shí)是邏輯意義上的概念。它并不像現(xiàn)實(shí)中的收納工具，可以把小的物件收納其中。Namespace 的“收納”實(shí)際上是一種映射關(guān)系。

圖片

這一點(diǎn)之所以重要，是因?yàn)樗苯記Q定了，刪除 Namespace 內(nèi)部資源的方法。如果是物理意義上的“收納”，那我們只需要?jiǎng)h除“收納盒”，里邊的資源就一并被刪除了。而對(duì)于邏輯意義上的關(guān)系，我們則需要羅列所有資源，并刪除那些指向需要?jiǎng)h除的 Namespace 的資源。

2. API、Group、Version

怎么樣羅列集群中的所有資源呢？這個(gè)問題需要從集群 API 的組織方式說起。

K8s 集群的 API 不是鐵板一塊的，它是用分組和版本來組織的。這樣做的好處顯而易見，就是不同分組的 API 可以獨(dú)立迭代，互不影響。常見的分組如 apps，它有 v1、v1beta1 和 v1beta2 三個(gè)版本。完整的分組/版本列表，可以使用 kubectl api-versions 命令看到。

圖片

我們創(chuàng)建的每一個(gè)資源，都必然屬于某一個(gè) API 分組/版本。以下邊 Ingress 為例，我們指定 Ingress 資源的分組/版本為 networking.k8s.io/v1beta1。

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

用一個(gè)簡(jiǎn)單的示意圖來總結(jié) API 分組和版本。

圖片

實(shí)際上，集群有很多 API 分組/版本，每個(gè) API 分組/版本支持特定的資源類型。我們通過 yaml 編排資源時(shí)，需要指定資源類型 kind，以及 API 分組/版本 apiVersion。而要列出資源，我們需要獲取 API 分組/版本的列表。

3. Controller 為什么不能刪除 Namespace 里的資源？

理解了 API 分組/版本的概念之后，再回頭看 Kube Controller Manager 的日志，就會(huì)豁然開朗。顯然 Namespace 的 Controller 在嘗試獲取 API 分組/版本列表，當(dāng)遇到 metrics.k8s.io/v1beta1 的時(shí)候，查詢失敗了。并且查詢失敗的原因是 "the server is currently unable to handle the request"。

再次回到集群入口

在上文中，我們發(fā)現(xiàn) Kube Controller Manager 在獲取 metrics.k8s.io/v1beta1 這個(gè) API 分組/版本的時(shí)候失敗了。而這個(gè)查詢請(qǐng)求，顯然是發(fā)給 API Server 的。所以我們回到 API Server 日志，分析 metrics.k8s.io/v1beta1 相關(guān)的記錄。

在相同的時(shí)間點(diǎn)，我們看到 API Server 也報(bào)了同樣的錯(cuò)誤 "the server is currently unable to handle the request"。

圖片

顯然這里有一個(gè)矛盾，就是 API Server 明顯在正常工作，為什么在獲取 metrics.k8s.io/v1beta1 這個(gè) API 分組版本的時(shí)候，會(huì)返回 Server 不可用呢？為了回答這個(gè)問題，我們需要理解一下 API Server 的“外掛”機(jī)制。

圖片

集群 API Server 有擴(kuò)展自己的機(jī)制，開發(fā)者可以利用這個(gè)機(jī)制，來實(shí)現(xiàn) API Server 的“外掛”。這個(gè)“外掛”的主要功能，就是實(shí)現(xiàn)新的 API 分組/版本。API Server 作為代理，會(huì)把相應(yīng)的 API 調(diào)用，轉(zhuǎn)發(fā)給自己的“外掛”。

以 Metrics Server 為例，它實(shí)現(xiàn)了 metrics.k8s.io/v1beta1 這個(gè) API 分組/版本。所有針對(duì)這個(gè)分組/版本的調(diào)用，都會(huì)被轉(zhuǎn)發(fā)到 Metrics Server。如下圖，Metrics Server 的實(shí)現(xiàn)，主要用到一個(gè)服務(wù)和一個(gè) pod。

圖片

而上圖中最后的 apiservice，則是把“外掛”和 API Server 聯(lián)系起來的機(jī)制。下圖可以看到這個(gè) apiservice 詳細(xì)定義。它包括 API 分組/版本，以及實(shí)現(xiàn)了 Metrics Server 的服務(wù)名。有了這些信息，API Server 就能把針對(duì) metrics.k8s.io/v1beta1 的調(diào)用，轉(zhuǎn)發(fā)給 Metrics Server。

圖片

節(jié)點(diǎn)與 Pod 之間的通信

經(jīng)過簡(jiǎn)單的測(cè)試，我們發(fā)現(xiàn)，這個(gè)問題實(shí)際上是 API server 和 metrics server pod 之間的通信問題。在阿里云 K8s 集群環(huán)境里，API Server 使用的是主機(jī)網(wǎng)絡(luò)，即 ECS 的網(wǎng)絡(luò)，而 Metrics Server 使用的是 Pod 網(wǎng)絡(luò)。這兩者之間的通信，依賴于 VPC 路由表的轉(zhuǎn)發(fā)。

圖片

以上圖為例，如果 API Server 運(yùn)行在 Node A 上，那它的 IP 地址就是 192.168.0.193。假設(shè) Metrics Server 的 IP 是 172.16.1.12，那么從 API Server 到 Metrics Server 的網(wǎng)絡(luò)連接，必須要通過 VPC 路由表第二條路由規(guī)則的轉(zhuǎn)發(fā)。

檢查集群 VPC 路由表，發(fā)現(xiàn)指向 Metrics Server 所在節(jié)點(diǎn)的路由表項(xiàng)缺失，所以 API server 和 Metrics Server 之間的通信出了問題。

Route Controller 為什么不工作？

為了維持集群 VPC 路由表項(xiàng)的正確性，阿里云在 Cloud Controller Manager 內(nèi)部實(shí)現(xiàn)了 Route Controller。這個(gè) Controller 在時(shí)刻監(jiān)聽著集群節(jié)點(diǎn)狀態(tài)，以及 VPC 路由表狀態(tài)。當(dāng)發(fā)現(xiàn)路由表項(xiàng)缺失的時(shí)候，它會(huì)自動(dòng)把缺失的路由表項(xiàng)填寫回去。

現(xiàn)在的情況，顯然和預(yù)期不一致，Route Controller 顯然沒有正常工作。這個(gè)可以通過查看 Cloud Controller Manager 日志來確認(rèn)。在日志中，我們發(fā)現(xiàn)，Route Controller 在使用集群 VPC id 去查找 VPC 實(shí)例的時(shí)候，沒有辦法獲取到這個(gè)實(shí)例的信息。

圖片

但是集群還在，ECS 還在，所以 VPC 不可能不在了。這一點(diǎn)我們可以通過 VPC id 在 VPC 控制臺(tái)確認(rèn)。那下邊的問題，就是為什么 Cloud Controller Manager 沒有辦法獲取到這個(gè) VPC 的信息呢？

集群節(jié)點(diǎn)訪問云資源

Cloud Controller Manager 獲取 VPC 信息，是通過阿里云開放 API 來實(shí)現(xiàn)的。這基本上等于從云上一臺(tái) ECS 內(nèi)部，去獲取一個(gè) VPC 實(shí)例的信息，而這需要 ECS 有足夠的權(quán)限。目前的常規(guī)做法是，給 ECS 服務(wù)器授予 RAM 角色，同時(shí)給對(duì)應(yīng)的 RAM 角色綁定相應(yīng)的角色授權(quán)。

圖片

如果集群組件，以其所在節(jié)點(diǎn)的身份，不能獲取云資源的信息，那基本上有兩種可能性。一是 ECS 沒有綁定正確的 RAM 角色；二是 RAM 角色綁定的 RAM 角色授權(quán)沒有定義正確的授權(quán)規(guī)則。檢查節(jié)點(diǎn)的 RAM 角色，以及 RAM 角色所管理的授權(quán)，我們發(fā)現(xiàn)，針對(duì) vpc 的授權(quán)策略被改掉了。

圖片

當(dāng)我們把 Effect 修改成 Allow 之后，沒多久，所有的 Terminating 狀態(tài)的 namespace 全部都消失了。

圖片

問題大圖

總體來說，這個(gè)問題與 K8s 集群的 6 個(gè)組件有關(guān)系，分別是 API Server 及其擴(kuò)展 Metrics Server，Namespace Controller 和 Route Controller，以及 VPC 路由表和 RAM 角色授權(quán)。

圖片

通過分析前三個(gè)組件的行為，我們定位到，集群網(wǎng)絡(luò)問題導(dǎo)致了 API Server 無法連接到 Metrics Server；通過排查后三個(gè)組件，我們發(fā)現(xiàn)導(dǎo)致問題的根本原因是 VPC 路由表被刪除且 RAM 角色授權(quán)策略被改動(dòng)。

總結(jié)

K8s 集群 Namespace 刪除不掉的問題，是線上比較常見的一個(gè)問題。這個(gè)問題看起來無關(guān)痛癢，但實(shí)際上不僅復(fù)雜，而且意味著集群重要功能的缺失。這篇文章全面分析了一個(gè)這樣的問題，其中的排查方法和原理，希望對(duì)大家排查類似問題有一定的幫助。