此页面描述了如何在多个区域中运行集群。
- 介绍
- 功能性
- 局限性
- 演练
介绍
Kubernetes 1.2增加了在多个故障区域中运行单个集群的支持（GCE称它们为“区域”，AWS称它们为“可用区域”，在这里我们将它们称为“区域”）。这是更广泛的集群联合功能的轻量级版本（以前被昵称为“ Ubernetes”）。完全集群联盟允许组合运行在不同区域或云提供商（或本地数据中心）中的各个Kubernetes集群。但是，许多用户只是想在其单个云提供商的多个区域中运行一个更可用的Kubernetes集群，而这正是1.2中的多区域支持所允许的（这以前被称为“ Ubernetes Lite”）。
对多区域的支持有一些限制：单个Kubernetes集群可以在多个区域中运行，但只能在同一区域（和云提供商）中运行。当前仅自动支持GCE和AWS（尽管很容易通过简单地安排将适当的标签添加到节点和卷来为其他云甚至裸机添加类似的支持）。
功能
启动节点后，kubelet会自动向其添加带有区域信息的标签。
Kubernetes会自动将复制控制器或服务中的Pod跨单个区域群集中的节点分布（以减少故障的影响）。对于多区域群集，此分布行为将跨区域扩展（以减少区域故障的影响） 。）（通过SelectorSpreadPriority实现）。这是尽力而为的布置，因此，如果群集中的区域是异构的（例如，不同数量的节点，不同类型的节点或不同的Pod资源要求），这可能会阻止Pod在整个区域中均匀分散。如果需要，可以使用同质区域（相同数量和类型的节点）来减少不等扩展的可能性。
创建永久卷后，PersistentVolumeLabel准入控制器会自动向其添加区域标签。然后，调度程序（通过VolumeZonePredicate谓词）将确保声明给定卷的吊舱仅与该卷位于同一区域中，因为无法跨区域附加卷。
局限性
多区域支持有一些重要限制：
- 我们假设不同的区域在网络中彼此靠近，所以我们不执行任何可感知区域的路由。特别是，通过服务的流量可能会跨越区域（即使支持该服务的某些Pod与客户端位于同一区域中），这可能会导致额外的延迟和成本。
- 卷区域关联性仅适用于PersistentVolume，并且如果直接在Pod规范中指定EBS卷，则将不起作用。
- 群集不能跨越云或区域（此功能将需要完整的联盟支持）。
- 尽管您的节点位于多个区域中，但默认情况下，kube-up当前会构建一个主节点。虽然服务的可用性很高，并且可以容忍区域丢失，但控制平面位于单个区域中。想要高可用性控制平面的用户应遵循高可用性说明。
卷限制
使用拓扑感知的卷绑定解决了以下限制。
- 当前使用动态预配置时的StatefulSet卷区域扩展当前与pod关联性或反关联性策略不兼容。
- 如果StatefulSet的名称包含破折号（“-”），则卷区域扩展可能无法提供跨区域的统一存储分布。
- 在Deployment或Pod规范中指定多个PVC时，需要为特定的单个区域配置StorageClass，或者需要在特定的区域中静态设置PV。另一个解决方法是使用StatefulSet，这将确保副本的所有卷都在同一区域中配置。
