這樣的問題就像冰山，影藏在它們背後的複雜邏輯，往往超過我們的預想。

背景

今天我們討論的這個問題，跟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這個名稱空間裡“收納”的資源。

怎麼樣刪除“收納盒”裡的資源

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

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

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

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

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

Controller為什麼不能刪除名稱空間裡的資源

理解了API分組/版本的概念之後，再回頭看Kube Controller Manager的日誌，就會豁然開朗。顯然名稱空間的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”。

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

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

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

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

節點與Pod之間的通訊

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

以上圖為例，如果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例項的時候，沒有辦法獲取到這個例項的資訊。

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

叢集節點訪問雲資源

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

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

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

問題大圖

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

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

後記

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

本文作者：shengdong

原文連結

本文為雲棲社群原創內容，未經