返回文章列表
玄貓（BlackCat）

Kubernetes高用性容錯工作負載管理

本文探討如何在 Kubernetes 中實作高用性和容錯性，重點介紹 ReplicaSet 和 ReplicationController 的使用，以及如何利用這些資源物件來管理和維護 Pod 副本，確保應用程式在面對故障時仍能正常執行。

Kubernetes 雲端原生
高用性 容錯性 Pod ReplicaSet ReplicationController Deployment

在 Kubernetes 環境中，確保應用程式的高用性和容錯性至關重要。本文將探討如何使用 ReplicaSet 和 ReplicationController 這兩個 Kubernetes 資源物件來管理 Pod 副本，進而提升應用程式的可靠性和穩定性。ReplicaSet 作為 ReplicationController 的後繼者，提供了更強大的功能和更靈活的標籤選擇機制，更適合用於現代應用程式的佈署和管理。相較於 ReplicationController 僅支援根據相等的標籤選擇器，ReplicaSet 支援更豐富的集合式選擇器，允許更精確地控制 Pod 的管理範圍。此外，ReplicaSet 與 Deployment 和 HorizontalPodAutoscaler 等更高階的 Kubernetes 物件無縫整合，簡化了應用程式的佈署、更新和擴充套件。對於有狀態應用程式，StatefulSet 提供了更精細的控制和管理能力，確保資料的永續性和一致性。

執行生產級別的Kubernetes工作負載

在前面的章節中，我們專注於容器化的概念以及Kubernetes的基本構建模組，如Pods、Jobs和ConfigMaps。到目前為止，我們的旅程主要涵蓋了單機場景，即應用程式只需要一個容器主機或Kubernetes節點。對於生產級別的Kubernetes，您需要考慮不同的方面，如可擴充套件性、高用性（HA）和負載平衡，這通常需要協調執行在多個主機上的容器。

簡而言之，容器協調是一種在大型動態環境中管理多個容器生命週期的方式——這可以包括佈署和維護容器網路的期望狀態，提供容器的冗餘和高用性（使用外部元件），擴大和縮小叢集和容器副本，自動化健康檢查和遙測（日誌和指標）收集。

在雲規模上解決高效容器協調的問題並不簡單——這就是為什麼Kubernetes存在！

在本章中，我們將涵蓋以下主題：

  • 確保Kubernetes上的高用性和容錯性
  • 什麼是ReplicationController？
  • 什麼是ReplicaSet？

技術要求

本章需要以下內容：

  • 已佈署的Kubernetes叢集。您可以使用本地或根據雲的叢集，但為了完全理解這些概念，我們建議使用多節點、根據雲的Kubernetes叢集。
  • 在本地機器上安裝了Kubernetes命令列介面（CLI）（kubectl），並組態為管理您的Kubernetes叢集。

Kubernetes叢集佈署（本地和根據雲）和kubectl安裝在第3章“安裝您的第一個Kubernetes叢集”中已經介紹過。

確保Kubernetes上的高用性和容錯性

首先，讓我們快速回顧一下我們如何定義高用性（HA）和容錯性（FT），以及它們之間的區別。這些是雲應用程式中的關鍵概念，用於描述系統或解決方案在長時間內持續執行的能力。從系統終端使用者的角度來看，可用性和資料一致性通常是最重要的需求。

高用性

簡而言之，系統工程中的可用性術語描述了系統對終端使用者完全功能和可操作的時間百分比。換句話說，它是系統執行時間除以執行時間和停機時間（基本上是總時間）的總和。例如，如果在過去30天（720小時）中，您的雲應用程式有1小時的非計劃維護時間，並且對終端使用者不可用，這意味著您的應用程式的可用性度量是$\frac{719h}{720h} = 99.861%$。通常，為了簡化設計系統時的表示法，可用性將以所謂的“九”來表示：例如，如果我們說一個系統具有五個九的可用性，則意味著它至少在總時間的99.999%內可用。為了更好地理解，這樣的系統每月最多隻能有26秒的停機時間！這些度量通常是定義收費雲端服務的服務水平協定（SLA）的基礎指標。

根據此，高用性的定義相對簡單明瞭，儘管不夠精確——如果一個系統在長時間內保持執行（可用）而沒有中斷，則該系統具有高用性。通常，我們可以說五個九的可用性被視為高用性的黃金標準。

實作系統的高用性通常涉及以下一種或多種技術：

  • 消除系統中的單點故障（SPOF）。這通常透過元件冗餘來實作。
  • 容錯移轉設定，這是一種可以在目前活躍（可能不健康）的元件與冗餘元件之間自動切換的機制。
  • 負載平衡，這意味著管理進入系統的流量並將其路由到可以處理流量的冗餘元件。這在大多數情況下將涉及適當的容錯移轉設定、元件監控和遙測。

讓我們介紹一下與此相關的容錯性概念，它在諸如在Kubernetes上執行的應用程式等分散式系統中也很重要。

容錯性

現在，容錯性可以被視為高用性概念的補充：如果一個系統在其一個或多個元件發生故障時仍能繼續執行和操作，則該系統具有容錯性。例如，像RAID這樣的容錯機制，用於資料儲存，將資料分佈在多個磁碟上，或者像負載平衡器這樣的容錯機制，將流量重定向到健康的節點，這些都是常用來確保系統還原力和最小化中斷的方法。實作完全的容錯性意味著實作100%的高用性，在許多情況下，這需要複雜的解決方案來主動檢測故障並在元件中修復問題而不會中斷。根據實作方式，故障可能導致效能的逐漸下降，其程度與故障的嚴重程度成比例。這意味著系統中的小故障將對系統在為終端使用者提供請求時的整體效能產生小影響。

Kubernetes應用程式的高用性和容錯性

在前面的章節中，您瞭解了Pods以及Services如何將它們暴露給外部流量（第8章“使用Services暴露您的Pods”）。Services是Kubernetes物件，它們為一組健康的Pods提供穩定的網路地址。在Kubernetes叢集內部，Service使Pods能夠使用由每個節點上的kube-proxy元件管理的虛擬IP地址進行定址。在外部，雲環境通常使用雲負載平衡器來暴露Service。此負載平衡器透過雲控制器管理器元件內的特定於雲的外掛與Kubernetes叢集整合。有了外部負載平衡器，在Kubernetes上執行的微服務或工作負載可以實作跨相同或不同節點上的健康Pods的負載平衡，這是高用性的關鍵構建模組。

Services是用於將請求負載平衡到Pods所必需的，但我們還沒有介紹如何維護相同Pod物件定義的多個副本，這些副本可能是冗餘的並且分配在不同的節點上。Kubernetes提供了多個構建模組來實作這一目標，概述如下：

  • ReplicationController物件——Kubernetes中定義Pod複製的原始形式。
  • ReplicaSet物件——ReplicationController的繼任者。主要區別在於ReplicaSet支援對Pods的集合式需求選擇器。
  • Deployment物件——在ReplicaSet之上的另一層抽象。這提供了對Pods和ReplicaSets的宣告式更新，包括滾動更新和回復。它用於管理無狀態微服務和工作負載。
  • StatefulSet物件——類別似於Deployment，但用於管理叢集中的有狀態微服務和工作負載。在分散式系統設計中，管理狀態通常是最具挑戰性的問題。

管理ReplicaSets的首選方法是透過Deployment物件，它簡化了更新和回復。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title Kubernetes應用程式的高用性和容錯性

rectangle "managed by" as node1
rectangle "used for" as node2

node1 --> node2

@enduml

此圖示說明瞭 Kubernetes 中不同物件之間的關係，以及它們如何用於管理不同型別的應用程式。

ReplicationController 和 ReplicaSet 詳細解說

ReplicationController 和 ReplicaSet 是 Kubernetes 中用於管理 Pod 複製的重要物件。它們確保了指定數量的 Pod 副本始終執行，並且可以在 Pod 失敗或被刪除時自動重新建立。

ReplicationController

ReplicationController 是 Kubernetes 中最早用於管理 Pod 複製的物件。它確保了指定數量的 Pod 副本始終執行，並且可以在 Pod 失敗或被刪除時自動重新建立。

apiVersion: v1
kind: ReplicationController
metadata:
  name: example-rc
spec:
  replicas: 3
  selector:
    app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: example-image
        ports:
        - containerPort: 80

內容解密：

此 ReplicationController 物件定義了一個名為 example-rc 的 ReplicationController，它確保了 3 個名為 example-app 的 Pod 副本始終執行。selector 欄位指定了 ReplicationController 如何選擇要管理的 Pod，而 template 欄位定義了要建立的 Pod 的範本。

ReplicaSet

ReplicaSet 是 ReplicationController 的繼任者，它提供了更多的功能，例如支援集合式需求選擇器。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: example-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: example-image
        ports:
        - containerPort: 80

內容解密：

此 ReplicaSet 物件定義了一個名為 example-rs 的 ReplicaSet，它確保了 3 個名為 example-app 的 Pod 副本始終執行。selector 欄位指定了 ReplicaSet 如何選擇要管理的 Pod，而 template 欄位定義了要建立的 Pod 的範本。與 ReplicationController 不同，ReplicaSet 使用 matchLabels 欄位來指定選擇器。

Kubernetes 高用性與容錯能力的工作負載管理

在現代的雲端原生應用程式開發中，Kubernetes 已成為事實上的容器協調標準。為了確保應用程式的高用性（HA）和容錯能力（FT），Kubernetes 提供了多種機制來管理和維護工作負載的副本。在本章中，我們將探討 Kubernetes 中的 ReplicationController 和 ReplicaSet 這兩個重要的資源物件，並瞭解如何使用它們來實作工作負載的高用性和容錯能力。

ReplicationController 與 ReplicaSet 簡介

在 Kubernetes 中，ReplicationController 和 ReplicaSet 是用於管理和維護 Pod 副本的兩種資源物件。雖然它們的目的相似，但 ReplicaSet 是 ReplicationController 的後繼者，提供了更靈活和強大的功能。

ReplicationController

ReplicationController 的主要任務是確保指定數量的 Pod 副本正在執行且健康。如果 Pod 的數量少於指定的數量，ReplicationController 將建立新的 Pod；如果 Pod 的數量多於指定的數量，它將終止多餘的 Pod。然而，由於 ReplicationController 的功能相對有限，且已被 ReplicaSet 取代，因此在新的應用程式中，建議使用 ReplicaSet 或更高層級的抽象，如 Deployment。

ReplicaSet

ReplicaSet 是 ReplicationController 的後繼者，提供了更靈活的標籤選擇器和與其他 Kubernetes 物件（如 Deployment 和 HorizontalPodAutoscaler）的整合。ReplicaSet 的主要目的是維護一組相同的 Pod 副本，並確保它們的數量符合預期。

ReplicaSet 與 ReplicationController 的比較

特性ReplicaSetReplicationController
標籤選擇器支援根據集合的選擇器（例如，包含/排除標籤）只支援根據相等的選擇器（例如，key=value）
與其他 Kubernetes 物件的整合可作為 Deployment 和 HPA 等更高層級物件的基礎主要直接管理 Pod 複製，不具備這樣的整合
Pod 更新佈署透過 Deployment 物件進行宣告式管理，允許分階段佈署和回復需要使用已棄用的 kubectl rolling-update 命令進行手動管理
未來支援更現代化和靈活的資源，具有導向未來的功能預計將在未來被棄用

總而言之，ReplicaSet 提供了比 ReplicationController 更強大的功能和靈活性，因此在大多數情況下，建議使用 ReplicaSet。

建立 ReplicaSet 物件

要建立 ReplicaSet 物件，首先需要定義一個 YAML 清單檔案，其中包含 ReplicaSet 的規格。以下是一個範例 YAML 檔案，用於建立一個具有四個副本的 nginx Pod：

# nginx-replicaset-example.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset-example
  namespace: rs-ns
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
      environment: test
  template:
    metadata:
      labels:
        app: nginx
        environment: test
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

建立 ReplicaSet 的步驟

  1. 首先，建立一個名稱空間來存放 ReplicaSet 資源。

    $ kubectl create -f ns-rs.yaml
namespace/rs-ns created

  2. 然後，使用 kubectl apply 命令建立 ReplicaSet 物件。

    $ kubectl apply -f nginx-replicaset-example.yaml
replicaset.apps/nginx-replicaset-example created

  3. 使用 kubectl get 命令驗證 ReplicaSet 和 Pod 的狀態。

    $ kubectl get replicaset -n rs-ns
NAME                    DESIRED   CURRENT   READY   AGE
nginx-replicaset-example   4         4         4       10s

$ kubectl get pods -n rs-ns
NAME                          READY   STATUS    RESTARTS   AGE
nginx-replicaset-example-xxxxx   1/1     Running   0          10s
nginx-replicaset-example-xxxyy   1/1     Running   0          10s
nginx-replicaset-example-xxxxy   1/1     Running   0          10s
nginx-replicaset-example-xxxxz   1/1     Running   0          10s

詳細內容解密：ReplicaSet 組態解析

ReplicaSet 的組態主要包括以下幾個部分：

  • replicas：指定要維護的 Pod 副本數量。
  • selector：定義用於選擇 Pod 的標籤選擇器。ReplicaSet 將根據此選擇器來管理 Pod。
  • template：定義用於建立新 Pod 的範本，包括 Pod 的 metadata 和 spec。

透過正確組態這些欄位，可以實作對 Pod 副本的有效管理和維護，從而確保應用程式的高用性和容錯能力。