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 聯邦機制介紹