深度剖析 PaaS 平臺上的聯邦叢集_Kubernetes中文社群
以下是本次分享實錄：
魏魏：根據現場的反饋，大家對聯邦叢集的認識可能還處在初級階段，因此後面介紹的時候會先介紹一些概念，介紹概念的過程當中再逐步深入。
今天主要講兩點，第一個聯邦叢集在社群裡面的現狀是什麼樣的。主要分為兩部分，第一個是聯邦叢集 V1，第一個版本，另外就是講聯邦叢集 V2。V2 是聯邦叢集現在社群裡面最新的進展，但是現在聯邦叢集V2的版本還處在早期的階段。
另外要講的一點就是聯邦叢集需要解決的問題，這裡主要講兩個方面。第一全域性性的負載均衡，第二跨叢集的分散式儲存。比如說，不同叢集之間儲存如何實現同步和複製，可能會有這種場景的需要。
聯邦叢集社群現狀
為什麼要做聯邦叢集？第一是要保證業務可以正常運營，要符合當地的法律法規，這就是業務的敏感性。第二，平臺大都不希望被特定的廠商鎖定，不希望所有的業務都布在 Kubernetes 之上。
首先介紹一下 Federation-V1 相關的資源。上面圖表裡的資源是聯邦叢集支援的資源，也就是說這些資源是可以在聯邦叢集上創建出來的。除了這個列表以外的其它資源，你在聯邦叢集上是沒有辦法建立的，而這些資源和 Kubernetes 本身的資源是有差異性的。這是聯邦 V1 版本里面現在面臨最大的問題，你要想擴充套件相關的資源，你必須要自己擴建。
Federation-V2
FederationV2 相關的概念，第一個概念成員叢集，不管是聯邦叢集 V1 版還是 V2 版，它都有成員叢集的概念。第二個是 Template，Template 在 V1 裡面是沒有的。它更多是指資源的定義，而這種資源的定義在 V2 裡面可以通過模板，定義所有資源，任何的資源都需要通過以模板的方式定義出來。並且這些資源之所以稱之為模板關鍵性原因，就是模板裡面有很大一部分引數是可以被替換掉的。
第三個概念是 Overrides，這個在聯邦叢集V1版裡面也沒有。這個東西更多強調的是我前面講的兩種場景，比如說 VPN 這種業務場景。我部署了一個 Pod，它分佈在不同的叢集上，如果我不希望這個業務部署某個地區，就可以通過 Overrides 覆蓋掉原來的裡面的業務，這就是它典型的使用場景。
然後是 Placement，它主要是用來決定哪些資源排程到哪些叢集上，它更多是影響這些東西，但是 Placement 本身並不是排程過程，排程的過程最終是靠下面來完成的。
還有另外一個概念就是 Propagation，它和 Placement 不太一樣，它是一個過程，一個機制。在不同的叢集上，如何去真正的把這些資源創建出來。比如說你想創建出來一個 Pod，具體就是由它把資源在不同的叢集上創建出來的。通過這種機制把資源創建出來之後，我要知道資源是建立成功還是失敗了，可以根據這個狀態做下一步的處理。
聯邦叢集裡面 V2 和 V1 不太一樣的點，V1 的資源大致瞭解之後，我們再看 V2 版，V2 資源主要分成兩部分，一個是基本的聯邦資源。另外一種是輔助性的聯邦資源。我們先看基本的聯邦資源。
剛才介紹的是聯邦 V2 版本里的基本資源，再介紹一些輔助資源，主要有以下幾種。一個是 Placement Preferences，這種主要是用來定義使用者偏好，主要是用來影響排程的。使用者希望某一個特定的業務排程到某一個特定的叢集上，一般情況下是由系統管理員完成這件事情。
既然講聯邦叢集 V2，我們就要了解一下它的歷史，它最早是 2017 年下半年的時候，工程師最早搞了一個稱之為 “fnord” 的一個專案，這個專案整體的結構就是這樣，它裡面涉及一些東西，像已有的聯邦叢集的 API，還有聯邦叢集的註冊列表，以及相關生成的聯邦叢集資源的一些型別。這些最早是這個專案相關的資源，以及資源相互之間的作用。
聯邦叢集的輔助資源的主要影響有兩個，一個是排程，二是模板替換的過程。而使用者的資源都是通過模板的方式建立，以模板的方式創建出來之後，通過 Kubernetes 或者是排程，由它決定這些工作負載去哪裡。
以上主要講聯邦叢集 V2 他們資源之間的相互作用，以及工作原理。這些資源已經有了，但剛才講的這個迴圈，事實上在社群裡面還沒有真正的執行起來，只是一個雛形。
以上主要介紹了聯邦叢集相關的 V1 和 V2 社群裡面現狀和進展，接下來我們主要從兩個方面介紹一下聯邦叢集面臨的一些問題。
剛才介紹聯邦叢集的時候，大家也注意到，聯邦主要解決了資源的建立和資源的排程兩個方面的問題。我們第一段說聯邦叢集有很多的問題，這些問題都沒有得到很好的解決，目前社群裡也沒有成熟的方案去解決這些跨叢集相關的問題。
今天講的點主要分兩個，第一個是全域性性的 LB（Load balancing）。這裡的全域性性的LB可能需要跨雲，比如說我們這裡的一個場景，你可以把你的工作負載分散在不同的雲上。但是你的工作負載或者你的程式部署在雲上之後，你怎麼向你的終端使用者提供服務呢？現在實際的情況是，比如說 AWS 這種，他們都沒有跨雲的負載能力。以 GCE 為例，因為它對 K8S 的親和力相對高一些，但是它本身提供的東西也根本沒有辦法實現跨雲的 LB。它只能實現你所有開發的叢集都部署在我的 GCE 上。但如果你想實現某些開發叢集部署在 AWS 上，某些部署在 GCE 上的，它根本就實現不了。
第二個問題是有了負載之後，如果讓某一個 EBS 上的服務掛掉了，你怎麼在他們雲之間做遷移，跨雲的遷移怎麼做呢？ EBS 掛了，我的業務需要遷移，但是業務遷移的過程中，我希望外部使用者對這個最好是無感知的。如果是對業務的連續性要求比較高的業務場景，肯定不希望使用者感知到。這個應該怎麼做，跨雲的遷移，在實際的使用場景下，也是很令人頭疼的問題。
全域性性的負載均衡，首先要考慮清楚以下幾個問題。
另外一個問題，某一個雲上的業務因為請求使用者多和少，你可能需要對某些資源進行釋放或者是對某些資源進行重新申請，當用戶量大的時候，我需要申請一些高配的資源，使用者量小的時候，我需要申請一些低配置的資源，需要釋放一些資源，這種問題又如何通過跨雲的 LB 實現呢？
前面介紹了很多各種各樣的問題，比如說負載均衡，如何動態的負載均衡，伸縮的時候又怎麼做。對於全域性性負載均衡，現在社群裡無外乎就是這幾種做法。首先，你可以使用第三方廠商全域性性的負載均衡器，比如你可以直接用谷歌的全域性性負載均衡器，但前提是你全部的部署都在谷歌的 GCE 上。
另外一種就是基於 CDN，現在社群裡關於全域性性負載均衡主要的思路就是這四種方式。你可以在技術方面做一些嘗試，但是社群裡目前沒有比較好的推薦。現在真正能夠把聯邦叢集用在生產環境的，應該是少之又少，或者是根本沒有。哪怕谷歌本身，它也沒有把聯邦叢集直接用於生產環境，在國內就更少，基本上都用聯邦叢集做開發環境和測試環境。
剛才在前面介紹了全域性性的負載均衡，後面主要介紹一下儲存問題，全域性性的分散式儲存。對於跨叢集來說，不同叢集之間，他們的工作負載都在 slave 上，它們之間是否會有資料同步呢。它們之間資料同步又應該怎麼做，我們必須得有相應的分散式儲存。比如說你的工作負載跑在 GCE 上，它可以直接跟 AWS 進行同步嗎？顯然是不行的，如果想要同步必須自己去做，必須要藉助其它的辦法和手段去做，因為谷歌本身並不做這種事情。谷歌更加希望你所有的業務都在我谷歌上，但是對於很多使用者，都極力避免被廠商鎖定，這就是他們的出發點。
當然 ceph 本身通過一些其它的技術手段可以支援 NFS、ISCSI 等等這些方式，這些方式其實也是可以通過底層下面的塊或者是池的方式同步。
在跨叢集上，假設已經解決分散式儲存，是不是意味著任何業務都可以跨叢集的部署了呢？顯然不是，儲存通常是和儲存相關的業務場景是相聯絡的。可以是全域性性分散式資料庫，這些儲存系統本身就具有資料全球化同步的能力。比如說它可以做全球性的部署，比如說在同一個叢集裡面某些節點是在紐約部署的，另外一些節點可能是在中國部署的，它可以跨地域。
但是有一些業務場景，就沒有辦法進行跨地域的部署。你想實現把它一個節點部署在香港，一個部署在北京，這是能接受的事情，因為延時實在太高了，延時無法把這兩個或者三個節點組成一個叢集。因為它們對延時或者是對資料同步的一致性要求特別高，但是上面的業務系統就可以做到。
所以通常部署這些儲存性程式的時候，一般考慮的不是把他們做跨叢集或者是跨機房的資料同步，而是把它放在同一個資料中心裡面去，這樣延時就會低很多。
前面介紹了很多聯邦叢集的好處，但聯邦叢集不是無所不能，聯邦叢集也有很多問題。聯邦叢集 V1 版從 1.9 之後，開始把聯邦叢集 V1 相關的程式碼從主倉庫裡獨立出來了。獨立出來以後，它能夠獨立的發展。但也帶來一些問題，比如社群裡面很多開發者在新倉庫裡的貢獻相對來說沒那麼積極了。
第二個問題，前面介紹了很多聯邦叢集的功能，事實上有很多功能是處在不可用的狀態，或者僅僅只有一個雛形，甚至連程式碼都沒有，都是在等待社群開發人員積極的加入，做一些相應的開發。
另外一個問題，聯邦叢集 controlplane只有一個，一旦 controlplane 出了問題，整個聯邦叢集都會掛掉，它在架構設計上存在這種問題。
前面提到跨叢集請求的訪問，不管是跨叢集的 LB，還是跨叢集的資料同步，都要受到這樣的限制，而在公有云上，最大的問題就是頻寬的成本過高。