本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。
聚焦 SIG 多集群
简介
SIG 多集群 专注于 Kubernetes 概念如何扩展和应用于集群边界之外。历史上，Kubernetes 资源只能在边界内交互 - KRU 或 Kubernetes 资源宇宙（并非实际的 Kubernetes 概念）。即使现在，Kubernetes 集群也并不真正了解自身或其他集群。缺少集群标识符就是一个例子。随着多云和多集群部署的日益普及，SIG 多集群的工作正受到越来越多的关注。在这篇博文中，Google 的 Jeremy Olmsted-Thompson 和 AWS 的 Chris Short 讨论了 SIG 多集群正在解决的有趣问题以及您如何参与其中。为了简洁起见，将使用他们的首字母 JOT 和 CS。
他们对话的总结
CS：SIG 多集群存在多久了？这个 SIG 在初期是什么样的？您加入这个 SIG 有多久了？
JOT：我在 SIG 多集群已经快两年了。关于初期的了解，我都是从传说中听来的，但即使在早期，它始终围绕着解决同一个问题。早期的工作包括 KubeFed 等项目。我认为现在仍然有人在使用 KubeFed，但比例较小。那时，我认为部署大量 Kubernetes 集群的人们还没有达到我们有很多真实的具体用例的程度。像 KubeFed 和 集群注册表 等项目都是在那个时候开发的，当时的需求可以与这些项目联系起来。这些项目的动机是，当我们开始扩展到多个集群时，我们如何解决我们认为人们将会遇到的问题。老实说，在某种程度上，那时的尝试有点过于超前了。
CS：KubeFed 与当前 SIG 多集群的状态有何不同？传说与现在有何不同？
JOT：是的，这就像试图提前解决潜在的问题，而不是解决具体的问题。我认为到 2019 年底，SIG 多集群的工作有所放缓，我们通过最近最活跃的项目之一 SIG 多集群服务 (MCS) 重新启动了它。
现在，我们已经转向解决真正的具体问题。例如，
我的工作负载分布在多个集群中，我需要它们彼此通信。
好的，这非常简单，我们知道我们需要解决这个问题。为了开始，让我们确保这些项目可以使用一个通用的 API 进行协作，这样您就可以获得与 Kubernetes 相同的可移植性。
目前已经有一些 MCS API 的实现，并且还有更多的正在开发中。但是，我们没有构建实现，因为根据您部署事物的方式，可能会有数百种实现。只要您只需要基本的多集群服务功能，它就可以在您想要的任何背景下工作，无论是 Submariner、GKE 还是服务网格。
我最喜欢的“过去与现在”的例子是集群 ID。几年前，曾经努力定义集群 ID。为了这个概念，人们进行了很多深入的思考，例如，我们如何使集群 ID 在多个集群中保持唯一。我们如何使这个 ID 在任何环境中都是全局唯一的？比如说，如果团队之间有收购或合并，这些团队的集群 ID 是否仍然保持唯一？
在多集群服务中，我们发现了对实际集群 ID 的需求，它有一个非常具体的需求。为了满足这个具体的需求，我们不再考虑所有 Kubernetes 集群，而是考虑 ClusterSets - 一组在某种范围内协同工作的集群。这比考虑时间和空间中的所有集群范围要窄得多。它也为实施者提供了定义边界（ClusterSet）的灵活性，超过该边界，此集群 ID 将不再唯一。
CS：您对当前 SIG 多集群的状态与您希望在未来达到的状态有何看法？
JOT：有一些项目刚刚开始，例如，Work API。在未来，我认为会形成一些关于如何在集群之间部署事物的通用实践。
如果我在许多不同的区域部署了集群；实际上最好的方法是什么？
答案几乎总是“视情况而定”。您为什么要这样做？是因为某种合规性让您关心位置吗？是为了性能吗？是为了可用性吗？
我认为，在我们拥有集群 ID 之后，重新审视注册表模式可能会是自然的一步，也就是说，您实际上如何将这些集群关联在一起？也许您有一个分布式的部署，在您遍布世界各地的数据中心中运行。我认为随着更多多集群功能的开发，扩展该领域的 API 将变得非常重要。这真的取决于社区开始使用这些工具做什么。
CS：在 Kubernetes 的早期，我们曾经有少数几个大型 Kubernetes 集群，现在我们正在处理许多小型 Kubernetes 集群 - 甚至为我们自己的开发环境使用多个集群。从少数大型集群到许多小型集群的这种转变如何影响了 SIG？它是否加速了工作，或者在任何方面都带来了挑战？
JOT：我认为它造成了很多需要解决的模糊性。最初，您会有一个开发集群、一个暂存集群和一个生产集群。当多区域出现时，我们开始需要每个区域的开发/暂存/生产集群。然后，有时集群确实需要更多的隔离，因为合规性或某些法规问题。因此，我们最终得到了很多集群。我认为弄清楚您实际上应该拥有多少集群的正确平衡非常重要。Kubernetes 的强大之处在于能够部署许多由单个控制平面管理的东西。因此，并非每个部署的工作负载都应该在其自己的集群中。但我认为很明显，我们不能将每个工作负载都放在一个集群中。
CS：您最喜欢这个 SIG 的哪些方面？
JOT：问题的复杂性、人员和这个领域的新颖性。我们没有正确的答案，我们必须弄清楚这一点。一开始，我们甚至无法考虑多集群，因为没有办法连接跨集群的服务。现在有了，我们开始着手解决这些问题，我认为这是一个非常有趣的地方，因为我预计在未来几年，SIG 将会变得更加繁忙。这是一个非常协作的团体，我们绝对希望更多的人加入我们，参与其中，提出他们的问题并带来他们的想法。
CS：您认为是什么让人们留在这个小组中？疫情如何影响了您？
JOT：我认为在疫情期间，它确实变得有点安静了。但在大多数情况下，这是一个非常分散的团体，所以无论您是在会议室还是在家中参加我们的每周会议，都没有太大的区别。在疫情期间，很多人都有时间专注于他们规模和增长的下一步。我认为这才是让人们留在这个小组的原因 - 我们有真正的、需要解决的、在这个领域非常新的问题。而且这很有趣 :)
总结
CS：今天就到这里了。感谢 Jeremy 的时间。
JOT：谢谢 Chris。欢迎大家参加我们的双周会议。我们欢迎尽可能多的人来参加，并欢迎所有问题和所有想法。这是一个新的领域，如果能壮大社区那就太好了。