選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

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

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

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

想要為此使用者指南做出貢獻? 捲動至此頁面底部,然後選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合每個人。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

想要為此使用者指南做出貢獻? 捲動至此頁面底部,然後選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合每個人。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Kubernetes 具有原生功能,可讓您的應用程式更彈性地處理事件,例如可用區域 (AZ) 的運作狀態降低或受損。在 Amazon EKS叢集中執行工作負載時,您可以使用 Amazon Application Recovery Controller 的 (ARC) 區域轉移區域自動轉移,進一步改善應用程式環境的容錯能力和應用程式復原能力。ARC區域轉移是設計為暫時性措施,可讓您將資源的流量從受損的 AZ 移出,直到區域轉移過期或您將其取消為止。如有必要,您可以延長區域轉移。

您可以為EKS叢集啟動區域轉移,也可以透過啟用區域自動轉移 AWS 來允許 為您執行。此轉移會更新叢集中的網路流量流程 east-to-west,只考慮在運作狀態良好的 工作節點上執行之 Pod 的網路端點AZs。此外,EKS叢集中應用程式的任何輸入流量ALB或NLB處理傳入流量都會自動將流量路由至運作狀態良好的 中的目標AZs。對於尋求最高可用性目標的客戶,如果 AZ 受損,則能夠將所有流量從受損的 AZ 轉向,直到復原為止,這很重要。為此,您也可以啟用具有區域轉移NLB的 ALB或 ARC

了解 Pod 之間的東西網路流量流程

下圖說明兩個範例工作負載、訂單和產品。此範例的目的是顯示工作負載和不同 Pod 的AZs通訊方式。

網路流量圖解
網路流量圖解
  1. 若要讓訂單與產品通訊,必須先解析目的地服務DNS的名稱。訂單將與 CoreDNS 通訊,以擷取該服務的虛擬 IP 地址 (叢集 IP)。一旦 Orders 解析產品服務名稱,它會將流量傳送至該目標 IP。

  2. kube-proxy 會在叢集中的每個節點上執行,並持續監控 EndpointSlices for Services。建立服務時, EndpointSlice 控制器 EndpointSlice 會在背景中建立和管理 。每個 EndpointSlice 都有端點的清單或資料表,其中包含 Pod 地址的子集,以及它們正在執行的節點。kube-proxy 會在節點iptables上使用 為這些 Pod 端點設定路由規則。kube-proxy 也負責基本形式的負載平衡,方法是將目的地為服務叢集 IP 的流量重新導向至 ,而不是直接傳送至 Pod 的 IP 地址。kube-proxy 透過在傳出連線上重寫目的地 IP 來執行此操作。

  3. 然後,網路封包會透過個別節點ENIs上的 (如上圖所示) 傳送至 AZ 2 中的產品 Pod。

了解 中的ARC區域轉移 EKS

如果您的環境中有 AZ 受損,您可以為您的EKS叢集環境啟動區域轉移。或者,您可以允許 使用區域自動轉移來管理此 AWS 項目。使用區域自動轉移時, AWS 會監控整體 AZ 運作狀態,並透過自動將流量從叢集環境中受損的 AZ 轉移來回應潛在的 AZ 損害。

叢集區域轉移啟用 後ARC,您可以使用ARC主控台、 EKS 或區域轉移和區域自動轉移 來觸發區域轉移 AWS CLI或啟用區域自動轉移APIs。EKS 在區域轉移期間,會自動執行下列動作:

  • 受影響的 AZ 中的所有節點都會進行封鎖。這將防止 Kubernetes Scheduler 將新的 Pod 排程到運作狀態不佳的 AZ 中的節點。

  • 如果您使用的是受管節點群組則可用區域重新平衡將暫停,而且您的 Auto Scaling 群組 (ASG) 將更新,以確保新的 EKS Data Plane 節點僅在運作狀態良好的 中啟動AZs。

  • 運作狀態不佳的 AZ 中的節點不會終止,也不會從這些節點移出 Pod。這是為了確保當區域轉移過期或取消時,您的流量可以安全地傳回至仍具有完整容量的 AZ

  • EndpointSlice 控制器會在受損的 AZ 中找到所有 Pod 端點,並從相關的 中移除它們 EndpointSlices。這將確保只有運作狀態良好的 Pod 端點AZs才能接收網路流量。當區域轉移取消或過期時, EndpointSlice 控制器會更新 EndpointSlices ,以將端點包含在還原的 AZ 中。

下圖描述EKS區域轉移如何確保叢集環境中只有運作狀態良好的 Pod 端點成為目標的高層級流程。

網路流量圖解
網路流量圖解

EKS 區域輪班要求

若要讓區域轉移在 中成功運作EKS,您需要事先設定叢集環境,以應對 AZ 損害。以下是您必須遵循的步驟清單。

  • 跨多個 佈建叢集的工作者節點 AZs

  • 提供足夠的運算容量,以承受移除單一可用區域

  • 在每個 AZ 中預先擴展您的 Pod (包括 CoreDNS)

  • 將多個 Pod 複本分散到所有區域,AZs以確保從單一 AZ 轉移將讓您擁有足夠的容量

  • 在相同的 AZ 中共同放置相互依存或相關 Pod

  • 手動啟動區域轉移,以測試叢集環境在較少可用區域上是否如預期般運作。或者,您可以啟用區域自動轉移並在自動轉移實務執行時回覆。這並非區域轉移運作的必要條件,EKS但強烈建議這麼做。

跨多個佈建EKS您的工作者節點 AZs

AWS 區域具有多個不同的位置,其實體資料中心稱為可用區域 (AZs)。 AZs 旨在彼此實體隔離,以避免可能影響整個區域的同時影響。佈建EKS叢集時,您應該AZs在區域中的多個 之間部署工作者節點。這將使您的叢集環境對單一 AZ 的損害更具彈性,並允許您維護在其他 中執行之應用程式的高可用性 (HA)AZs。當您開始從受影響的可用區域轉移區域時,您EKS環境的叢集內網路會自動更新為僅使用運作狀態良好的 AZs,同時為您的叢集維持高度可用的狀態。

確保您擁有這種適用於您EKS環境的多可用區域設定,可增強系統的整體可靠性。不過,多可用區域環境在傳輸和處理應用程式資料的方式上扮演重要角色,這反過來將影響您環境的網路費用。特別是,頻繁的輸出跨區域流量 (在 之間分佈流量AZs) 可能會對您的網路相關成本產生重大影響。您可以套用不同的策略來控制EKS叢集中 Pod 之間的跨區域流量,並降低相關聯的成本。如需如何在執行高可用性EKS環境時最佳化網路成本的詳細資訊,請參閱此最佳實務指南

下圖描述具有 3 個運作狀態良好的高可用性EKS環境AZs。

網路圖解

下圖說明具有 3 EKS的環境如何對 AZ 損害具有AZs彈性,並由於其他 2 個運作狀態良好的 而保持高度可用性AZs。

網路圖解

佈建足夠的運算容量,以停止移除單一 AZ

若要最佳化 EKS Data Plane 中運算基礎設施的資源使用率和成本,最佳實務是將運算容量與您的工作負載需求保持一致。不過,如果您的所有工作者節點都已滿容量,則這可讓您依賴將新的工作者節點新增至 EKS Data Plane,然後才能排程新的 Pod。執行關鍵工作負載時,通常最好使用備援容量線上執行,來處理負載突然增加、節點運作狀態問題等事件。如果您計劃使用區域轉移,則計劃移除整個 AZ 容量,因此您需要調整備援運算容量,以便即使 AZ 離線也能處理負載。

擴展運算時,將新節點新增至EKS資料平面的程序需要一些時間,這可能會影響應用程式的即時效能和可用性,特別是在區域受損的情況下。您的EKS環境應該具有彈性,可吸收遺失 AZ 的負載,以避免最終使用者或用戶端體驗下降。這表示在需要新 Pod 的時間,以及實際排程在工作者節點的時間之間,盡可能減少或消除任何延遲。

此外,如果發生區域性損害,您應該降低潛在運算容量限制的風險,這將防止在運作狀態良好的 中將新所需的節點新增至EKS您的資料平面AZs。

若要達成此目的,您應該在每個 中的某些工作者節點中過度佈建運算容量,AZs以便 Kubernetes Scheduler 具有可用於新 Pod 置放的預先存在容量,特別是當您的環境中有一個較少的可用區域時。

執行並分散多個 Pod 複本 AZs

Kubernetes 可讓您透過執行單一應用程式的多個執行個體 (Pod 複本) 來預先擴展工作負載。為應用程式執行多個 Pod 複本可消除單一故障點,並透過減少單一複本上的資源負擔來提高其整體效能。不過,為了讓您的應用程式同時具有高可用性和更好的容錯能力,您應該在不同的故障網域 (也稱為拓撲網域) 中執行和分散應用程式的多個複本,在此案例中為 AZs。透過拓撲分散限制,您可以將應用程式設定為具有預先存在的靜態穩定性,以便在 AZ 受損的情況下,您會在運作狀態良好時擁有足夠的複本AZs,以立即處理他們可能遇到的任何額外尖峰或激增流量。

下圖說明當所有 AZs都正常運作時,流量 east-to-west流程EKS的環境。

網路圖解

下圖說明單一 AZ 失敗且您啟動區域轉移時,具有 east-to-west流量流程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 PodAZs,以便在發生單一可用區域受損時,繼續處理叢集中其他通訊 Pod 的服務探索請求。如果多個AZs可用節點,則 CoreDNS EKS 附加元件具有預設設定,可讓 CoreDNS Pod 分散到叢集的可用區域。您也可以將這些預設設定取代為您自己的自訂組態。

使用 Helm 安裝 CoreDNS 時,您可以更新 value.yaml 檔案中replicaCount的 ,以確保您在每個 AZ 中有足夠的複本數量。此外,為了確保這些複本在您的AZs叢集環境中分散到不同的 ,您應該更新相同 value.yaml 檔案中的 topologySpreadConstraints 屬性。以下程式碼片段示範如何為此設定 CoreDNS。

核心DNS Helm values.yaml

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

如果 AZ 受損,您可以使用適用於 CoreDNS 的自動擴展系統來吸收 Core Pod 上增加的負載DNS。您需要的DNS執行個體數目取決於叢集中執行的工作負載數目。核心DNS已CPU繫結,允許它根據CPU使用水平 Pod Autoscaler (HPA) 進行擴展。以下是您可以修改以滿足您的需求的範例。

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可以在 核心DNS的EKS附加元件版本中管理核心部署的自動擴展DNS。此核心DNS自動擴展器會持續監控叢集狀態,包括節點和CPU核心的數量。根據該資訊,控制器將動態調整EKS叢集中核心DNS部署的複本數量。

若要在核心DNSEKS附加元件中啟用自動調整規模組態,您應該新增下列選用的組態設定:

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

您也可以使用 NodeLocal DNS叢集比例自動擴展器來擴展核心DNS。您可以在此處進一步閱讀水平擴展核心DNS

在相同 AZ 中配置相互依存 Pod

在大多數情況下,您可能正在執行不同的工作負載,這些工作負載必須彼此通訊,才能成功執行程序 end-to-end。如果不同的應用程式分散到不同的 ,AZs但沒有共置在相同的 AZ 中,則單一 AZ 受損可能會影響基礎 end-to-end程序。例如,如果應用程式 A 在 AZ 1 和 AZ 2 中有多個複本,但應用程式 B 在 AZ 3 中有其所有複本,則 AZ 3 的遺失將影響這兩個工作負載 (應用程式 A 和 B) 之間的任何 end-to-end程序。將拓撲分散限制與 Pod 親和性結合,可以透過將 Pod 分散到所有 ,以及設定特定 Pod 之間的關係,以確保它們共置在一起AZs,來增強應用程式的彈性。

使用 Pod 親和性規則,您可以定義工作負載之間的關係,以影響 Kubernetes 排程器的行為,使其將 Pod 共同放置在相同的工作者節點或相同的 AZ 中。您也可以設定這些排程限制的嚴格程度。

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。

網路圖解

測試您的叢集環境是否可以處理 AZ 遺失

完成上述要求後,下一個重要的步驟是測試您是否有足夠的運算和工作負載容量來處理 AZ 遺失。您可以在 中手動觸發區域轉移,以執行此操作EKS。或者,您可以啟用區域自動轉移,並設定實務執行,以測試您的應用程式在叢集環境中的可用區域是否如預期運作。

常見問答集

為什麼我應該使用此功能?

透過在EKS叢集中使用ARC區域轉移或區域自動轉移,您可以自動化從受損的 AZ 轉移叢集內網路流量的快速復原程序,以更好地維持 Kubernetes 應用程式可用性。使用 ARC,您可以避免長時間且複雜的步驟,這些步驟通常會導致在 AZ 事件受損期間延長復原期。

此功能如何與其他 AWS 服務搭配使用?

EKS 與 整合ARC,提供主要界面供您完成復原操作 AWS。為了確保叢集內流量適當路由離開受損的 AZ,會修改在 Kubernetes 資料平面中執行之 Pod 的網路端點清單。如果您使用 AWS 負載平衡器將外部流量路由到叢集,則您已經向 註冊負載平衡器,ARC並在它們上觸發區域轉移,以防止流量流入降級的區域。此功能也會與 EKS Managed Node Groups (ASG) 建立的 Amazon EC2 Auto Scaling Groups () 互動MNG。為了防止受損的 AZ 用於新的 Kubernetes Pod 或節點啟動, 會從 EKS中移除受損的 AZASG。

此功能與預設 Kubernetes 保護有何不同?

此功能可搭配多種 Kubernetes 原生內建保護,協助客戶保持彈性。您可以設定 Pod 整備和即時探查,以決定 Pod 何時應接收流量。當這些探查失敗時,Kubernetes 會將這些 Pod 移除為服務的目標,且流量不會再傳送至 Pod。雖然這很實用,但客戶設定這些運作狀態檢查並保證在區域降級時失敗並不顯眼。當 ARC Kubernetes 的原生保護尚未足夠時,區域轉移功能可為您提供額外的安全網,協助它們完全隔離降級的 AZ。它也提供簡單的方法來測試架構的操作準備度和彈性。

可以代表我 AWS 觸發區域轉移嗎?

是,如果您想要使用ARC區域轉移的全自動方式,您可以啟用ARC區域自動轉移。透過區域自動轉移,您可以依賴 AWS 來監控AZsEKS叢集的運作狀態,並在偵測到 AZ 受損時自動觸發轉移。

如果我使用此功能,而且我的工作者節點和工作負載未預先擴展,會發生什麼情況?

如果您未預先調整規模,並依賴於在區域轉移期間佈建其他節點或 Pod,則會有延遲復原的風險。將新節點新增至 Kubernetes 資料平面的程序需要一些時間,這可能會影響應用程式的即時效能和可用性,特別是在區域受損的情況下。此外,在區域受損的情況下,您可能會遇到潛在的運算容量限制,這可能會阻止新所需的節點新增至運作狀態良好的 AZs。

如果您的工作負載未預先擴展並分散到叢集AZs中的所有 ,則區域性損害可能會影響僅在受影響 AZ 中的工作者節點上執行的應用程式可用性。為了降低應用程式完全中斷可用性的風險,如果工作負載在運作狀態不佳的 AZ 中擁有其所有端點, 就會EKS無法安全地將流量傳送至受損區域中的 Pod 端點。不過,強烈建議您偏好預先擴展並分散應用程式至所有區域AZs,以便在發生區域問題時維持可用性。

如果我執行具狀態的應用程式,會發生什麼情況?

如果您正在執行具狀態的應用程式,您將需要根據使用案例和架構來評估其容錯能力。如果您有作用中/待命架構或模式,則可能會有作用中位於受損 AZ 的執行個體。在應用程式層級,如果未啟用待命,您可能會遇到應用程式的問題。當新的 Kubernetes Pod 在運作狀態良好時,您可能會遇到問題,AZs因為它們無法連接至繫結至受損 AZ 的持久性磁碟區。

此功能是否適用於 Karpenter?

Karpenter 支援目前不適用於 ARC 中的區域轉移和區域自動轉移EKS。如果 AZ 受損,您可以透過移除運作狀態不佳的 AZ 來調整相關的 Karpenter NodePool 組態,以便僅在運作狀態良好的 中啟動新的工作者節點AZs。

此功能是否適用於 EKS Fargate?

此功能不適用於 EKS Fargate。根據預設,當 EKS Fargate 辨識區域運作狀態事件時,Pod 會偏好在其他 中執行AZs。

受EKS管 Kubernetes 控制平面會受到影響嗎?

否,根據預設,Amazon 會EKS執行 Kubernetes 控制平面並將其擴展到多個 AZs,以確保高可用性。ARC區域轉移和區域自動轉移只會在 Kubernetes 資料平面上作用。

此新功能是否有任何相關成本?

您可以在EKS叢集中使用ARC區域轉移和區域自動轉移,無需額外費用。不過,您將繼續支付佈建執行個體的費用,強烈建議您在使用此功能之前預先擴展 Kubernetes 資料平面。您應該考慮成本和應用程式可用性之間的適當平衡。

其他資源

📝 在 上編輯此頁面 GitHub

下一個主題:

啟用區域轉移

上一個主題:

自動擴展
隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。