Kubernetes 中怎么實現應用高可用

這篇文章將為大家詳細講解有關Kubernetes 中怎么實現應用高可用，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

1. Kubernetes 探針

當你使用 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。

2. 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 中怎么實現應用高可用就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。