一直關(guān)注云計(jì)算領(lǐng)域的人，必定知道Docker和Kubernetes的崛起。如今，世界范圍內(nèi)的公有云巨頭（谷歌、亞馬遜、微軟、華為云、阿里云等等）都在其傳統(tǒng)的公共云服務(wù)之上提供托管的Kubernetes服務(wù)。Kubernetes功能強(qiáng)大、擴(kuò)展性高，在許多人看來(lái)，它正在成為云計(jì)算的終極解決方案。

接下來(lái)本文將為大家免費(fèi)提供阿里云《深入淺出Kubernetes項(xiàng)目實(shí)戰(zhàn)手冊(cè)》下載，幫助你一次搞懂 6 個(gè)核心原理，吃透基礎(chǔ)理論，一次學(xué)會(huì) 6 個(gè)典型問(wèn)題的華麗操作！

如何免費(fèi)下

掃描添加，發(fā)送"阿里云"，即可免費(fèi)獲得

為何值得所有技術(shù)人收藏？

1.阿里云真實(shí)案例的沉淀

2.理論闡述深入淺出

3.理論和實(shí)踐的完美契合

4.技術(shù)細(xì)節(jié)追根究底

本書(shū)作者羅建龍（花名聲東），阿里云技術(shù)專(zhuān)家，有著多年操作系統(tǒng)和圖形顯卡驅(qū)動(dòng)調(diào)試和開(kāi)發(fā)經(jīng)驗(yàn)。目前專(zhuān)注云原生領(lǐng)域，容器集群和服務(wù)網(wǎng)格。本書(shū)分為理論篇和實(shí)踐篇，共匯集了 12 篇技術(shù)文章，深入解析了集群控制、集群伸縮原理、鏡像拉取等理論，帶你實(shí)現(xiàn)從基礎(chǔ)概念的準(zhǔn)確理解到上手實(shí)操的精準(zhǔn)熟練，深入淺出使用 Kubernetes！

精彩分享：以下內(nèi)容節(jié)選自《深入淺出 Kubernetes》一書(shū)

前言

阿里云有自己的 Kubernetes 容器集群產(chǎn)品。隨著 Kubernetes 集群出貨量的劇增，線上用戶(hù)零星的發(fā)現(xiàn)，集群會(huì)非常低概率地出現(xiàn)節(jié)點(diǎn) NotReady 情況。

據(jù)我們觀察，這個(gè)問(wèn)題差不多每個(gè)月就會(huì)有一到兩個(gè)客戶(hù)遇到。在節(jié)點(diǎn) NotReady 之后，集群 Master 沒(méi)有辦法對(duì)這個(gè)節(jié)點(diǎn)做任何控制，比如下發(fā)新的 Pod，再比如抓取節(jié)點(diǎn)上正在運(yùn)行 Pod 的實(shí)時(shí)信息。

在上面的問(wèn)題中，我們的排查路徑從 K8s 集群到容器運(yùn)行時(shí)，再到 sdbus 和 systemd，不可謂不復(fù)雜。這個(gè)問(wèn)題目前已經(jīng)在 systemd 中做了修復(fù)，所以基本上能看到這個(gè)問(wèn)題的幾率是越來(lái)越低了。

但是，集群節(jié)點(diǎn)就緒問(wèn)題還是有的，然而原因卻有所不同。

今天這篇文章，將側(cè)重和大家分享另外一例集群節(jié)點(diǎn) NotReady 的問(wèn)題。這個(gè)問(wèn)題和上面問(wèn)題相比，排查路徑完全不同。

問(wèn)題現(xiàn)象

這個(gè)問(wèn)題的現(xiàn)象，也是集群節(jié)點(diǎn)會(huì)變成 NotReady 狀態(tài)。問(wèn)題可以通過(guò)重啟節(jié)點(diǎn)暫時(shí)解決，但是在經(jīng)過(guò)大概 20 天左右之后，問(wèn)題會(huì)再次出現(xiàn)。

問(wèn)題出現(xiàn)之后，如果我們重啟節(jié)點(diǎn)上 kubelet，則節(jié)點(diǎn)會(huì)變成 Ready 狀態(tài)，但這種狀態(tài)只會(huì)持續(xù)三分鐘。這是一個(gè)特別的情況。

大邏輯

在具體分析這個(gè)問(wèn)題之前，我們先來(lái)看一下集群節(jié)點(diǎn)就緒狀態(tài)背后的大邏輯。K8s 集群中，與節(jié)點(diǎn)就緒狀態(tài)有關(guān)的組件，主要有四個(gè)，分別是：集群的核心數(shù)據(jù)庫(kù) etcd、集群的入口 API Server、節(jié)點(diǎn)控制器以及駐守在集群節(jié)點(diǎn)上直接管理節(jié)點(diǎn)的 kubelet。

一方面，kubelet 扮演的是集群控制器的角色，它定期從 API Server 獲取 Pod 等相關(guān)資源的信息，并依照這些信息，控制運(yùn)行在節(jié)點(diǎn)上 Pod 的執(zhí)行；另外一方面，kubelet 作為節(jié)點(diǎn)狀況的監(jiān)視器，它獲取節(jié)點(diǎn)信息，并以集群客戶(hù)端的角色，把這些狀況同步到 API Server。

在這個(gè)問(wèn)題中，kubelet 扮演的是第二種角色。

Kubelet 會(huì)使用上圖中的 NodeStatus 機(jī)制，定期檢查集群節(jié)點(diǎn)狀況，并把節(jié)點(diǎn)狀況同步到 API Server。而 NodeStatus 判斷節(jié)點(diǎn)就緒狀況的一個(gè)主要依據(jù)，就是 PLEG。

PLEG是Pod Lifecycle Events Generator的縮寫(xiě)，基本上它的執(zhí)行邏輯，是定期檢查節(jié)點(diǎn)上Pod運(yùn)行情況，如果發(fā)現(xiàn)感興趣的變化，PLEG 就會(huì)把這種變化包裝成 Event 發(fā)送給 Kubelet 的主同步機(jī)制 syncLoop 去處理。但是，在 PLEG 的 Pod 檢查機(jī)制不能定期執(zhí)行的時(shí)候，NodeStatus 機(jī)制就會(huì)認(rèn)為，這個(gè)節(jié)點(diǎn)的狀況是不對(duì)的，從而把這種狀況同步到 API Server。

而最終把 kubelet 上報(bào)的節(jié)點(diǎn)狀況，落實(shí)到節(jié)點(diǎn)狀態(tài)的是節(jié)點(diǎn)控制這個(gè)組件。這里我故意區(qū)分了 kubelet 上報(bào)的節(jié)點(diǎn)狀況，和節(jié)點(diǎn)的最終狀態(tài)。因?yàn)榍罢?，其?shí)是我們 describe node 時(shí)看到的 Condition，而后者是真正節(jié)點(diǎn)列表里的 NotReady 狀態(tài)。

就緒三分鐘

在問(wèn)題發(fā)生之后，我們重啟 kubelet，節(jié)點(diǎn)三分鐘之后才會(huì)變成 NotReady 狀態(tài)。這個(gè)現(xiàn)象是問(wèn)題的一個(gè)關(guān)鍵切入點(diǎn)。

在解釋它之前，請(qǐng)大家看一下官方這張 PLEG 示意圖。這個(gè)圖片主要展示了兩個(gè)過(guò)程。

• 一方面，kubelet 作為集群控制器，從 API Server 處獲取 pod spec changes，然后通過(guò)創(chuàng)建 worker 線程來(lái)創(chuàng)建或結(jié)束掉 pod；
• 另外一方面，PLEG 定期檢查容器狀態(tài)，然后把狀態(tài)，以事件的形式反饋給 kubelet。

在這里，PLEG 有兩個(gè)關(guān)鍵的時(shí)間參數(shù)：一個(gè)是檢查的執(zhí)行間隔，另外一個(gè)是檢查的超時(shí)時(shí)間。以默認(rèn)情況為準(zhǔn)，PLEG 檢查會(huì)間隔一秒，換句話說(shuō)，每一次檢查過(guò)程執(zhí)行之后，PLEG 會(huì)等待一秒鐘，然后進(jìn)行下一次檢查；而每一次檢查的超時(shí)時(shí)間是三分鐘，如果一次 PLEG 檢查操作不能在三分鐘內(nèi)完成，那么這個(gè)狀況，會(huì)被上一節(jié)提到的 NodeStatus 機(jī)制，當(dāng)做集群節(jié)點(diǎn) NotReady 的憑據(jù)，同步給 API Server。

而我們之所以觀察到節(jié)點(diǎn)會(huì)在重啟 kubelet 之后就緒三分鐘，是因?yàn)?kubelet 重啟之后，第一次 PLEG 檢查操作就沒(méi)有順利結(jié)束。節(jié)點(diǎn)就緒狀態(tài)，直到三分鐘超時(shí)之后，才被同步到集群。

如下圖，上邊一行表示正常情況下 PLEG 的執(zhí)行流程，下邊一行則表示有問(wèn)題的情況。relist 是檢查的主函數(shù)。

溫馨提示：

篇幅過(guò)長(zhǎng)，建議掃描下方二維碼獲取全部?jī)?nèi)容

掃描下方二維碼通過(guò)后回復(fù)

關(guān)鍵詞：阿里云?！

文章來(lái)源于網(wǎng)絡(luò)，侵刪！