集群聯邦 · kubernetes完整攻略

# 集群聯邦 Kubernetes v1.9聲稱單集群最多可支持5000個節點和15萬個Pod，我相信很少有公司會部署如此龐大的一個單集群，總有很多情況下因為各種各樣的原因我們可能會部署多個集群，但是有時候有想將他們統一起來管理，這時候就需要用到集群聯邦（Federation）。 ## 為什么要使用 federation Federation 使管理多個集群變得簡單。它通過提供兩個主要構建模塊來實現： - 跨集群同步資源：Federation 提供了在多個集群中保持資源同步的能力。例如，可以保證同一個 deployment 在多個集群中存在。 - 跨集群服務發現：Federation 提供了自動配置 DNS 服務以及在所有集群后端上進行負載均衡的能力。例如，可以提供一個全局 VIP 或者 DNS 記錄，通過它可以訪問多個集群后端。 Federation 還可以提供一些其它用例： - 高可用：通過在集群間分布負載并自動配置 DNS 服務和負載均衡，federation 最大限度地減少集群故障的影響。 - 避免廠商鎖定：通過更簡單的跨集群應用遷移方式，federation 可以防止集群廠商鎖定。 Federation 對于單個集群沒有用處。基于下面這些原因您可能會需要多個集群： - 低延遲：通過在多個區域部署集群可以最大限度減少區域近端用戶的延遲。 - 故障隔離：擁有多個小集群可能比單個大集群更利于故障隔離（例如：在云服務提供商的不同可用區中的多個集群）。詳情請參考 [多集群指南](https://kubernetes.io/docs/concepts/cluster-administration/federation)。 - 可伸縮性：單個集群有可伸縮性限制（對于大多數用戶這不是典型場景。更多細節請參考 [Kubernetes 彈性伸縮與性能目標](https://git.k8s.io/community/sig-scalability/goals.md)）。 - [混合云](https://kubernetes.io/docs/concepts/cluster-administration/federation/)：您可以在不同的云服務提供商或本地數據中心中擁有多個集群。 ### 警告雖然 federation 有很多吸引人的使用案例，但也有一些注意事項： - 增加網絡帶寬和成本：federation 控制平面監控所有集群以確保當前狀態符合預期。如果集群在云服務提供商的不同區域或者不同的云服務提供商上運行時，這將導致明顯的網絡成本增加。 - 減少跨集群隔離：federation 控制平面中的 bug 可能影響所有集群。通過在 federation 中實現最少的邏輯可以緩解這種情況。只要有可能，它就將盡力把工作委托給 kubernetes 集群中的控制平面。這種設計和實現在安全性及避免多集群停止運行上也是錯誤的。 - 成熟度：federation 項目相對比較新，還不是很成熟。并不是所有資源都可用，許多仍然處于 alpha 狀態。 [Issue 88](https://github.com/kubernetes/kubernetes/issues/88) 列舉了團隊目前正忙于解決的與系統相關的已知問題。 ### 混合云能力 Kubernetes 集群 federation 可以包含運行在不同云服務提供商（例如 Google Cloud、AWS）及本地（例如在 OpenStack 上）的集群。您只需要按需在適合的云服務提供商和/或地點上簡單的創建集群，然后向 Federation API Server 注冊每個集群的 API endpoint 和憑據即可。此后，您的 [API 資源](https://kubernetes.io/docs/concepts/cluster-administration/federation/) 就可以跨越不同的集群和云服務提供商。 ## 設置 federation 為了能夠聯合（federate）多個集群，首先需要建立一個 federation 控制平面。請按照 [設置指南](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed) 設置 federation 控制平面。 ## API 資源一旦設置了控制平面，您就可以開始創建 federation API 資源。以下指南詳細介紹了一些資源： - [Cluster](https://kubernetes.io/docs/tasks/administer-federation/cluster) - [ConfigMap](https://kubernetes.io/docs/tasks/administer-federation/configmap) - [DaemonSets](https://kubernetes.io/docs/tasks/administer-federation/daemonset) - [Deployment](https://kubernetes.io/docs/tasks/administer-federation/deployment) - [Events](https://kubernetes.io/docs/tasks/administer-federation/events) - [Hpa](https://kubernetes.io/docs/tasks/administer-federation/hpa) - [Ingress](https://kubernetes.io/docs/tasks/administer-federation/ingress) - [Jobs](https://kubernetes.io/docs/tasks/administer-federation/job) - [Namespaces](https://kubernetes.io/docs/tasks/administer-federation/namespaces) - [ReplicaSets](https://kubernetes.io/docs/tasks/administer-federation/replicaset) - [Secrets](https://kubernetes.io/docs/tasks/administer-federation/secret) - [Services](https://kubernetes.io/docs/concepts/cluster-administration/federation-service-discovery) [API 參考文檔](https://kubernetes.io/docs/reference/federation) 列舉了 federation apiserver 支持的所有資源。 ## 級聯刪除 Kubernetes 1.6 版本包括了對聯邦資源（federated resources）級聯刪除的支持。通過級聯刪除，當您從 federation 控制平面刪除一個資源時，會同時刪除所有底層集群中對應的資源。當使用 REST API 時，級聯刪除沒有默認開啟。要想在使用 REST API 從 federation 控制平面刪除資源時啟用級聯刪除，請設置 `DeleteOptions.orphanDependents=false` 選項。使用 `kubectl delete` 時默認使用級聯刪除。您可以通過運行 `kubectl delete --cascade=false` 來禁用該功能。注意：Kubernetes 1.5 版本支持的級聯刪除僅支持部分 federation 資源。 ## 單個集群范圍在諸如 Google Compute Engine 或者 Amazon Web Services 等 IaaS 服務提供商中，虛擬機存在于 [區域](https://cloud.google.com/compute/docs/zones) 或 [可用區](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) 上。我們建議 Kubernetes 集群中的所有虛擬機應該位于相同的可用區，因為： - 與擁有單個全局 Kubernetes 集群相比，單點故障更少。 - 與跨可用區集群相比，推測單區域集群的可用性屬性更容易。 - 當 Kubernetes 開發人員設計系統時（例如對延遲，帶寬或相關故障進行假設），它們假設所有的機器都在一個單一的數據中心，或以其它方式緊密連接。在每個可用區域同時擁有多個集群也是可以的，但總體而言，我們認為少一點更好。選擇較少集群的理由是： - 某些情況下，在一個集群中擁有更多的節點可以改進 Pod 的裝箱打包（較少資源碎片）。 - 減少運維開銷（盡管隨著運維工具和流程的成熟，優勢已經減少）。 - 減少每個集群固定資源成本的開銷，例如 apiserver 虛擬機（但對于大中型集群的整體集群成本來說百分比很小）。擁有多個集群的原因包括： - 嚴格的安全策略要求將一類工作與另一類工作隔離開來（但是，請參見下面的分區集群（Partitioning Clusters））。 - 對新的 Kubernetes 發行版或其它集群軟件進行灰度測試。 ## 選擇正確的集群數量 Kubernetes 集群數量的選擇可能是一個相對靜態的選擇，只是偶爾重新設置。相比之下，依據負載情況和增長，集群的節點數量和 service 的 pod 數量可能會經常變化。要選擇集群的數量，首先要確定使用哪些區域，以便為所有終端用戶提供足夠低的延遲，以在 Kubernetes 上運行服務（如果您使用內容分發網絡（Content Distribution Network，CDN），則 CDN 托管內容的時延要求不需要考慮）。法律問題也可能影響到這一點。例如，擁有全球客戶群的公司可能會決定在美國、歐盟、亞太和南亞地區擁有集群。我們將選擇的區域數量稱為 `R`。其次，決定在整體仍然可用的前提下，可以同時有多少集群不可用。將不可用集群的數量稱為 `U`。如果您不能確定，那么 1 是一個不錯的選擇。如果在集群故障的情形下允許負載均衡將流量引導到任何區域，則至少需要有比 `R` 或 `U + 1` 數量更大的集群。如果不行的話（例如希望在集群發生故障時對所有用戶確保低延遲），那么您需要有數量為 `R * (U + 1)` 的集群（`R` 個區域，每個中有 `U + 1` 個集群）。無論如何，請嘗試將每個集群放在不同的區域中。最后，如果您的任何集群需要比 Kubernetes 集群最大建議節點數更多的節點，那么您可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 個節點的集群。 Kubernetes v1.8 支持最多 5000 個節點的集群。 --- 原文地址：https://kubernetes.io/docs/concepts/cluster-administration/federation/ 譯文地址：https://k8smeetup.github.io/docs/concepts/cluster-administration/federation/