作者簡介：

胡家靖

百度基礎架構部研發工程師

負責函數計算與云原生產品的研發

本文基于百度云原生團隊『云原生基礎知識概述及實踐』系列視頻課程——『Kubernetes入門—Kubernetes實現應用高可用』梳理.

視頻課程可點擊：https://cloud.baidu.com/video-center/video.html?id=609進行學習。

導讀
在前兩節課，我們學習了Docker（Kubernetes入門——深入淺出講Docker）和Kubernetes（Kubernetes入門——Kubernetes工作原理及使用）（Kubernetes入門——Kubernetes應用部署）相關基礎知識。
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 將會認為容器已經不在運行，將會重新啟動容器。

探測方式：

HTTP：kubelet 對容器的 IP 地址指定路徑執行 HTTP GET 請求。根據返回碼判斷是否探測成功

TCP套接字：嘗試與容器指定端口建立TCP連接，如果建立成功則表示探測成功。

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 的工作原理，升級方式以及如何回滾。

以上是本期課程的所有內容，希望對大家有幫助。

更多精彩課程歡迎關注百度開發者中心公眾號。

總結

以上是生活随笔為你收集整理的Kubernetes入门——Kubernetes实现应用的高可用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。