學習路徑:可擴充的應用程式 - 模擬失敗

IT 管理員和營運人員可以透過這個系列的教學課程,瞭解如何部署、執行及管理 Google Kubernetes Engine (GKE) 中運作的現代化應用程式環境。在本系列教學課程中,您將瞭解如何設定監控和快訊、擴充工作負載,以及模擬失敗,所有操作都使用 Cymbal Bank 範例微服務應用程式:

  1. 建立叢集並部署範例應用程式
  2. 使用 Google Cloud Managed Service for Prometheus 進行監控
  3. 擴充工作負載
  4. 模擬失敗 (本教學課程)
  5. 集中管理變更

總覽和目標

應用程式應能容許中斷和故障。這項功能可讓使用者在發生問題時,繼續存取您的應用程式。Cymbal Bank 範例應用程式的設計宗旨是處理失敗情況並繼續執行,因此您不需要排解及修正問題。為提供這項復原能力,GKE 區域叢集會在可用區之間分配運算節點,而 Kubernetes 控制器會自動回應叢集內的服務問題。

在本教學課程中,您將瞭解如何模擬 Google Cloud 中的故障,並查看 GKE 叢集中的應用程式服務如何回應。您將瞭解如何完成下列工作:

  • 查看節點和服務的分配情形。
  • 模擬節點或區域故障。
  • 確認服務是否繼續在剩餘節點上執行。

查看節點和服務的分配情形

在 Google Cloud中,「區域」是可供您託管資源的特定地理位置。具有三個以上的可用區。舉例來說,us-central1 地區是指美國中西部地區,其中包含多個區域,例如 us-central1-aus-central1-bus-central1-c。區域會有高頻寬、低延遲的網路連線至同一地區中的其他區域。

如要部署具有高可用性的容錯應用程式,Google 建議跨多個區域和多個地區部署應用程式。這有助於防範元件發生非預期失敗,確保最多只有單一區域或地區會受到影響。

在第一個教學課程中建立 GKE 叢集時,系統會使用一些預設的設定值。根據預設,使用 Autopilot 的 GKE 叢集會建立及執行節點,這些節點會跨越您指定的區域。這種做法表示 Cymbal Bank 範例應用程式已部署到多個區域,有助於預防發生非預期失敗的情形。

  1. 檢查 GKE 叢集中的節點分布情形:

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    結果會類似下列範例輸出內容,顯示節點分散在區域中的所有三個可用區:

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
    scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. 檢查 Cymbal Bank 範例應用程式服務在 GKE 叢集節點的分布情況:

    kubectl get pods -o wide
    

    下列輸出範例顯示服務分散在叢集中的節點。從上一個步驟中檢查節點的分配方式,這個輸出內容會顯示服務在區域中的各個地帶執行:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
    frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1
    

模擬服務中斷

Google 設計的區域可將實體基礎架構中斷 (例如電力、冷卻或網路) 造成的相關故障風險降到最低。不過,仍可能發生非預期的問題。如果節點或可用區無法使用,您希望服務繼續在同一區域的其他節點或可用區中執行。

Kubernetes 控制器會監控叢集中的節點、Service 和 Deployment 狀態。如果發生非預期的服務中斷,控制器會重新啟動受影響的資源,並將流量轉送到正常運作的節點。

在本教學課程中,如要模擬中斷情形,請在其中一個區域中隔離並排空節點。這種做法可模擬節點故障或整個區域發生問題時的情況。Kubernetes 控制器應會發現部分服務已無法使用,因此必須在其他區域的節點上重新啟動:

  • 隔離並排空其中一個區域中的節點。以下範例會以 us-central1-a 中的兩個節點為目標:

    kubectl drain scalable-apps-pool-2-node1 \
        --delete-emptydir-data --ignore-daemonsets
    
    kubectl drain scalable-apps-pool-2-node2 \
        --delete-emptydir-data --ignore-daemonsets
    

    這項指令會將節點標示為無法排程,因此 Pod 無法再於這些節點上執行。Kubernetes 會將 Pod 重新排程到正常運作的可用區中。

查看模擬失敗回應

本系列的前一個教學課程中,您已瞭解如何為 GKE 叢集設定代管 Prometheus 執行個體,以監控部分服務,並在發生問題時產生快訊。如果您在模擬中斷的區域中,有 Pod 在節點上執行,就會收到 Prometheus 產生的快訊發送的 Slack 通知訊息。這個行為說明如何建構現代化應用程式環境,監控 Deployment 的健康狀態、在發生問題時發出快訊,以及自動因應負載變化或故障進行調整。

GKE 叢集會自動回應模擬中斷。受影響節點上的任何服務都會在剩餘節點上重新啟動。

  1. 再次檢查 GKE 叢集中的節點分布情況:

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    結果類似於下列範例輸出內容,顯示節點現在只分布在區域中的兩個可用區:

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. Kubernetes 控制器會發現有兩個節點無法再使用,並在可用節點之間重新分配服務。所有服務應會繼續執行。

    檢查 Cymbal Bank 範例應用程式服務在 GKE 叢集節點的分布情況:

    kubectl get pods -o wide
    

    下列輸出範例顯示,服務會分散到叢集中的其餘節點。從上一個步驟檢查節點的分配方式,這個輸出內容顯示服務現在只會在區域中的兩個地帶執行:

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
    contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
    frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1
    
  3. 查看「服務」的 AGE。在先前的輸出範例中,部分服務的年齡比 Cymbal Bank 範例應用程式中的其他服務年輕。這些較新的服務先前是在您模擬故障的其中一個節點上執行。Kubernetes 控制器已在可用節點上重新啟動這些服務。

在實際情況中,您會排解問題,或等待解決基礎維護問題。如果您已設定 Prometheus,讓系統根據快訊傳送 Slack 訊息,就會收到這些通知。您也可以選擇重複上一個教學課程中的步驟來調度資源,瞭解當區域中只有兩個可用區域時,GKE 叢集如何因應負載增加的情況。叢集應會擴充,並使用其餘兩個可用區。