K8S從懵圈到熟練 - 咱們爲何會刪除不了集羣的命名空間？

阿里雲售後技術團隊的同窗，天天都在處理各式各樣千奇百怪的線上問題。常見的有，網絡鏈接失敗，服務器宕機，性能不達標，請求響應慢等。但若是要評選，什麼問題看起來微不足道事實上卻足以讓人絞盡腦汁，我相信答案確定是「刪不掉」的問題。好比文件刪不掉，進程結束不掉，驅動卸載不了等。

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

背景

今天咱們討論的這個問題，跟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

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。