Kubernetes聯邦機制是什么

本篇內容介紹了“Kubernetes聯邦機制是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Federation（聯邦）

此頁面解釋了為什么以及如何使用聯邦來管理多個Kubernetes集群。

• Why federation

• Caveats

• Hybrid cloud capabilities

• Setting up federation

• API resources

• Cascading deletion

• Scope of a single cluster

• Selecting the right number of clusters

• What’s next

為什么聯邦

聯合可以輕松管理多個群集。 它通過提供2個主要構件來實現：

• 跨群集同步資源：聯邦可以使多個群集中的資源保持同步。 例如，可以確保多個群集中部署相同的程序。

• 跨群集發現：聯邦提供了自動配置DNS服務器和負載均衡器與所有群集后端的功能。例如，您可以確保可以使用全局VIP或DNS記錄來訪問多個群集的后端。

聯邦的一些其它用處如下：

• 高可用：通過在群集之間傳播負載并自動配置DNS服務器和負載平衡器，聯邦會將群集故障的影響降至最低。

• 避免提供者鎖定(lock-in)：通過更輕松地跨群集遷移應用程序，聯邦會阻止群集提供者鎖定(lock-in)。

除非有多個集群，否則聯邦并沒有任何用。你可能需要多個集群的一些原因有：

• 低延遲：讓多個區域中的集群通過向距離它們最近的集群提供服務來最大限度地減少延遲。

• 故障隔離：最好有多個小型集群而不是一個單獨人大型集群來進行故障隔離（例如：云提供商的不同可用區域中有多個集群）。

• 可擴展性：單個kubernetes集群具有可擴展性限制（大多數用戶不應該這樣做，更多詳情請參閱Kubernetes Scaling和Performance Goals）。

• 混合云：可以在不同的云提供商或本地數據中心上擁有多個群集。

注意事項

雖然聯邦有很多有吸引力的用處，但也有一些注意事項：

• 增加網絡帶寬和成本：聯邦控制臺監視所有群集以確保當前狀態符合預期。如果集群在云提供商或不同云提供商的不同區域(regions)運行，這可能會導致顯著的網絡成本。

• 減少跨群集隔離：聯邦控制臺中的錯誤可能影響所有群集。通過將聯邦控制臺中的邏輯保持最簡，可以緩解這一問題。 只要可能，它大部分都會委托給控制臺的kubernetes集群中。 設計和實施也在安全方面做了很多考慮，并避免發生錯誤時多集群停機。

• 成熟度：聯邦項目相對較新，不太成熟。 并非所有資源都可用，許多資源仍然是alpha狀態。 Issue 88列舉了團隊忙于解決的系統已知問題。

混合云功能

Kubernetes集群聯邦可以運行在不同云提供商（例如Google Cloud，AWS）和本地（例如OpenStack）中的集群。 Kubefed是部署聯邦集群的推薦方式。

此后，您的API資源可以跨越不同的集群和云提供商。

設置聯邦

為了能夠聯合多個集群，首先需要設置聯邦控制臺。按照設置指南進行設置。

API 資源

一旦設置了控制臺，就可以開始創建聯邦API資源。 以下指南詳細解釋了一些資源：

• Cluster

• ConfigMap

• DaemonSets

• Deployment

• Events

• Hpa

• Ingress

• Jobs

• Namespaces

• ReplicaSets

• Secrets

• Services

API參考文檔列出了聯邦apiserver支持的所有資源。

級聯刪除

Kubernetes 1.6版支持級聯刪除聯邦資源。當從聯邦控制臺中刪除資源時，還會刪除所有基礎集群中的相應資源。

在使用REST API時，級聯刪除在默認情況下不會啟用。要啟用它，請在使用REST API從聯邦控制臺中刪除資源時設置DeleteOptions.orphanDependents=false選項。 使用kubectl delete可以在默認情況下啟用級聯刪除。還可以通過運行kubectl delete --cascade=false來禁用它

注意：Kubernetes版本1.5包括對聯邦資源子集的級聯刪除支持。

單個群集的范圍

在諸如Google Compute Engine或Amazon Web Services之類的IaaS供應商中，虛擬機存在于zone 或AZ中。 我們建議Kubernetes集群中的所有虛擬機應位于相同的可用區域中，因為：

• 與具有單個全局Kubernetes集群相比，單點故障的數量更少。

• 與跨越可用區域的集群相比，更容易推斷單區域群集的可用性屬性。

• 當Kubernetes開發人員正在設計系統時（例如對延遲，帶寬或相關故障進行假設），他們假設所有機器都位于單個數據中心或連接非常近。

建議在每個可用區域運行更少的虛擬機群集; 但可以在每個可用區域運行多個群集。

選擇每個可用區域較少群集的理由是：

• 在某些情況下，在一個群集中有更多節點（更少的資源），可以改進Pod的裝箱包裝。

• 降低了運維開銷（盡管隨著操作工具和流程的成熟，優勢沒那么明顯了）。

• 降低每個集群固定資源花費的成本，例如， apiserver虛擬機（但對于大中型集群整體集群成本的比例很小）。

有多個集群的原因包括：

• 嚴格的安全策略要求將一類工作與另一類工作隔離（但請參閱下面的分區集群）

• 測試群集canary 到新Kubernetes版本或其他群集軟件。

選擇正確數量的集群

選擇Kubernetes集群的數量一般是不會變的，只是偶爾會重新審視(revisited occasionally)。 相比之下，集群中的節點數量和服務中的pod數量可能會隨著負載和業務增長頻繁變化。

要選擇集群數量，首先需要確定您需要在哪些區域(region)進行部署，以便在Kubernetes上運行的服務為所有最終用戶提供最低的延遲，（如果使用內容分發網絡，則CDN- 托管內容不需要考慮）。 法律問題也可能會對此產生影響。 例如，一家擁有全球客戶群的公司可能會決定在美國，歐盟，美聯社和南非地區擁有集群。需要使用的區域的數量為R。

其次，確定在不影響整體業務的情況下，最多可以容忍有多少個群集同時不可用。將不最多不可用集群數量設為U.如果您不確定，那么U=1是一個不錯的選擇。

如果允許負載平衡在發生集群故障時將流量引導至任何區域，則至少需要較大的R或U + 1集群。 如果不是（例如，如果要確保發生群集故障時所有用戶的延遲較低），則需要具有R *（U + 1）群集（每個R區域中的U + 1）。 無論如何，嘗試將每個集群放入不同的區域。

最后，如果需要構建一個比Kubernetes的最大建議節點數量多的集群，則可能需要多個群集。 Kubernetes v1.3支持最多1000個節點的群集。 Kubernetes v1.8支持多達5000個節點的集群。 有關更多指導，請參閱構建大型集群。

“Kubernetes聯邦機制是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！