这篇文章已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已不正确。
聚焦 SIG Multicluster
引言
SIG Multicluster 是一个 SIG，专注于 Kubernetes 概念如何扩展到集群边界之外并加以利用。历史上，Kubernetes 资源仅在此边界内交互——即 KRU 或 Kubernetes Resource Universe（并非 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 的实现，并且正在开发更多。但是，我们没有构建一个具体的实现，因为取决于你如何部署，可能会有成百上千种实现方式。只要你只需要基本的 Multicluster service 功能，它就可以在你想要的任何底层上工作，无论是 Submariner、GKE，还是一个服务网格。
我最喜欢的“当时与现在”的例子是集群 ID。几年前，曾有一项工作来定义集群 ID。当时对这个概念进行了很多深入的思考，例如，如何确保集群 ID 在多个集群中是唯一的。如何使这个 ID 全局唯一，以便它在任何上下文中都能工作？比如说，如果团队发生了收购或合并，这些集群 ID 对于这些团队来说是否仍然保持唯一？
通过 Multicluster services，我们发现了对实际集群 ID 的需求，它有一个非常具体的需求。为了满足这个特定需求，我们不再考虑所有现有的 Kubernetes 集群，而是考虑 ClusterSets——一种在某种范围内协同工作的集群分组。这比考虑时空中的所有集群范围要窄得多。它还为实现者留下了灵活性，可以定义这个集群 ID 不再唯一的边界（一个 ClusterSet）。
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。欢迎大家参加我们的双周例会。我们非常欢迎尽可能多的人来参加，并欢迎所有问题和想法。这是一个新的领域，很高兴能壮大社区。