联邦

本页面阐明了为何以及如何使用联邦创建Kubernetes集群。

为何使用联邦

联邦可以使多个集群的管理简单化。它提供了两个主要构件模块:

  • 跨集群同步资源:联邦能够让资源在多个集群中同步。例如,你可以确保在多个集群中存在同样的部署。
  • 跨集群发现:联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如,通过多个集群的后端,你可以确保全局的VIP或DNS记录可用。

联邦技术的其他应用场景:

  • 高可用性:通过跨集群分摊负载,自动配置DNS服务和负载均衡,联邦将集群失败所带来的影响降到最低。
  • 避免供应商锁定:跨集群使迁移应用程序变得更容易,联邦服务避免了供应商锁定。

只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因:

  • 降低延迟:在多个区域含有集群,可使用离用户最近的集群来服务用户,从而最大限度降低延迟。
  • 故障隔离:对于故障隔离,也许有多个小的集群比有一个大的集群要更好一些(例如:一个云供应商的不同可用域里有多个集群)。详细信息请参阅多集群指南
  • 可伸缩性:对于单个kubernetes集群是有伸缩性限制的(但对于大多数用户来说并非如此。更多细节参考Kubernetes扩展和性能目标)。
  • 混合云:可以有多个集群,它们分别拥有不同的云供应商或者本地数据中心。

注意事项

虽然联邦有很多吸引人的场景,但这里还是有一些需要关注的事项:

  • 增加网络的带宽和损耗:联邦控制面会监控所有的集群,来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中,则会带来重大的网络损耗。
  • 降低集群的隔离:当联邦控制面中存在一个故障时,会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时,它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。
  • 完整性:联邦项目相对较新,还不是很成熟。不是所有资源都可用,且很多资源才刚刚开始。Issue 38893 列举了一些团队正忙于解决的系统已知问题。

混合云的能力

Kubernetes集群里的联邦包括运行在不同云供应商上的集群(例如,谷歌云、亚马逊),和本地部署的集群(例如,OpenStack)。只需在适当的云供应商和/或位置创建所需的所有集群,并将每个集群的API endpoint和凭据注册到您的联邦API服务中(详情参考联邦管理指南)。

在此之后,您的API资源就可以跨越不同的集群和云供应商。

建立联邦

若要能联合多个集群,首先需要建立一个联邦控制面。参照安装指南 建立联邦控制面。

API资源

控制面建立完成后,就可以开始创建联邦API资源了。 以下指南详细介绍了一些资源:

API参考文档列举了联邦API服务支持的所有资源。

级联删除

Kubernetes1.6版本支持联邦资源级联删除。使用级联删除,即当删除联邦控制面的一个资源时,也删除了所有底层集群中的相应资源。

当使用REST API时,级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时,要开启级联删除功能,即需配置选项 DeleteOptions.orphanDependents=false。使用kubectl delete使级联删除功能默认开启。使用kubectl delete --cascade=false禁用级联删除功能。

注意:Kubernetes1.5版本开始支持联邦资源子集的级联删除。

单个集群的范围

对于IaaS供应商如谷歌计算引擎或亚马逊网络服务,一个虚拟机存在于一个可用域中。 我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里,因为:

  • 与单一的全局Kubernetes集群对比,该方式有较少的单点故障。
  • 与跨可用域的集群对比,该方式更容易推断单区域集群的可用性属性。
  • 当Kubernetes开发者设计一个系统(例如,对延迟、带宽或相关故障进行假设),他们也会假设所有的机器都在一个单一的数据中心,或者以其他方式紧密相连。

每个可用区域里包含多个集群当然是可以的,但是总的来说我们认为集群数越少越好。 偏爱较少集群数的原因是:

  • 在某些情况下,在一个集群里有更多的节点,可以改进Pods的装箱问题(更少的资源碎片)。
  • 减少操作开销(尽管随着OPS工具和流程的成熟而降低了这块的优势)。
  • 为每个集群的固定资源花费降低开销,例如,使用apiserver的虚拟机(但是在全体集群开销中,中小型集群的开销占比要小的多)。

多集群的原因包括:

  • 严格的安全性策略要求隔离一类工作与另一类工作(但是,请参见下面的集群分割)。
  • 测试集群或其他集群软件直至最优的新Kubernetes版本发布。

选择合适的集群数

Kubernetes集群数量选择也许是一个相对静止的选择,因为对其重新审核的情况很少。相比之下,一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。

选择集群的数量,首先,需要决定哪些区域对于将要运行在Kubernetes上的服务,可以有足够的时间到达所有的终端用户(如果使用内容分发网络,则不需要考虑CDN-hosted内容的延迟需求)。法律问题也可能影响这一点。例如,拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用R代表区域的数量。

其次,决定有多少集群在同一时间不可用,而一些仍然可用。使用U代表不可用的数量。如果不确定,最好选择1。

如果允许负载均衡在集群故障发生时将通信引导到任何区域,那么至少需要较大的RU + 1集群。若非如此(例如,若要在集群故障发生时确保所有用户的低延迟),则需要R * (U + 1)集群(在每一个R区域里都有U + 1)。在任何情况下,尝试将每个集群放在不同的区域中。

最后,如果你的集群需求超过一个Kubernetes集群推荐的最大节点数,那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。

接下来