本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Multicluster
簡介
SIG Multicluster 是一個專注於 Kubernetes 概念如何擴展和應用於叢集邊界之外的 SIG。從歷史上看，Kubernetes 資源僅在該邊界內交互 - KRU 或 Kubernetes 資源宇宙（不是實際的 Kubernetes 概念）。即使是現在，Kubernetes 叢集實際上也不了解自己或關於其他叢集的任何資訊。缺少叢集標識符就是一個例子。隨著多雲和多叢集部署的日益普及，SIG Multicluster 正在做的工作越來越受到關注。在本部落格中，Google 的 Jeremy Olmsted-Thompson 和 AWS 的 Chris Short 討論了 SIG Multicluster 正在解決的有趣問題，以及您如何參與其中。為簡潔起見，將使用他們的首字母 JOT 和 CS。
他們的對話摘要
CS：SIG Multicluster 存在多久了？SIG 在初期是如何的？您加入這個 SIG 有多久了？
JOT：我在 SIG Multicluster 大約兩年了。我對初期的了解都來自軼事，但即使在早期，它始終是關於解決同一個問題。早期的努力一直是像 KubeFed 這樣的東西。我認為仍然有人在使用 KubeFed，但比例較小。在那時，我認為部署大量 Kubernetes 叢集的人們實際上還沒有達到我們有大量真實具體用例的地步。像 KubeFed 和 Cluster Registry 這樣的專案是在那段時間開發出來的，當時的需求可以與這些專案相關聯。這些專案的動機是當人們開始擴展到多個叢集時，我們如何解決我們認為人們將要遇到的問題。老實說，在某些方面，那時嘗試做的事情太多了。
CS：KubeFed 與當前 SIG Multicluster 的狀態有何不同？軼事與現在有何不同？
JOT：是的，這就像試圖領先於潛在問題，而不是解決特定問題。我認為在 2019 年底，SIG multicluster 的工作有所放緩，我們透過最近最活躍的專案之一 SIG Multicluster 服務 (MCS) 重新開始。
現在，這是轉向解決真實特定問題的轉變。例如，
我的工作負載分佈在多個叢集上，我需要它們互相通信。
好的，這非常直接，我們知道我們需要解決這個問題。為了開始，讓我們確保這些專案可以協同工作在一個通用的 API 上，以便您獲得與 Kubernetes 相同的可移植性。
MCS API 有一些實作，並且正在開發更多實作。但是，我們沒有構建實作，因為根據您部署事物的方式，可能會有多種實作。只要您只需要基本的多叢集服務功能，它就可以在您想要的任何背景下工作，無論是 Submariner、GKE 還是服務網格。
我最喜歡的“當時 vs. 現在”的例子是叢集 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。歡迎大家參加我們的每兩週會議。我們歡迎盡可能多的人來參加，並歡迎所有問題和所有想法。這是一個新的領域，如果能壯大社群那就太好了。