本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Multicluster
引言
SIG Multicluster 是專注於 Kubernetes 概念如何擴充套件和應用於叢集邊界之外的特別興趣小組。歷史上，Kubernetes 資源只在該邊界內互動——KRU 或 Kubernetes 資源宇宙（並非一個實際的 Kubernetes 概念）。Kubernetes 叢集，即使是現在，對自身或其他叢集也知之甚少。缺少叢集識別符號就是一個很好的例子。隨著多雲和多叢集部署的日益普及，SIG Multicluster 的工作正受到越來越多的關注。在這篇部落格中，來自 Google 的 Jeremy Olmsted-Thompson 和來自 AWS 的 Chris Short 將討論 SIG Multicluster 正在解決的有趣問題以及您如何參與其中。為簡潔起見，我們將使用他們的姓名首字母 JOT 和 CS。
他們的對話摘要
CS：SIG Multicluster 成立多久了？在其初期是怎樣的？您加入這個 SIG 有多久了？
JOT：我加入 SIG Multicluster 差不多兩年了。關於其早期的情況，我只知道一些傳聞，但即使在早期，它也一直致力於解決同樣的問題。早期的努力包括像 KubeFed 這樣的專案。我認為現在仍有一些人在使用 KubeFed，但這只是很小一部分。回想當時，我認為那些部署大量 Kubernetes 叢集的人們還沒有真正遇到足夠多的具體用例。像 KubeFed 和 Cluster Registry 這樣的專案就是在那段時間開發的，當時的需求可以與這些專案聯絡起來。這些專案的動機是思考如何解決當人們開始擴充套件到多個叢集時**將會**遇到的問題。老實說，在某些方面，當時它試圖做得太多了。
CS：KubeFed 與 SIG Multicluster 的現狀有何不同？過去與現在有何不同？
JOT：是的，那就像是試圖預先解決潛在問題，而不是解決具體問題。我認為在 2019 年底，SIG Multicluster 的工作有所放緩，然後我們重新啟動了它，其中最活躍的新專案之一是 SIG Multicluster Services (MCS)。
現在，這是一種轉向解決真實具體問題的轉變。例如，
我有一些工作負載分佈在多個叢集中，我需要它們能夠相互通訊。
好的，這很直接，我們知道我們需要解決這個問題。為了開始，我們首先要確保這些專案可以在一個共同的 API 上協同工作，這樣你就能獲得與 Kubernetes 相同的可移植性。
目前已經有一些 MCS API 的實現，並且還在開發更多。但是，我們沒有自己構建一個實現，因為根據你的部署方式，可能會有數百種實現。只要你需要基本的多叢集服務功能，它就可以在你想要的任何背景下工作，無論是 Submariner、GKE 還是服務網格。
我最喜歡的“當時與現在”的例子是叢集 ID。幾年前，曾有人嘗試定義一個叢集 ID。這個概念背後有很多很好的思考，例如，我們如何使一個叢集 ID 在多個叢集中保持唯一。我們如何使這個 ID 全域性唯一，以便在任何情況下都能工作？比如說，如果發生了團隊的收購或合併——叢集 ID 是否對這些團隊仍然保持唯一？
隨著多叢集服務的出現，我們發現需要一個實際的叢集 ID，並且它有非常具體的需求。為了滿足這一特定需求，我們不再考慮所有 Kubernetes 叢集，而是考慮 ClusterSets——一組在某種邊界內協同工作的叢集。這個範圍比考慮時空中的所有叢集要窄得多。它還為實現者留下了靈活性，可以定義一個邊界（ClusterSet），超出這個邊界，叢集 ID 將不再唯一。
CS：你對 SIG Multicluster 的現狀感覺如何，與你希望未來達到的目標相比呢？
JOT：有幾個專案正在啟動，例如 Work API。未來，我認為將會形成一些關於如何在叢集間部署事物的通用實踐。
如果我的叢集部署在許多不同的區域，那麼最好的方法是什麼？
答案几乎總是“視情況而定”。你為什麼這麼做？是因為有某種合規性要求你關心本地性嗎？是效能原因嗎？還是可用性？
我認為在我們擁有叢集 ID 之後，重新審視註冊模式可能會是自然的下一步，也就是說，你實際上如何將這些叢集關聯在一起？也許你有一個分散式的部署，執行在世界各地你自己的資料中心裡。我想隨著更多多叢集功能的開發，擴充套件該領域的 API 將會變得很重要。這真的取決於社群開始如何使用這些工具。
CS：在 Kubernetes 的早期，我們通常有幾個大型 Kubernetes 叢集，而現在我們處理的是許多小型 Kubernetes 叢集——甚至在我們自己的開發環境中也有多個叢集。從少數大型叢集到許多小型叢集的這種轉變對 SIG 有何影響？它是否加速了工作，或者在任何方面帶來了挑戰？
JOT：我認為它製造了許多需要解決的模糊性。最初，你可能會有一個開發叢集、一個預發叢集和一個生產叢集。當多區域的概念出現後，我們開始需要在每個區域都設定開發/預發/生產叢集。然後，有時由於合規或某些法規問題，叢集確實需要更多的隔離。因此，我們最終擁有了大量的叢集。我認為，弄清楚你應該擁有多少叢集的正確平衡是很重要的。Kubernetes 的強大之處在於能夠部署大量由單一控制平面管理的東西。所以，並不是每個部署的工作負載都應該在它自己的叢集中。但我認為很明顯，我們不能把所有的工作負載都放在一個單一的叢集中。
CS：關於這個 SIG，你最喜歡哪些方面？
JOT：問題的複雜性、參與的人以及這個領域的新穎性。我們沒有現成的正確答案，我們必須自己去探索。起初，我們甚至無法考慮多叢集，因為沒有辦法跨叢集連線服務。現在有了，我們開始著手解決這些問題，我認為這是一個非常有趣的地方，因為我預計 SIG 在未來幾年會變得更加忙碌。這是一個非常協作的團體，我們非常希望有更多的人加入我們，參與進來，提出他們的問題，並帶來他們的想法。
CS：你認為是什麼讓人們留在這個小組裡？疫情對你有什麼影響？
JOT：我認為在疫情期間，情況確實變得安靜了一些。但在大多數情況下，這是一個非常分散的團體，所以無論你是從會議室還是從家裡撥入我們的每週會議，都沒有太大的區別。在疫情期間，許多人有時間專注於他們規模和增長的下一步。我認為這就是讓人們留在這個小組裡的原因——我們有真正需要解決的問題，而這些問題在這個領域是非常新的。而且這很有趣 :)
總結
CS：今天就到這裡。謝謝 Jeremy 的時間。
JOT：謝謝 Chris。歡迎大家參加我們的雙週會議。我們希望儘可能多的人來參加，並歡迎所有的問題和想法。這是一個新的領域，社群的壯大將是一件很棒的事情。