背景
Kubernetes 的设计使得单个 Kubernetes 集群可以跨多个故障区域 multiple failure zones 运行, 通常这些区域 (zones ) 位于称为区域 (region) 的逻辑分组中. 主要的云提供商将一个区域定义为一组故障区域 failure zones(也称为可用性区域 availability zones), 这些区域提供一组一致的功能: 在一个区域内, 每个区域提供相同的 API 和服务.
典型的云架构旨在将一个区域中的故障同时损害另一个区域中的服务的可能性降至最低.
控制平面行为
所有控制平面组件都支持作为一个可交换资源池运行, 每个组件复制一个.
部署群集控制平面时, 请跨多个故障区域放置控制平面组件的副本. 如果可用性是一个重要问题, 请选择至少三个故障区域, 并跨至少三个故障区域复制每个单独的控制平面组件(API 服务器, 调度器, etcd, 群集控制器管理器). 如果您正在运行一个云控制器管理器, 那么您还应该在您选择的所有故障区域中复制它.
注意: Kubernetes 不为 API 服务器端点提供跨区域弹性. 您可以使用各种技术来提高集群 API 服务器的可用性, 包括 DNS 循环, SRV 记录或具有运行状况检查的第三方负载平衡解决方案.
节点行为
Kubernetes 自动将工作负载资源 (如部署或状态集) 的 pod 分布在集群中的不同节点上. 这种传播有助于减少失败的影响.
当节点启动时, 每个节点上的 kubelet 会自动向节点对象添加标签, 该对象在 kubernetesapi 中表示特定的 kubelet. 这些标签可以包含区域信息.
如果集群跨越多个区域或区域, 则可以将节点标签与 Pod 拓扑扩展约束结合使用, 以控制 Pod 如何在容错域 (区域, 区域甚至特定节点) 之间跨集群扩展. 这些提示使调度器能够放置 pod 以获得更好的预期可用性, 从而降低相关故障影响整个工作负载的风险.
例如, 您可以设置一个约束, 以确保 StatefulSet 的 3 个副本都彼此在不同的区域中运行, 只要这是可行的. 您可以声明性地定义它, 而无需显式地定义每个工作负载使用的可用性区域.
跨区域 (Zone) 分布节点
Kubernetes 的核心并不为您创建节点; 您需要自己创建节点, 或者使用集群 API 之类的工具代表您管理节点.
使用诸如 clusterapi 之类的工具, 您可以定义作为集群的工作节点跨多个故障域运行的计算机集, 以及在整个区域服务中断时自动修复集群的规则.
Pods 的手动区域分配
可以将节点选择器约束应用于创建的 Pod, 以及工作负载资源 (如部署, 状态集或作业) 中的 Pod 模板.
区域 (zone) 的存储访问
创建持久卷时, PersistentVolumeLabel 许可控制器会自动向链接到特定区域的任何持久卷添加区域标签. 然后, 调度器通过其 NoVolumeZoneConflict 谓词确保声明给定 PersistentVolume 的 pod 只放置在与该卷相同的区域中.
您可以为 PersistentVolumeClaimes 指定一个 StorageClass, 它指定该类中的存储可能使用的故障域(区域). 要了解如何配置可识别故障域或区域的 StorageClass, 请参阅允许的拓扑.
网络
Kubernetes 本身并不包括区域感知网络. 您可以使用网络插件来配置集群网络, 并且该网络解决方案可能具有特定于区域的元素. 例如, 如果您的云提供商支持 type=LoadBalancer 的服务, 那么负载平衡器可能只向运行在与处理给定连接的负载平衡器元素所在的同一区域中的 pod 发送流量. 有关详细信息, 请查看云提供商的文档.
对于自定义或内部部署, 也需要考虑类似的问题. 服务和入口行为 (包括对不同故障区域的处理) 确实有所不同, 具体取决于集群的设置方式.
故障恢复
在设置集群时, 您可能还需要考虑, 如果某个区域中的所有故障区域同时脱机, 安装程序是否以及如何恢复服务. 例如, 您是否依赖于一个区域中至少有一个节点能够运行 Pods?
确保任何群集关键修复工作都不依赖于群集中至少有一个正常节点. 例如: 如果所有节点都不正常, 则可能需要运行具有特殊容差的修复作业, 以便修复可以完成到足以使至少一个节点投入服务的程度.
Kubernetes 并没有回答这个挑战, 但是, 这是值得考虑的问题.
来源: http://developer.51cto.com/art/202201/697638.htm