作者 | 聲東  阿里雲售後技術專家

> **導讀**：阿里雲售後技術團隊的同學，每天都在處理各式各樣千奇百怪的線上問題。常見的有網路連線失敗、伺服器當機、效能不達標及請求響應慢等。但如果要評選的話，什麼問題看起來微不足道事實上卻讓人絞盡腦汁，我相信肯定是“刪不掉”的問題，比如檔案刪不掉、程式結束不掉、驅動解除安裝不了等。這樣的問題就像冰山，隱藏在它們背後的複雜邏輯，往往超過我們的預想。

# 背景

今天我們討論的這個問題，跟 K8s 叢集的 Namespace 有關。Namespace 是 K8s 叢集資源的“收納”機制。我們可以把相關的資源“收納”到同一個 Namespace 裡，以避免不相關資源之間不必要的影響。

Namespace 本身也是一種資源。透過叢集 API Server 入口，我們可以新建 Namespace，而對於不再使用的 Namespace，我們需要清理掉。Namespace 的 Controller 會透過 API Server，監視叢集中 Namespace 的變化，然後根據變化來執行預先定義的動作。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/755d9fc47b704315b8c02ea673bafa60.png)

有時候，我們會遇到下圖中的問題，即 Namespace 的狀態被標記成了 "Terminating"，但卻沒有辦法被完全刪除。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/5033409e2a8a4a7fa25dde110eac9059.png)

# 從叢集入口開始

因為刪除操作是透過叢集 API Server 來執行的，所以我們要分析 API Server 的行為。跟大多數叢集元件類似，API Server 提供了不同級別的日誌輸出。為了理解 API Server 的行為，我們將日誌級別調整到最高階。然後，透過建立刪除 tobedeletedb 這個 Namespace 來重現問題。

但可惜的是，API Server 並沒有輸出太多和這個問題有關的日誌。

相關的日誌，可以分為兩部分：

- 一部分是 Namespace 被刪除的記錄，記錄顯示客戶端工具是 kubectl，以及發起操作的源 IP 地址是 192.168.0.41，這符合預期；
- 另外一部分是 Kube Controller Manager 在重複地獲取這個 Namespace 的資訊。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/bc6e794de198423f910425044605d024.png)

Kube Controller Manager 實現了叢集中大多數的 Controller，它在重複獲取 tobedeletedb 的資訊，基本上可以判斷，是 Namespace 的 Controller 在獲取這個 Namespace 的資訊。

# Controller 在做什麼？
和上一節類似，我們透過開啟 Kube Controller Manager 最高階別日誌，來研究這個元件的行為。在 Kube Controller Manager 的日誌裡，可以看到 Namespace 的 Controller 在不斷地嘗試一個失敗了的操作，就是清理 tobedeletedb 這個 Namespace 裡“收納”的資源。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/d0beef076e1a460fa44cfb145d94cbe4.png)

## 怎麼樣刪除“收納盒”裡的資源？
這裡我們需要理解一點，就是 Namespace 作為資源的“收納盒”，其實是邏輯意義上的概念。它並不像現實中的收納工具，可以把小的物件收納其中。Namespace 的“收納”實際上是一種對映關係。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/455adc8894004413b6f0ff1a8369ff46.png)

這一點之所以重要，是因為它直接決定了，刪除 Namespace 內部資源的方法。如果是物理意義上的“收納”，那我們只需要刪除“收納盒”，裡邊的資源就一併被刪除了。而對於邏輯意義上的關係，我們則需要羅列所有資源，並刪除那些指向需要刪除的 Namespace 的資源。

## API、Group、Version
怎麼樣羅列叢集中的所有資源呢？這個問題需要從叢集 API 的組織方式說起。K8s 叢集的 API 不是鐵板一塊的，它是用分組和版本來組織的。這樣做的好處顯而易見，就是不同分組的 API 可以獨立迭代，互不影響。常見的分組如 apps，它有 v1、v1beta1 和 v1beta2 三個版本。完整的分組/版本列表，可以使用 kubectl api-versions 命令看到。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/25c23619f742450e8054806f73da7598.png)

我們建立的每一個資源，都必然屬於某一個 API 分組/版本。以下邊 Ingress 為例，我們指定 Ingress 資源的分組/版本為 networking.k8s.io/v1beta1。

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

用一個簡單的示意圖來總結 API 分組和版本。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/15e8d972944844f5a80c3fa0f37832b1.png)

實際上，叢集有很多 API 分組/版本，每個 API 分組/版本支援特定的資源型別。我們透過 yaml 編排資源時，需要指定資源型別 kind，以及 API 分組/版本 apiVersion。而要列出資源，我們需要獲取 API 分組/版本的列表。

## Controller 為什麼不能刪除 Namespace 裡的資源

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

# 再次回到叢集入口

在上一節中，我們發現 Kube Controller Manager 在獲取 metrics.k8s.io/v1beta1 這個 API 分組/版本的時候失敗了。而這個查詢請求，顯然是發給 API Server 的。所以我們回到 API Server 日誌，分析 metrics.k8s.io/v1beta1 相關的記錄。在相同的時間點，我們看到 API Server 也報了同樣的錯誤 "the server is currently unable to handle the request"。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/81cff9a1fd4a43fd83c0ce9c1eb7ac52.png)

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

![9.png](https://ucc.alicdn.com/pic/developer-ecology/8798527dcbf9473399eded2fb9ebc849.png)

叢集 API Server 有擴充套件自己的機制，開發者可以利用這個機制，來實現 API Server 的“外掛”。這個“外掛”的主要功能，就是實現新的 API 分組/版本。API Server 作為代理，會把相應的 API 呼叫，轉發給自己的“外掛”。

以 Metrics Server 為例，它實現了 metrics.k8s.io/v1beta1 這個 API 分組/版本。所有針對這個分組/版本的呼叫，都會被轉發到 Metrics Server。如下圖，Metrics Server 的實現，主要用到一個服務和一個 pod。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/4fcf9fd92f294753969563e34b82a8b7.png)

而上圖中最後的 apiservice，則是把“外掛”和 API Server 聯絡起來的機制。下圖可以看到這個 apiservice 詳細定義。它包括 API 分組/版本，以及實現了 Metrics Server 的服務名。有了這些資訊，API Server 就能把針對 metrics.k8s.io/v1beta1 的呼叫，轉發給 Metrics Server。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/05d7d87e5241452b99caa2e53c83e189.png)

# 節點與Pod之間的通訊

經過簡單的測試，我們發現，這個問題實際上是 API server 和 metrics server pod 之間的通訊問題。在阿里雲 K8s 叢集環境裡，API Server 使用的是主機網路，即 ECS 的網路，而 Metrics Server 使用的是 Pod 網路。這兩者之間的通訊，依賴於 VPC 路由表的轉發。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/6effde274ada4687b95c4c6fc8503b7d.png)

以上圖為例，如果 API Server 執行在 Node A 上，那它的 IP 地址就是 192.168.0.193。假設 Metrics Server 的 IP 是 172.16.1.12，那麼從 API Server 到 Metrics Server 的網路連線，必須要透過 VPC 路由表第二條路由規則的轉發。

檢查叢集 VPC 路由表，發現指向 Metrics Server 所在節點的路由表項缺失，所以 API server 和 Metrics Server 之間的通訊出了問題。

## Route Controller 為什麼不工作？

為了維持叢集 VPC 路由表項的正確性，阿里雲在 Cloud Controller Manager 內部實現了 Route Controller。這個 Controller 在時刻監聽著叢集節點狀態，以及 VPC 路由表狀態。當發現路由表項缺失的時候，它會自動把缺失的路由表項填寫回去。

現在的情況，顯然和預期不一致，Route Controller 顯然沒有正常工作。這個可以透過檢視 Cloud Controller Manager 日誌來確認。在日誌中，我們發現，Route Controller 在使用叢集 VPC id 去查詢 VPC 例項的時候，沒有辦法獲取到這個例項的資訊。

![13.png](https://ucc.alicdn.com/pic/developer-ecology/d538092dd8934db7bd502385fcee42d4.png)

但是叢集還在，ECS 還在，所以 VPC 不可能不在了。這一點我們可以透過 VPC id 在 VPC 控制檯確認。那下邊的問題，就是為什麼 Cloud Controller Manager 沒有辦法獲取到這個 VPC 的資訊呢？

# 叢集節點訪問雲資源

Cloud Controller Manager 獲取 VPC 資訊，是透過阿里雲開放 API 來實現的。這基本上等於從雲上一臺 ECS 內部，去獲取一個 VPC 例項的資訊，而這需要 ECS 有足夠的許可權。目前的常規做法是，給 ECS 伺服器授予 RAM 角色，同時給對應的 RAM 角色繫結相應的角色授權。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/ee98709e925c499387e43afd425892a3.png)

如果叢集元件，以其所在節點的身份，不能獲取雲資源的資訊，那基本上有兩種可能性。一是 ECS 沒有繫結正確的 RAM 角色；二是 RAM 角色繫結的 RAM 角色授權沒有定義正確的授權規則。檢查節點的 RAM 角色，以及 RAM 角色所管理的授權，我們發現，針對 vpc 的授權策略被改掉了。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/9362e270b76141d98ae39def3dbbc89a.png)

當我們把 Effect 修改成 Allow 之後，沒多久，所有的 Terminating 狀態的 namespace 全部都消失了。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/58cc4f426e224809b637dbe00e930c83.png)

# 問題大圖

總體來說，這個問題與 K8s 叢集的 6 個元件有關係，分別是 API Server 及其擴充套件 Metrics Server，Namespace Controller 和 Route Controller，以及 VPC 路由表和 RAM 角色授權。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/f80ff2abae6543bea82e4f1180d4bbda.png)

透過分析前三個元件的行為，我們定位到，叢集網路問題導致了 API Server 無法連線到 Metrics Server；透過排查後三個元件，我們發現導致問題的根本原因是 VPC 路由表被刪除且 RAM 角色授權策略被改動。

# 後記

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

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

我們為什麼會刪除不了叢集的 Namespace？

相關文章