Kubernetes 入門——Kubernetes 實現應用的高可用
胡家靖
百度基礎架構部研發工程師
負責函數計算與雲原生產品的研發
本文基於百度雲原生團隊『雲原生基礎知識概述及實踐』系列視頻課程——『Kubernetes 入門—Kubernetes 實現應用高可用』梳理.
視頻課程可點擊:https://cloud.baidu.com/video-center/video.html?id=609 進行學習。
導讀
Pod 代表了 Kubernetes 中的基本部署單元,但是,在一般情況下我們不會直接使用 Pod,因爲每一次重啓它的 IP 都會發生變化;如果你希望自己的應用能自動保持健康運行而且無需手動干預,則需要通過創建 ReplicaSet 或者 Deployment 這樣的資源來管理實際的 Pod。
另外很多時候我們需要判斷 Pod 是否需要重啓,請求是否可被調度到 Pod,探針的出現使得這些問題迎刃而解。
本節課將帶領大家學習探針與 Deployment 的使用。通過實踐與學習,瞭解 Kubernetes 如何實現應用的高可用。
課程主要分爲以下四個部分:
第一部分:探針
第二部分:Deployment 的使用
第三部分:Demo
第四部分:總結
01
Kubernets 探針
當你使用 kubernetes 的時候,有沒有遇到過 Pod 在啓動後一會就掛掉然後又重新啓動這樣的惡性循環?Kubernetes 如何檢測 pod 是否還存活?雖然容器已經啓動,Kubernetes 如何知道容器的進程是否準備好對外提供服務了呢?答案是:探針
探針種類
LivenessProbe
-
介紹:LivenessProbe 又稱存活探針,其作用主要用於檢測容器是否還在運行。kubelet 使用存活探測器來知道什麼時候要重啓容器。例如,存活探測器可以捕捉到死鎖(應用程序在運行,但是無法繼續執行後面的步驟)。這樣的情況下重啓容器有助於讓應用程序在有問題的情況下更可用。
-
用途:Kubernetes 可以通過存活探針來檢查容器是否還在運行。如果探測失敗,則 Kubernetes 將會認爲容器已經不在運行,將會重新啓動容器。
-
探測方式:
1. HTTP:kubelet 對容器的 IP 地址指定路徑執行 HTTP GET 請求。根據返回碼判斷是否探測成功
2. TCP 套接字:嘗試與容器指定端口建立 TCP 連接,如果建立成功則表示探測成功。
3. Exec:在容器內執行任意命令,檢查退出狀態碼。如返回值爲 0,則探測成功。 -
存活探針 yaml 文件:
綠色爲 http 探針,這裏請求容器的 8080 端口,如果返回是 2xx,或者 3xx,那麼表示探測成功。
紅色爲 exec 探針,這裏執行了一個 cat 命令。
藍色的爲 tcp 探針。作用爲和 8080 端口嘗試建立 TCP 連接。
ReadnessProbe:
-
介紹:就緒探針。用於探測 Pod 是否已經就緒。由於部分 Pod 啓動時將會有較長的初始化時間,就緒探針可以用於探測 Pod 是否已經初始化完畢。kubelet 使用就緒探測器可以知道容器什麼時候準備好了並可以開始接受請求流 量, 當一個 Pod 內的所有容器都準備好了,才能把這個 Pod 看作就緒了。這種信號的一個用途就是控制哪個 Pod 作爲 Service 的後端。在 Pod 還沒有準備好的時候,會從 Service 的負載均衡器中被剔除的。
-
用途:就緒探針在容器生命週期中會被定期調用。確定 Pod 是否接受客戶端請求,當容器的準備就緒探測返回成功時,表示容器已經準備好接受請求。
-
探測方式:
1.HTTP:對容器的 IP 地址指定路徑執行 HTTP GET 請求。根據返回碼判斷是否探測成功
2.TCP 套接字:嘗試與容器指定端口建立 TCP 連接,如果建立成功則表示探測成功。
3.Exec:在容器內執行任意命令,檢查退出狀態碼。如狀態碼爲 0,則探測成功。 -
就緒探針的 yaml 文件:
就緒探針與存活探針配置幾乎一致。
只是字段爲 readinessProbe。
02
Deployment 的使用
ReplicaSet
-
簡介:Pod 不可靠,可能會宕掉,可以配置重啓,但是如果是 Pod 所在的節點宕掉,Pod 就會完全丟失,如果在生產環境就會出現問題。另外我們一般不會使用單個 Pod,而是許多組相同的 Pod 來提供服務,如果手動維護的話會特別困難,特別是在集羣數量比較大的時候,所以這裏對 ReplicaSet 進行介紹。ReplicaSet 的目的是維護一組在任何時候都處於運行狀態的 Pod 副本的穩定集合。因此,它通常用來保證給定數量的、完全相同的 Pod 的可用性。
-
工作原理:RepicaSet 是通過一組字段來定義的,包括一個用來識別可獲得的 Pod 的集合的選擇算符,一個用來標明應該維護的副本個數的數值,一個用來指定應該創建新 Pod 以滿足副本個數條件時要使用的 Pod 模板等等。每個 ReplicaSet 都通過根據需要創建和 刪除 Pod 以使得副本個數達到期望值,進而實現其存在價值。當 ReplicaSet 需要創建新的 Pod 時,會使用所提供的 Pod 模板。
-
工作過程:ReplicaSet 的目的是維護一組在任何時候都處於運行狀態的 Pod 副本的穩定集合。因此,它通常用來保證給定數量的、完全相同的 Pod 的可用性。
每次 ReplicaSet 會監控當前 Pod 的數量,如果 Pod 數量多於要求的數量,則會自動刪除一 部分。否則會自動創建,創建過程中會使用模板創建。
ReplicaSet 爲故障節點上運行的 Pod 創建了新的替代副本,輕鬆地實現了 pod 的水平伸縮。
如果你更改了一個 pod 的標籤,就有可能讓它脫離它所屬的 ReplicaSet
同理,如果你想將一個 Pod 歸到 Replicas Set 中,也可以使用修改標籤的方式將其增加到 ReplicaSet 中。
-
ReplicaSet yaml 示例
1.Label Selector: 標籤選擇器,用於確定作用域
2.Replicas:副本個數,也就是作用域
3.Pod template: pod 模板
Deployment
一個 Deployment 控制器爲 Pod 和 ReplicasSet 提供聲明式的更新能力。
你負責描述 Deployment 中的 目標狀態,而 Deployment 控制器以受控速率更改實際狀態, 使其變爲期望狀態。你可以定義 Deployment 以創建新的 ReplicaSet,或刪除現有 Deployment, 並通過新的 Deployment 收養其資源。
-
Deployment yaml 示例
Deployment yaml 文件與 ReplicaSet 十分相似, 只是多了 strategy 字段。該字段主要用於描述升級方式。
Deployment 並不直接管理 Pod
當創建 Deployment 時,ReplicaSet 也會隨之創建。在實際使用 Deployment 的時候,實際的 Pod 由 ReplicaSet 創建和管理,而不是由 Deployment 直接管理。
使用 Deployment 可以更容易地更新應用程序,因爲可以直接定義單個 Deployment 資源所需要達到的狀態,並讓 Kubernetes 處理中間狀態。
升級 Deployment
Deployment 支持聲明式更新,即只需要修改 Deployment 資源中的 Pod 模板,Kubernetes 會自動將實際的系統狀態收斂爲資源中定義的狀態。
Deployment 支持不同的升級策略,主要分爲 RollingUpdate 以及 Recreate 模式,本策略在 deployment.spec.strategy 字段中定義。詳情可以使用 kubectl explain 命令獲取。
Deployment Recreate 升級
Deployment Recreate 升級策略將會直接停止老版本 Pod, 並創建新的 ReplicaSet 和 Pod。並且進行流量切換。具體步驟如下所示:
缺陷是,升級過程中有一段時間沒有 Pod 運行,此時如果有外部請求,服務就處於不可用狀態,會損失一定流量。
Deployment RollingUpdate 升級
滾動升級方式如上圖所示:
Kubernetes 會先額外創建 v2 版本的 pod 以及 replicaSet。並且逐漸銷燬 v1 版本的 pod,從而實現滾動升級
同時,在生產環境中我們十分建議 Deployment 配合就緒探針使用。因爲默認情況下, Pod running 時就會接受請求。但是實際上內部服務可能並未就緒。
所以可以配合 minReadySeconds 字段,以及就緒探針等相關功能進一步使用。
03
課程總結
1、探針的使用,就緒探針與存活探針。三種探測方式
2、ReplicaSet 的工作原理,通過 label 將 pod 維持在一定數量
3、Deployment 的工作原理,升級方式以及如何回滾。
以上是本期課程的所有內容,希望對大家有幫助。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/mmFUoHRaPi1UBNI8BJwpTw