作者：shengdong
今天我們討論的這個問題，跟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集群命名空間刪除不掉的問題，是線上比較常見的一個問題。這個問題看起來無關痛癢，但實際上不僅複雜，而且意味著集群重要功能的缺失。這篇文章全面分析了一個這樣的問題，其中的排查方法和原理，希望對大家排查類似問題有一定的幫助。
