協助改進此頁面

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

了解 Amazon EKS 中的 Amazon 應用程式復原控制器 (ARC) 區域轉移

Kubernetes 提供各種原生功能，可支援您針對運作狀態降級或可用區域 (AZ) 受損等事件，讓應用程式具備更強的復原能力。在 Amazon EKS 叢集中執行工作負載時，您可使用 Amazon 應用程式復原控制器 (ARC) 區域轉移或區域自動轉移，進一步改善應用程式環境的容錯能力與應用程式復原能力。ARC 區域轉移旨在作為一項臨時措施，讓您將資源的流量遠離受損的 AZ，直到區域轉移到期或您將它取消為止。您可在必要時擴充區域轉移。

您可針對 EKS 叢集開始區域轉移，亦可啟用區域自動轉移，讓 AWS 為您轉移流量。藉助此區域轉移，可將叢集中的東向西網路流量更新為只考慮正常運作 AZ 中工作節點上執行之 Pod 的網路端點。另外，任何 ALB 或 NLB 在處理 EKS 叢集中應用程式的輸入流量時，都會將流量路由自動至運作狀態良好的可用區域中的目標。若客戶尋求實現最高可用性目標，在可用區域受損時，能夠在復原之前將所有流量從受損的可用區域移出非常重要。因此，您亦可啟用具備 ARC 區域轉移的 ALB 或 NLB。

了解 Pod 間的東西網路流量

下面的圖表闡述了兩個範例工作負載：訂單與產品。此範例的用途是顯示不同可用區域中的工作負載與 Pod 如何通訊。

了解 Amazon EKS 中的 ARC 區域轉移

若您的環境中有可用區域受損，您可針對 EKS 叢集環境起始區域轉移。或者，您可允許 AWS 透過區域自動轉移來管理轉移的流量。藉助區域自動轉移時，AWS 可監控整個可用區域的運作狀態，以及透過將流量從叢集環境中受損的可用區域移出，來回應可能的可用區域受損。

Amazon EKS 叢集藉助 ARC 啟用區域轉移後，您可透過 ARC 主控台、AWS CLI 或區域轉移及區域自動轉移 API，來開始區域轉移或啟用區域自動轉移。EKS 區域轉移期間會自動執行以下操作：

下面的圖表提供了一個高階概觀，闡述 EKS 區域轉移如何確保叢集環境中僅鎖定運作狀態良好的 Pod 端點。

EKS 區域轉移要求

為了將區域轉移與 EKS 成功地配合使用，必須事先設定叢集環境，以便具備復原能力應對可用區域受損。下面的清單列示了可協助確保復原能力的組態選項。

跨多個可用區域佈建 EKS 工作節點

AWS 區域有多個不同的位置，包含稱為可用區域 (AZ) 實體資料中心。設置可用區域旨在彼此進行實體隔離，以避免可能同時影響整個區域。佈建 EKS 叢集後，建議您將工作節點部署至區域中的多個可用區域。此操作有助於讓叢集環境具備更強的復原能力來應對單一可用區域受損，還可確保在其他可用區域執行的應用程式具有高可用性。開始從受影響的可用區域移出時，EKS 環境的叢集內網路會自動更新，僅使用運作狀態良好的可用區域，進而有助於確保叢集具有高可用性。

確保 EKS 環境具有多可用區域設定，能夠增強系統的整體可靠性。然而，多可用區域環境會影響應用程式資料的傳輸及處理方式，進而影響環境的網路費用。具體來說，頻繁輸出跨區域流量 (在可用區域間分散的流量) 可能會對網路相關成本產生重大影響。您可運用不同的策略，來控制 EKS 叢集中 Pod 間的跨區域流量，進而降低關聯成本。若要了解如何在執行高可用性 EKS 環境時最佳化網路成本的詳細資訊，請參閱這些最佳實務。

下面的圖表闡述了三個運作狀態良好可用區域的高可用性 EKS 環境。

下面的圖表闡述三個可用區域的 EKS 環境如何具備復原能力來應對可用區域受損，以及確保高可用性，因為還有兩個運作狀態良好的可用區域。

佈建足夠的運算容量來應對單一可用區域移除

如需最佳化 EKS 資料平面中運算基礎結構的資源使用率與成本，最佳實務是使運算容量符合工作負載需求。然而，若您的所有工作節點容量已滿，則您需要在排程新的 Pod 之前，將新的工作節點新增至 EKS 資料平面。若執行關鍵工作負載，最佳實務一般是在線上使用備援容量來執行，以便處理負載突增及節點運作狀態問題等情境。若您打算使用區域轉移，需要規劃在發生受損情況時移除整個可用區域的容量。這意味著必須調整備援運算容量，即使其中一個可用區域離線，也足以處理負載。

擴展運算資源後，需要一些時間來處理將新的節點新增至 EKS 資料平面的程序。這可能會影響應用程式的即時效能與可用性，在區域受損的情況下尤其如此。EKS 環境應能在缺少一個可用區域的情況下吸收負載，而不會導致最終使用者或用戶端的體驗降級。這意味著，需要新 Pod 與在工作節點實際排程的間隔時間，需要最大限度地減少或消除延遲。

另外，若出現區域受損，您應竭力緩解在運算容量約束條件中執行的風險，以阻止將新的必要節點新增至運作狀態良好可用區域中的 EKS 資料平面。

若要實現降低這些潛在負面影響的風險，建議您在每個可用區域的某些工作節點中過度佈建運算容量。執行此操作，Kubernetes 排程器就預先有容量可用於新 Pod 置放，在環境中缺少其中一個可用區域時尤其重要。

跨可用區域執行及分佈多個 Pod 複本

Kubernetes 藉由執行單一應用程式的多個執行個體 (Pod 複本)，可讓您預先擴展您的工作負載。針對應用程式執行多個 Pod 複本，能夠消除單一故障點，以及減少單一複本上的資源壓力來提高整體效能。然而，若要讓應用程式同時具備高可用性與更佳容錯能力，建議您執行應用程式的多個複本，然後將複本分佈到不同的故障網域，亦稱為拓撲網域。此情境中的故障網域為可用區域。藉助拓撲分佈約束條件，您可設定應用程式，使其具備預先存在的靜態穩定性。之後，若可用區域受損，您的環境將會在運作狀態良好的可用區域擁有足夠的複本，以便立即處理任何流量尖峰或激增。

下面的圖表闡述了 EKS 環境，在所有可用區域運作狀態良好時，該環境具有東西向流量。

下面的圖表闡述了具有東西向流量的 EKS 環境，其中單一可用區域發生故障，並且您已開始區域轉移。

以下程式碼片段展示了如何在 Kubernetes 中利用多個複本設定工作負載的範例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 9
  selector:
    matchLabels:
      app:orders
  template:
    metadata:
      labels:
        app: orders
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: orders

最重要的是，您應執行 DNS 伺服器軟體 (CoreDNS/kube-dns) 的多個複本，若預設未設定，則應套用類似的拓撲分佈約束條件。若有單一可用區域受損，這可協助確保您在運作狀態良好的可用區域有足夠的 DNS Pod，以便繼續處理叢集中其他通訊 Pod 的服務探索請求。CoreDNS EKS 附加元件具有適用於 CoreDNS Pod 的預設設定，若多個可用區域有可用的節點，可確保這些節點將分佈到叢集的各個可用區域。您可依據意願，使用您自己的自訂組態來取代預設設定。

若您透過 Helm 安裝 CoreDNS，可更新 values.yaml 檔案中的 replicaCount，以便確保在每個可用區域有充足的複本。另外，若要確保這些複本會分佈到叢集環境的不同可用區域，請確認您更新了同一 values.yaml 檔案中的 topologySpreadConstraints 屬性。以下程式碼片段闡述了如何設定 CoreDNS 來執行此動作。

CoreDNS Helm values.yaml

replicaCount: 6
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

若可用區域受損，您可藉助適用於 CoreDNS 的自動擴展系統，來吸收 CoreDNS Pod 上增加的負載。您所需的 DNS 執行個體數目視乎叢集中執行的工作負載數目而定。CoreDNS 與 CPU 繫結，可使用水平 Pod 自動擴展器 (HPA) 依據 CPU 來進行擴展。下面展示了一個範例，您可透過修改來滿足您的需求。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

或者，EKS 可在 CoreDNS 的 EKS 附加元件版本中管理 CoreDNS 部署的自動擴展。此 CoreDNS 自動擴展器持續監控叢集狀態，包括節點數和 CPU 核心數。依據該資訊，控制器可動態調整 EKS 叢集中 CoreDNS 部署的複本數目。

如需在 CoreDNS EKS 附加元件中啟用自動擴展組態，請使用以下組態設定：

{
  "autoScaling": {
    "enabled": true
  }
}

您亦可使用 NodeLocal DNS，或是使用叢集比例自動擴展器來擴展 CoreDNS。如需詳細資訊，請參閱水平擴展 CoreDNS。

在同一可用區域設定相依的 Pod

通常，應用程式有各種工作負載，需要彼此通訊來成功完成端對端程序。若這些不同的應用程式分佈到不同的可用區域，並且未在同一可用區域進行主機代管，則單一可用區域受損可能會影響端對端程序。舉例來說，若應用程式 A 在可用區域 1 與可用區域 2 有多個複本，但應用程式 B 在可用區域 3 有其所有複本，則缺少可用區域 3 會影響兩個工作負載 (應用程式 A 與應用程式 B) 間的端對端程序。若結合拓撲分佈約束條件與 Pod 親和性，則可將 Pod 分佈到所有可用區域，藉此增強應用程式的復原能力。另外，這可設定某些 Pod 間的關係，來確保其主機代管。

藉助 Pod 親和性規則，您可定義工作負載間的關係，來影響 Kubernetes 排程器的行為，以便將 Pod 在同一工作節點或同一可用區域進行主機代管。您亦可設定排程約束條件的嚴格度。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: products
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"

    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"

下面的圖表展示了多個 Pod 藉助 Pod 親和性規則在同一節點進行主機代管。

測試叢集環境是否可應對可用區域缺失

在完成前面章節所述的要求之後，下一步是測試是否有充足的運算和工作負載容量來應對可用區域缺失。您可在 EKS 中，手動啟動區域轉移來執行此動作。或者，您可啟用區域自動轉移及設定實際執行，這亦會測試在叢集環境缺少一個可用區域的情況下，應用程式是否如預期運作。

常見問答集

這項功能有什麼用？

藉由在您的 EKS 叢集中使用 ARC 區域轉移或區域自動轉移，您可自動執行從受損的可用區域移出叢集內網路流量的快速復原程序，以便更好地確保 Kubernetes 應用程式可用性。藉助 ARC，在發生受損可用區域事件期間，您可避免可能引起延長復原時段的冗長且複雜的步驟。

此功能如何與其他 AWS 服務協同運作？

EKS 整合 ARC 可提供主要介面，以便您完成 AWS 中的復原作業。若要確保叢集內流量從受損的可用區域適當移出，EKS 會對執行於 Kubernetes 資料平面的 Pod 的網路端點清單做出修改。若您使用 Elastic Load Balancing，將外部流量路由至叢集，可在 ARC 註冊負載平衡器，然後在這些負載平衡器上開始區域轉移，來阻止流量流入降級的可用區域。此外，區域轉移還適用於 EKS 受管節點群組建立的 Amazon EC2 Auto Scaling 群組。若要阻止受損的可用區域用於新的 Kubernetes Pod 或節點啟動，EKS 會從 Auto Scaling 群組中移除受損的可用區域。

此功能與預設 Kubernetes 防護有何差異？

此功能可與若干 Kubernetes 內建防護功能配合使用，可協助客戶確保應用程式的復原能力。您可設定 Pod 整備與存活探查，來決定 Pod 應接收流量的時間。若這些探查失敗，Kubernetes 會將這些 Pod 作為服務目標進行移除，並且不再將流量傳送至 Pod。雖然這很實用，但客戶設定這些運作狀態檢查並不容易，因此若可用區域降級，需要保證這些探查會失敗。ARC 區域轉移功能提供了額外的安全網路，若 Kubernetes 的原生保護不足，它能協助您完全隔離降級的可用區域。此外，區域轉移還為您提供了一種簡便的方式，來測試架構的運作整備與復原能力。

AWS 是否能代我開始區域轉移？

是，若您需要以全自動化方式使用 ARC 區域轉移，您可啟用 ARC 區域自動轉移。藉助區域自動轉移，您可依賴於 AWS 監控 EKS 叢集的可用區域運作狀態，以及在偵測到可用區域受損時自動開始區域轉移。

若我使用此功能，並且工作節點與工作負載未預先擴展，會發生什麼？

若您未預先調整擴展，並且在區域轉移期間依賴於佈建額外的節點或 Pod，則有延遲復原的風險。新增節點至 Kubernetes 資料平面的程序需要一些時間，這可能會影響應用程式的即時效能與可用性，在區域受損時尤其如此。另外，若發生區域受損，您可能會遇到運算容量約束，這可能會阻止新的必要節點新增至運作狀態良好的可用區域。

若工作負載未預先擴展，並且分佈到叢集中的所有可用區域，對於僅執行於受影響可用區域中工作節點的應用程式，區域受損可能會影響其可用性。當工作負載在運作狀態不佳的可用區域擁有全部端點的情況下，若要緩解應用程式可用性完全中斷的風險，EKS 設置有失效安全機制，來將流量傳送至受損區域的 Pod 端點。然而，強烈建議您預先擴展應用程式，然後將其分佈到所有可用區域，以便在發生區域問題時確保可用性。

若我執行具狀態應用程式，會如何運作？

若您正在執行具狀態應用程式，必須依據您的使用案例和架構來評估其容錯能力。若您有作用中/待命架構或模式，可能會有作用中執行個體位於受損的可用區域。若在應用程式層級未啟用待命，執行時可能會遇到應用程式問題。若在運作狀態良好的可用區域啟動新的 Kubernetes Pod，可能會遇到問題，因為這些 Pod 無法連接至已繫結受損可用區域的持續性磁碟區。

此功能是否可與 Karpenter 配合使用？

EKS 中的 ARC 區域轉移與區域自動轉移目前不提供 Karpenter 支援。若可用區域受損，您可移除運作狀態不佳的可用區域，藉此來調整相關的 Karpenter NodePool 組態，以便僅在其他可用區域啟動新的工作節點。

此功能是否可與 EKS Fargate 配合使用？

此功能不與 EKS Fargate 配合使用。依預設，若 EKS Fargate 發現區域運作狀態事件，Pod 更偏好在其他可用區域執行。

EKS 受管 Kubernetes 控制平面是否會受到影響？

否，依預設，Amazon EKS 在多個可用區域內執行和擴展 Kubernetes 控制平面以確保高可用性。ARC 區域轉移與區域自動轉移僅可在 Kubernetes 資料平面運作。

此新功能是否有任何關聯成本？

您可在 EKS 叢集中使用 ARC 區域轉移與區域自動轉移，並且不會收取額外費用。但是，您會繼續支付佈建執行個體費用，強烈建議您預先擴展 Kubernetes 資料平面，再使用此功能。您應考慮在成本與應用程式可用性間達成平衡。

其他資源