炉边谈话｜SIG Multicluster

作者：Dewan Ahmed（Aiven）和 Chris Short（AWS）

介绍

SIG Multicluster[1]是专注于 Kubernetes 概念如何扩展和超越集群边界使用的 SIG。历史上，Kubernetes 资源只在这个边界内相互作用——KRU 或 Kubernetes Resource Universe（不是一个真正的 Kubernetes 概念）。Kubernetes 的集群，即使是现在，也不知道关于自己或者其他集群的任何事情。集群标识符的缺失就是一个很好的例子。随着对多云和多集群部署的采用越来越多，SIG multicluster 所做的工作正获得很多关注。在这篇博客中，Jeremy Olmsted-Thompson，谷歌[2]和Chris Short，AWS[3]讨论了 SIG Multicluster 正在解决的有趣问题，以及你可以如何参与进来。为了简洁起见，我们将使用他们的首字母JOT和CS。

谈话摘要

CS：SIG Multicluster 存在多久了？SIG 的初期是怎样的？你参与 SIG 有多长时间了？

JOT：我已经在 SIG Multicluster 工作了近两年了。我所知道的初期情况都来自传说，但即使是在早期，也总是关于解决同样的问题。早期的努力包括KubeFed[4]。我认为仍有小部分人在使用 KubeFed。那时候，我认为部署大量 Kubernetes 集群的人还没有真正拥有大量具体的用例。像 KubeFed 和Cluster Registry[5]这样的项目是在那个时候开发的，那时的需求可以与这些项目相关联。这些项目的动机是，当人们开始扩展到多个集群时，我们如何解决我们认为人们将会遇到的问题。老实说，在某种程度上，它当时想做的太多了。

CS：KubeFed 与 SIG Multicluster 的当前状态有何不同？早期和现在有什么不同？

JOT：是的，这就像试图提前解决潜在的问题，而不是解决具体的问题。我认为在 2019 年年底，SIG Multicluster 工作有所放缓，我们通过最近最活跃的项目之一SIG Multicluster 服务（MCS）[6]重新投入了它。

现在我们转向解决真正的具体问题。例如，

我的工作负载分布在多个集群中，我需要它们相互通信。

这很简单，我们知道我们需要解它。在开始之前，让我们确保这些项目可以在一个公共 API 上一起工作，这样你就可以获得与 Kubernetes 一样的可移植性。

现在外面是有一些 MCS API 的实现，更多的正在开发中。但是，我们没有构建一个实现，因为取决于你如何部署东西，可能有数百个实现。只要你只需要基本的多集群服务功能，它就可以在任何你想要的背景下工作，无论是Submariner[7]，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：我认为这创造了许多需要解决的模糊性。最初，你拥有一个开发集群、一个模拟（staging）集群和一个生产集群。当多区域出现时，我们开始需要每个区域的 dev/staging/prod 集群。然后，有时由于遵从性或一些法规问题，集群确实需要更多的隔离。因此，我们最终会得到很多集群。我认为，在实际应该拥有多少集群上找到正确的平衡是很重要的。Kubernetes 的强大之处在于它能够通过一个控制平面来部署很多东西。因此，并不是每个部署的工作负载都需要在自己的集群中。但我认为，很明显，我们不能将每个工作负载都放在一个集群中。

CS：关于这个 SIG，你最喜欢的是什么？

JOT：问题的复杂性，人员和领域的新鲜度。我们没有正确的答案，我们必须弄清楚。一开始，我们甚至不能考虑多集群，因为没有办法跨集群连接服务。现在有了，我们开始着手解决这些问题，我认为这是一个非常有趣的地方，因为我预计 SIG 将在未来几年变得更加忙碌。这是一个非常合作的团队，我们当然希望更多的人加入我们，参与进来，提出他们的问题，提出他们的想法。

CS：你认为是什么让人们留在这个团队中？冠状病毒病大流行对你们有何影响？

JOT：我认为在大流行期间，它确实变得安静了一些。但在大多数情况下，这是一个非常分散的小组，所以无论你是在会议室还是在家里参加我们的每周例会，都没有太大的区别。在大流行期间，许多人有时间关注他们下一步的规模和增长。我认为这是让人们留在团队中的原因——我们有真正需要解决的问题，这些问题在这个领域是非常新的。这很有趣:）

总结

CS：今天的时间到这里。谢谢你，Jeremy。

JOT：谢谢 Chris。欢迎大家参加我们双周会议[8]。我们喜欢多人参与，欢迎所有问题和想法。这是一个新领域，发展社区会很棒。

参考资料

[1]SIG Multicluster: https://github.com/kubernetes/community/tree/master/sig-multicluster

[2]Jeremy Olmsted-Thompson，谷歌: https://twitter.com/jeremyot

[3]Chris Short，AWS: https://twitter.com/ChrisShort

[4]KubeFed: https://github.com/kubernetes-sigs/kubefed

[5]Cluster Registry: https://github.com/kubernetes-retired/cluster-registry

[6]SIG Multicluster 服务（MCS）: https://github.com/kubernetes-sigs/mcs-api

[7]Submariner: https://submariner.io/

[8]双周会议: https://github.com/kubernetes/community/tree/master/sig-multicluster#meetings