本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 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。欢迎大家参加我们的双周会议。我们希望尽可能多的人来参加，并欢迎所有的问题和想法。这是一个新的领域，社区的壮大将是一件很棒的事情。