「容器云架構」K8s 多區(qū)域部署
背景
Kubernetes的設計使得單個Kubernetes集群可以跨多個故障區(qū)域multiple failure zones運行,通常這些區(qū)域(zones )位于稱為區(qū)域(region)的邏輯分組中。主要的云提供商將一個區(qū)域定義為一組故障區(qū)域 failure zones(也稱為可用性區(qū)域availability zones),這些區(qū)域提供一組一致的功能:在一個區(qū)域內,每個區(qū)域提供相同的api和服務。
典型的云架構旨在將一個區(qū)域中的故障同時損害另一個區(qū)域中的服務的可能性降至最低。
控制平面行為
所有控制平面組件都支持作為一個可交換資源池運行,每個組件復制一個。
部署群集控制平面時,請跨多個故障區(qū)域放置控制平面組件的副本。如果可用性是一個重要問題,請選擇至少三個故障區(qū)域,并跨至少三個故障區(qū)域復制每個單獨的控制平面組件(API服務器、調度器、etcd、群集控制器管理器)。如果您正在運行一個云控制器管理器,那么您還應該在您選擇的所有故障區(qū)域中復制它。
注意:Kubernetes不為API服務器端點提供跨區(qū)域彈性。您可以使用各種技術來提高集群API服務器的可用性,包括DNS循環(huán)、SRV記錄或具有運行狀況檢查的第三方負載平衡解決方案。
節(jié)點行為
Kubernetes自動將工作負載資源(如部署或狀態(tài)集)的pod分布在集群中的不同節(jié)點上。這種傳播有助于減少失敗的影響。
當節(jié)點啟動時,每個節(jié)點上的kubelet會自動向節(jié)點對象添加標簽,該對象在kubernetesapi中表示特定的kubelet。這些標簽可以包含區(qū)域信息。
如果集群跨越多個區(qū)域或區(qū)域,則可以將節(jié)點標簽與Pod拓撲擴展約束結合使用,以控制Pod如何在容錯域(區(qū)域、區(qū)域甚至特定節(jié)點)之間跨集群擴展。這些提示使調度器能夠放置pod以獲得更好的預期可用性,從而降低相關故障影響整個工作負載的風險。
例如,您可以設置一個約束,以確保StatefulSet的3個副本都彼此在不同的區(qū)域中運行,只要這是可行的。您可以聲明性地定義它,而無需顯式地定義每個工作負載使用的可用性區(qū)域。
跨區(qū)域(Zone)分布節(jié)點
Kubernetes的核心并不為您創(chuàng)建節(jié)點;您需要自己創(chuàng)建節(jié)點,或者使用集群API之類的工具代表您管理節(jié)點。
使用諸如clusterapi之類的工具,您可以定義作為集群的工作節(jié)點跨多個故障域運行的計算機集,以及在整個區(qū)域服務中斷時自動修復集群的規(guī)則。
Pods的手動區(qū)域分配
可以將節(jié)點選擇器約束應用于創(chuàng)建的Pod,以及工作負載資源(如部署、狀態(tài)集或作業(yè))中的Pod模板。
區(qū)域(zone)的存儲訪問
創(chuàng)建持久卷時,PersistentVolumeLabel許可控制器會自動向鏈接到特定區(qū)域的任何持久卷添加區(qū)域標簽。然后,調度器通過其NoVolumeZoneConflict謂詞確保聲明給定PersistentVolume的pod只放置在與該卷相同的區(qū)域中。
您可以為PersistentVolumeClaimes指定一個StorageClass,它指定該類中的存儲可能使用的故障域(區(qū)域)。要了解如何配置可識別故障域或區(qū)域的StorageClass,請參閱允許的拓撲。
網(wǎng)絡
Kubernetes本身并不包括區(qū)域感知網(wǎng)絡。您可以使用網(wǎng)絡插件來配置集群網(wǎng)絡,并且該網(wǎng)絡解決方案可能具有特定于區(qū)域的元素。例如,如果您的云提供商支持type=LoadBalancer的服務,那么負載平衡器可能只向運行在與處理給定連接的負載平衡器元素所在的同一區(qū)域中的pod發(fā)送流量。有關詳細信息,請查看云提供商的文檔。
對于自定義或內部部署,也需要考慮類似的問題。服務和入口行為(包括對不同故障區(qū)域的處理)確實有所不同,具體取決于集群的設置方式。
故障恢復
在設置集群時,您可能還需要考慮,如果某個區(qū)域中的所有故障區(qū)域同時脫機,安裝程序是否以及如何恢復服務。例如,您是否依賴于一個區(qū)域中至少有一個節(jié)點能夠運行Pods?
確保任何群集關鍵修復工作都不依賴于群集中至少有一個正常節(jié)點。例如:如果所有節(jié)點都不正常,則可能需要運行具有特殊容差的修復作業(yè),以便修復可以完成到足以使至少一個節(jié)點投入服務的程度。
Kubernetes并沒有回答這個挑戰(zhàn),但是,這是值得考慮的問題。