欢迎来到Kubernetes快速教程系列。 这是常规专栏，其中包含我们在网上和培训中收到的最有趣的问题。 Kubernetes专家回答。
今天的专家是Daniele Polencic 。 Daniel是Learnk8s的讲师和软件开发人员。
如果您想在下一篇文章中回答您的问题， 请通过电子邮件或在Twitter上 与我们联系 ：@ learningk8s 。
跳过以前的帖子？ 在这里找他们 。
如何连接不同数据中心的Kubernetes集群？
简要地说 ： Kubefed v2即将推出 ，我也建议您阅读有关Shipper和multi-cluster-scheduler项目的信息 。
通常，基础结构会在不同区域之间复制和分布，尤其是在受控环境中。
如果一个区域不可用，则将流量重定向到另一区域以避免中断。
借助Kubernetes，您可以使用类似的策略并在不同区域之间分配工作负载。
每个团队，区域，环境或这些元素的组合可以有一个或多个集群。
您的群集可以托管在不同的云和本地环境中。
但是，如何针对这种地理分布规划基础设施呢？
是否需要在单个网络上跨多个云环境创建一个大型集群？
还是启动许多小型集群并找到一种控制和同步它们的方法？
一个线索集群
在单个网络上创建单个集群不是那么简单。
想象一下您发生了事故，集群各部分之间的连接丢失。
如果您有一台主服务器，则一半的资源将无法接收新命令，因为它们将无法与主服务器联系。
同时，您拥有旧的路由表（ kube-proxy无法加载新的路由表），并且没有其他Pod（kubelet无法请求更新）。
更糟糕的是，如果Kubernetes没有看到该节点，它将标记为已丢失，并将丢失的Pod分发到现有节点。
结果，您的豆荚数量是原来的两倍。
如果为每个区域创建一个主服务器，则etcd数据库中的共识算法将存在问题。 （ 大约是Ed。-实际上，etcd数据库不必位于主服务器上。它可以在同一区域的另一组服务器上运行。但是，它收到了群集故障点。但是很快。 ）
在将值写入磁盘之前，etcd使用筏算法来协商该值。
也就是说，大多数实例必须先达成共识，然后才能将状态写入etcd。
如果etcd实例之间的延迟急剧增加（例如在不同区域中的三个etcd实例），则花费很长时间来协调该值并将其写入磁盘。
这反映在Kubernetes控制器中。
控制器管理器需要更多时间来了解更改并将响应写入数据库。
如果控制器不是一个控制器，而是多个控制器，则将获得连锁反应，并且整个群集将开始非常缓慢地工作 。
etcd对延迟非常敏感，以至于官方文档建议使用SSD而不是常规硬盘驱动器 。
当前没有针对单个群集的大型网络的良好示例。
基本上，开发社区和SIG-cluster组正在尝试找出如何以Kubernetes编排容器的相同方式来编排集群。
选项1：使用kubefed的集群联合
SIG-cluster的官方答案是kubefed2，这是原始客户端和操作员kube联合的新版本 。
他们第一次尝试使用kube联合工具将集群的集合作为单个对象进行管理。
刚开始是好的，但是最后，kube联合并不流行，因为它不支持所有资源。
他支持联合交付和服务，但不支持StatefulSets。
联盟的配置以注释的形式传输，灵活性没有差异。
想象一下如何仅使用注释来描述联盟中每个群集的副本分离。
原来是一团糟。
在kubefed v1之后，SIG集群表现出色，并决定从另一侧着手解决该问题。
他们决定不发布注释，而是发布在群集上安装的控制器。 可以使用自定义资源定义（CRD）进行配置。
对于将成为联合身份验证一部分的每个资源，您都具有三个部分的自定义CRD定义：
- 资源的标准定义，例如部署；
placement部分，您可以在其中确定如何在联盟中分配资源；- 部分
override ，对于特定资源，您可以覆盖展示位置的权重和参数。
这是带有放置部分和替代部分的组合交付示例。
apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: metadata: labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster2 - cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5
如您所见，供应分布在两个集群中： cluster1和cluster2 。
第一个集群提供三个副本，第二个集群设置为5。
如果您需要对副本数量进行更多控制，则kubefed2提供了一个新的ReplicaSchedulingPreference对象，可以在其中对副本进行加权：
apiVersion: scheduling.federation.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 9 clusters: A: weight: 1 B: weight: 2
CRD结构和API尚未准备就绪，正在官方项目存储库中进行积极的工作。
注意kubefed2，但请记住，它尚不适合工作环境。
在Kubernetes博客上的官方 kubefed2 文章和官方kubefed项目存储库中了解有关kubefed2的更多信息 。
选项2：将Booking.com样式的群集聚类
Booking.com开发人员并未处理kubefed v2，但他们提出了Shipper，后者是一家运营商，可在多个集群，多个区域和多个云中进行交付。
托运人类似于kubefed2。
两种工具都允许您为多个群集配置部署策略（使用了哪些群集以及它们具有多少个副本）。
但是托运人的目标是减少交货错误的风险。
在运货商中，您可以定义一系列步骤，以描述先前部署与当前部署之间的副本分离以及传入流量的数量。
当您向集群提交资源时，Shipper控制器会在所有组合集群中逐步部署此更改。
而且托运人非常有限。
例如， 它接受Helm图表作为输入 ，但不支持原始资源。
一般而言，托运人的工作方式如下。
代替标准交付，您需要创建一个包含Helm图表的应用程序资源：
apiVersion: shipper.booking.com/v1alpha1 kind: Application metadata: name: super-server spec: revisionHistoryLimit: 3 template: chart: name: nginx repoUrl: https://storage.googleapis.com/shipper-demo version: 0.0.1 clusterRequirements: regions: - name: local strategy: steps: - capacity: contender: 1 incumbent: 100 name: staging traffic: contender: 0 incumbent: 100 - capacity: contender: 100 incumbent: 0 name: full on traffic: contender: 100 incumbent: 0 values: replicaCount: 3
托运人是管理多个集群的不错选择，但它与Helm的紧密关系只会产生干扰。
如果我们都从赫尔姆（Helm）转向kustomize或kapitan，该怎么办 ？
在此官方新闻中了解有关Shipper及其哲学的更多信息。
如果您想深入研究代码， 请转到官方项目存储库 。
选项3：“魔术”集群加入
Kubefed v2和Shipper使用集群联合，通过自定义资源定义为集群提供新资源。
但是，如果您不想重写所有耗材，StatefulSet，DaemonSet等来组合怎么办？
如何在不更改YAML的情况下将现有群集包含到联盟中？
multi-cluster-scheduler是一个Admirality项目 ，用于处理群集中的计划工作负载。
但是，与其提出一种新的方式来与集群交互并在用户定义的定义中包装资源，多集群调度程序已嵌入在标准的Kubernetes生命周期中，并且拦截了所有创建Pod的调用。
每个下创建的立即替换为虚拟对象。
multi-cluster-scheduler使用Web挂钩来修改访问权限以拦截呼叫并创建空闲的Pod虚拟对象。
源窗格经历另一个计划周期，在对整个联盟进行调查之后，对放置进行决策。
最后，将pod交付给目标集群。
结果，您有一个额外的容器，它什么也不做，只占用空间。
优点是您不必编写新的资源来组合耗材。
每个创建Pod的资源都会自动准备好进行合并。
这很有趣，因为您的发货突然分布在多个区域，但是您没有注意到。 但是，这很冒险，因为这里的一切都取决于魔术。
但是，如果Shipper试图主要减轻供应的影响，则多群集计划程序将执行更一般的任务，并且可能更适合于批处理作业。
它没有先进的逐步供应机制。
您可以在官方存储库页面上了解有关multi-cluster-scheduler 的更多信息 。
如果您想了解实际使用的多集群调度程序，金钟可以将Argo用作一个有趣的用例 -工作流，事件，CI和Kubernetes CD。
其他工具和解决方案
连接和管理多个集群是一项复杂的任务；没有通用的解决方案。
如果您想了解有关此主题的更多信息，请参考以下资源：
今天就这些
感谢您阅读到底！
如果您知道如何更有效地连接多个集群，请告诉我们 。
我们会将您的方法添加到链接中。
特别感谢Chris Nesbitt-Smith和Vincent De Smet （ swatmobile.io的可靠性工程师）阅读本文并分享了有关联盟工作方式的一些有用信息。