作者 | 聲東? 阿里云售后技術(shù)專家

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了阿魯科爾沁免費(fèi)建站歡迎大家使用！

導(dǎo)讀：阿里云售后技術(shù)團(tuán)隊(duì)的同學(xué)，每天都在處理各式各樣千奇百怪的線上問(wèn)題。常見的有網(wǎng)絡(luò)連接失敗、服務(wù)器宕機(jī)、性能不達(dá)標(biāo)及請(qǐng)求響應(yīng)慢等。但如果要評(píng)選的話，什么問(wèn)題看起來(lái)微不足道事實(shí)上卻讓人絞盡腦汁，我相信肯定是“刪不掉”的問(wèn)題，比如文件刪不掉、進(jìn)程結(jié)束不掉、驅(qū)動(dòng)卸載不了等。這樣的問(wèn)題就像冰山，隱藏在它們背后的復(fù)雜邏輯，往往超過(guò)我們的預(yù)想。

背景

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

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

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

從集群入口開始

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

但可惜的是，API Server 并沒(méi)有輸出太多和這個(gè)問(wèn)題有關(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é)類似，我們通過(guò)開啟 Kube Controller Manager 最高級(jí)別日志，來(lái)研究這個(gè)組件的行為。在 Kube Controller Manager 的日志里，可以看到 Namespace 的 Controller 在不斷地嘗試一個(gè)失敗了的操作，就是清理 tobedeletedb 這個(gè) Namespace 里“收納”的資源。

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

這里我們需要理解一點(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 的資源。

API、Group、Version

怎么樣羅列集群中的所有資源呢？這個(gè)問(wèn)題需要從集群 API 的組織方式說(shuō)起。K8s 集群的 API 不是鐵板一塊的，它是用分組和版本來(lái)組織的。這樣做的好處顯而易見，就是不同分組的 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)單的示意圖來(lái)總結(jié) API 分組和版本。

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

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"。

再次回到集群入口

在上一節(jié)中，我們發(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è)問(wèn)題，我們需要理解一下 API Server 的“外掛”機(jī)制。

集群 API Server 有擴(kuò)展自己的機(jī)制，開發(fā)者可以利用這個(gè)機(jī)制，來(lái)實(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)系起來(lái)的機(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)過(guò)簡(jiǎn)單的測(cè)試，我們發(fā)現(xiàn)，這個(gè)問(wèn)題實(shí)際上是 API server 和 metrics server pod 之間的通信問(wèn)題。在阿里云 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ò)連接，必須要通過(guò) VPC 路由表第二條路由規(guī)則的轉(zhuǎn)發(fā)。

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

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 顯然沒(méi)有正常工作。這個(gè)可以通過(guò)查看 Cloud Controller Manager 日志來(lái)確認(rèn)。在日志中，我們發(fā)現(xiàn)，Route Controller 在使用集群 VPC id 去查找 VPC 實(shí)例的時(shí)候，沒(méi)有辦法獲取到這個(gè)實(shí)例的信息。

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

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

Cloud Controller Manager 獲取 VPC 信息，是通過(guò)阿里云開放 API 來(lái)實(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 沒(méi)有綁定正確的 RAM 角色；二是 RAM 角色綁定的 RAM 角色授權(quán)沒(méi)有定義正確的授權(quán)規(guī)則。檢查節(jié)點(diǎn)的 RAM 角色，以及 RAM 角色所管理的授權(quán)，我們發(fā)現(xiàn)，針對(duì) vpc 的授權(quán)策略被改掉了。

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

問(wèn)題大圖

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

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

后記

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

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

網(wǎng)站標(biāo)題：我們?yōu)槭裁磿?huì)刪除不了集群的Namespace？
本文來(lái)源：http://www.chinadenli.net/article44/jcojee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、網(wǎng)站收錄、軟件開發(fā)、用戶體驗(yàn)、商城網(wǎng)站、手機(jī)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)