本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes Federation 演進

作者：Irfan Ur Rehman (Huawei), Paul Morie (RedHat), Shashidhara T D (Huawei) |

Kubernetes 為將應用程式部署到叢集提供了出色的基本元件：它可以像 kubectl create -f app.yaml 一樣簡單。跨多個叢集部署應用程式從未如此簡單。應用程式工作負載應如何分發？應用程式資源應複製到所有叢集、複製到選定的叢集，還是分割到叢集？如何管理對叢集的存取？如果使用者想要分發的某些資源以某種形式預先存在於某些或所有叢集中，會發生什麼情況？

在 SIG Multicluster 中，我們的旅程揭示了有多種可能的模型可以解決這些問題，並且可能沒有單一的最佳解決方案來適用所有情境。Kubernetes 叢集聯邦 (簡稱 KubeFed)，然而，是 Kubernetes 最大的開源子專案，並且在這個問題領域中看到了社群最大的興趣和貢獻。該專案最初重用了 Kubernetes API，以消除現有 Kubernetes 使用者的任何額外使用複雜性。由於以下總結的問題，這種方法不可行

  • 在叢集層級重新實作 Kubernetes API 的困難，因為聯邦特定的擴展儲存在註釋中。
  • 由於 1:1 模擬 Kubernetes API，因此在聯邦類型、放置和協調方面的靈活性有限。
  • 沒有確定的 GA 路徑，以及關於 API 成熟度的一般混淆；例如，Deployments 在 Kubernetes 中是 GA，但在 Federation v1 中甚至不是 Beta。

這些想法隨著聯邦特定的 API 架構和社群努力而進一步發展，現在以 Federation v2 的形式繼續進行。

概念概述

由於聯邦嘗試解決一組複雜的問題，因此將這些問題的不同部分分解開來是有益的。讓我們看看所涉及的不同高階領域

Kubernetes Federation v2 Concepts

Kubernetes Federation v2 概念

聯邦任意資源

聯邦的主要目標之一是能夠定義 API 和 API 群組，其中包含聯邦任何給定 Kubernetes 資源所需的基本原則。這至關重要，因為 CustomResourceDefinitions 作為使用新 API 擴展 Kubernetes 的方式非常受歡迎。

工作組達成了聯邦 API 和 API 群組的通用定義，即「一種將“正常” Kubernetes API 資源分發到不同叢集的機制」。最簡單形式的分發可以想像為簡單傳播此「正常 Kubernetes API 資源」跨聯邦叢集。有思想的讀者當然可以辨別出比這種 Kubernetes 資源的簡單傳播更複雜的機制。

在定義聯邦 API 的建構區塊的過程中，近期目標之一也演變為「能夠建立一個簡單的聯邦，又名任何 Kubernetes 資源或 CRD 的簡單傳播，幾乎不需編寫任何程式碼」。隨後出現的是一個核心 API 群組，為每個給定的 Kubernetes 資源定義了作為 Template 資源、Placement 資源和 Override 資源的建構區塊，一個 TypeConfig 來指定給定資源的同步或不同步，以及相關的控制器來執行同步。更多詳細資訊請參閱下一節。後續章節也將討論能夠遵循分層行為，更高階的聯邦 API 消費這些核心建構區塊的行為，以及使用者能夠消費 API 和相關控制器的全部或部分。最後，此架構也允許使用者編寫額外的控制器或用他們自己的控制器替換可用的參考控制器，以執行所需的行為。

「輕鬆聯邦任意 Kubernetes 資源」的能力，以及解耦的 API，分為建構區塊 API、更高階 API 和可能的使用者意圖類型，以這樣的方式呈現，不同的使用者可以消費部分並編寫控制器，組成特定於他們的解決方案，這為 Federation v2 提供了一個引人注目的理由。

聯邦資源：詳細資訊

從根本上說，聯邦必須配置兩種資訊類型

  • 聯邦應處理哪些 API 類型
  • 聯邦應以哪些叢集為目標來分發這些資源。

對於聯邦處理的每個 API 類型，宣告狀態的不同部分都存在於不同的 API 資源中

  • Template 類型保存資源的基本規格 - 例如，名為 FederatedReplicaSet 的類型保存應分發到目標叢集的 ReplicaSet 的基本規格
  • Placement 類型保存資源應分發到的叢集的規格 - 例如，名為 FederatedReplicaSetPlacement 的類型保存有關 FederatedReplicaSets 應分發到哪些叢集的資訊
  • 可選的 Overrides 類型保存 Template 資源應如何在某些叢集中變化的規格 - 例如，名為 FederatedReplicaSetOverrides 的類型保存有關 FederatedReplicaSet 應如何在某些叢集中變化的資訊。

這些類型都按名稱關聯 - 這表示對於名稱為 foo 的特定 Template 資源，該資源的 Placement 和 Override 資訊包含在名稱為 foo 且與 Template 位於相同命名空間的 Override 和 Placement 資源中。

更高階行為

v2 API 的架構允許使用核心 API 類型 (Template、Placement 和 Override) 以及相關控制器，為給定資源建構更高階的 API。在社群中，我們發現了一些使用案例，並實作了適用於這些案例的更高階 API 和相關控制器。進一步章節中描述的其中一些類型也為任何有興趣解決更複雜的使用案例、基於 v2 API 已提供的機制之上建構的人提供了有用的參考。

ReplicaSchedulingPreference

ReplicaSchedulingPreference 提供了一種自動化機制，用於將基於 Deployment 或 ReplicaSet 的聯邦工作負載的副本總數分發和維護到聯邦叢集中。這是基於使用者給出的高階使用者偏好設定。這些偏好設定包括加權分發和限制（最小和最大值）的語義，用於分發副本。這些還包括允許動態重新分發副本的語義，以防某些副本 Pod 在某些叢集中保持未調度狀態，例如由於該叢集中的資源不足。更多詳細資訊可以在 ReplicaSchedulingPreferences 的使用者指南中找到。

聯邦服務 & 跨叢集服務發現

Kubernetes 服務在建構微服務架構中非常有用。顯然希望跨叢集、區域、地區和雲端邊界部署服務。跨越叢集的服務提供地理分佈、實現混合雲和多雲情境，並提高超出單一叢集部署的高可用性水準。希望其服務跨越一個或多個（可能是遠端）叢集的客戶，需要它們從叢集內部和外部以一致的方式可訪問。

聯邦 Service 的核心包含一個 Template (Kubernetes 服務的定義)、一個 Placement (要部署到的叢集)、一個 Override (特定叢集中的可選變更) 和一個 ServiceDNSRecord (指定如何發現它的詳細資訊)。

注意：聯邦服務必須是 LoadBalancer 類型，才能跨叢集被發現。

從聯邦叢集內的 Pod 發現聯邦服務

預設情況下，Kubernetes 叢集預先配置了叢集本機 DNS 伺服器，以及智慧建構的 DNS 搜尋路徑，它們共同確保由 Pod 內部執行的軟體發出的 DNS 查詢，例如 myservice、myservice.mynamespace 或 some-other-service.other-namespace，會自動擴展並正確解析為在本機叢集中執行的服務的適當 IP。

隨著聯邦服務和跨叢集服務發現的引入，這個概念被擴展到涵蓋在全球叢集聯邦中任何其他叢集中執行的 Kubernetes 服務。為了利用這種擴展範圍，您使用略有不同的 DNS 名稱 (例如 myservice.mynamespace.myfederation) 來解析聯邦服務。使用不同的 DNS 名稱也避免了您現有的應用程式意外地遍歷跨區域或跨地區網路，並且您可能在沒有明確選擇加入此行為的情況下產生不必要的網路費用或延遲。

讓我們考慮一個範例，使用名為 nginx 的服務。

位於 us-central1-a 可用區叢集中的 Pod 需要連線到我們的 nginx 服務。它現在可以使用服務的聯邦 DNS 名稱 nginx.mynamespace.myfederation，而不用服務傳統的叢集本機 DNS 名稱 (nginx.mynamespace，會自動擴展為 nginx.mynamespace.svc.cluster.local)。這將會自動擴展並解析到我的 nginx 服務最近的健康分片，無論它在世界上的哪個位置。如果本機叢集中存在健康的分片，則會傳回該服務的叢集本機 IP 位址 (由叢集本機 DNS 傳回)。這與非聯邦服務解析完全相同。

如果本機叢集中不存在該服務 (或存在但沒有健康的後端 Pod)，DNS 查詢會自動擴展為 nginx.mynamespace.myfederation.svc.us-central1-a.us-central1.example.com。在幕後，這會找到最靠近我的可用區的分片之一的外部 IP。此擴展由叢集本機 DNS 伺服器自動執行，該伺服器會傳回相關聯的 CNAME 記錄。這會導致遍歷 DNS 記錄的層次結構，並最終到達附近聯邦服務的外部 IP 之一。

也可以透過明確指定適當的 DNS 名稱，而不是依賴自動 DNS 擴展，來鎖定可用區和區域中，Pod 本機以外的服務分片。例如，nginx.mynamespace.myfederation.svc.europe-west1.example.com 將解析為歐洲目前所有健康的服務分片，即使發出查詢的 Pod 位於美國，並且無論美國是否存在該服務的健康分片。這對於遠端監控和其他類似應用程式非常有用。

從聯邦叢集外部的其他用戶端探索聯邦服務

對於外部用戶端，目前無法使用所述的自動 DNS 擴展。外部用戶端需要指定聯邦服務的完整 DNS 名稱之一，無論是區域、區域性或全域名稱。為了方便起見，通常最好在您的服務中手動配置其他靜態 CNAME 記錄，例如

短名稱CNAME
eu.nginx.acme.comnginx.mynamespace.myfederation.svc.europe-west1.example.com
us.nginx.acme.comnginx.mynamespace.myfederation.svc.us-central1.example.com
nginx.acme.comnginx.mynamespace.myfederation.svc.example.com

這樣一來，您的用戶端就可以始終使用左側的簡短形式，並始終自動路由到其所在洲最近的健康分片。所有需要的容錯移轉都由 Kubernetes 叢集聯邦自動為您處理。

作為延伸閱讀，使用者可以在 Multi-Cluster Service DNS with ExternalDNS 指南中找到更詳細的使用者範例

親自試試看

若要開始使用 Federation v2，請參閱使用者指南。可以使用 Helm chart 完成部署，一旦控制平面可用，就可以使用使用者指南的範例來獲得 Federation V2 的實務經驗。

Federation v2 可以部署在叢集範圍和命名空間範圍配置中。叢集範圍部署將需要主機和成員叢集的叢集管理員權限，並且可能非常適合在未執行關鍵工作負載的叢集上評估聯邦。命名空間範圍部署僅需要存取主機和成員叢集上的單一命名空間，並且更適合在執行工作負載的叢集上評估聯邦。大多數使用者指南都參考叢集範圍部署，而 命名空間聯邦章節記錄了命名空間部署的使用差異。同一個叢集可以託管多個聯邦，並且在使用命名空間聯邦時，叢集可以成為多個聯邦的一部分。

下一步

正如我們在這篇文章開頭所指出的，多叢集問題空間非常廣泛。如果沒有具體的軟體來架構這些對話，可能很難確切地知道如何處理如此廣泛的問題空間。我們在聯邦工作組中的希望是，Federation v2 可以成為架構討論的具體產物。我們很想了解大家在這個問題空間中的經驗、他們對 Federation v2 的看法，以及他們未來有興趣探索的使用案例。

歡迎加入我們的 sig-multicluster slack 頻道 或每週三太平洋標準時間 07:30 舉行的 聯邦工作組會議。