运行于多可用区环境

Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行，通常这些区位于某个称作 区域（region） 逻辑分组中。主要的云提供商都将区域定义为一组失效区的集合（也称作 可用区（Availability Zones）），能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。

典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。

控制面行为

所有的控制面组件都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。

当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本，跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将该组件跨所选的三个失效区来部署。

说明：

Kubernetes 并不会为 API 服务器端点提供跨失效区的弹性。你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用 DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。

节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象添加标签。这些标签可能包含。

如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合 Pod 拓扑分布约束来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是地理区域、可用区甚至是特定节点。这些提示信息使得能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载带来的风险。

例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束，而不需要显式指定每个工作负载使用哪些可用区。

Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用类似这类工具来替你管理节点。

使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。

为 Pods 手动指定区

你可以应用到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源中的 Pod 模板设置此类约束。

你可以为 PersistentVolumeClaim 指定以设置该类中的存储可以使用的失效域（区）。要了解如何配置能够感知失效域或区的 StorageClass，请参阅可用的拓扑逻辑。

网络

Kubernetes 自身不提供与可用区相关的联网配置。你可以使用网络插件来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。例如，如果你的云提供商支持的 Service，则负载均衡器可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。请查阅云提供商的文档了解详细信息。

对于自定义的或本地集群部署，也可以考虑这些因素 Ingress 的行为，包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。

在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何恢复服务。例如，你是否要求在某个区中至少有一个节点能够运行 Pod？请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job，该 Job 要设置特定的容忍度以便修复操作能够至少将一个节点恢复为可用状态。

Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。

接下来

要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅调度与驱逐。