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

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

如何免費下

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

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

1.阿里云真實案例的沉淀

2.理論闡述深入淺出

3.理論和實踐的完美契合

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

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

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

前言

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

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

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

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

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

問題現(xiàn)象

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

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

大邏輯

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

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

在這個問題中，kubelet 扮演的是第二種角色。

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

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

而最終把 kubelet 上報的節(jié)點狀況，落實到節(jié)點狀態(tài)的是節(jié)點控制這個組件。這里我故意區(qū)分了 kubelet 上報的節(jié)點狀況，和節(jié)點的最終狀態(tài)。因為前者，其實是我們 describe node 時看到的 Condition，而后者是真正節(jié)點列表里的 NotReady 狀態(tài)。

就緒三分鐘

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

在解釋它之前，請大家看一下官方這張 PLEG 示意圖。這個圖片主要展示了兩個過程。

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

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

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

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

溫馨提示：

篇幅過長，建議掃描下方二維碼獲取全部內(nèi)容

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

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

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