多层次 AKS 应用程序的高可用性

Azure Cosmos DB

Azure 磁盘存储

Azure 文件

Azure Kubernetes 服务 (AKS)

Azure 负载均衡器

本指南讨论 Azure Kubernetes 服务 (AKS) 群集中多层应用程序部署的高可用性 (HA) 问题。 本文介绍 Kubernetes HA 机制和构造，并提供用于识别和消除单一 HA 故障点的清单和指南。

要为 AKS 应用程序实现 HA，有两项基本任务。

• 识别应用程序中的所有单一故障点。
• 消除单一故障点。

消除单一故障点需要使用 HA 解决方案。

四个 HA 要素

对于所有高可用性系统而言，都有四个 HA 要素：

• 冗余
• 监视
• 恢复
• 检查点

考虑多层 AKS 应用程序，在此类应用程序中，流量会到达业务逻辑层、数据层会保留状态，而应用程序将返回对用户的响应。

识别单一故障点

要识别单一故障点，请首先确定客户端请求与为这些请求提供服务的组件之间的关键路径。 此路径上的任何不受四大 HA 要素管制的组件，或者不受其中三大要素管制的无状态组件（没有检查点）都是单一故障点。 如果不受监视，那么即使是复制的组件也会被视为单一故障点，因为其故障是静默且不被检测到的。

消除单一故障点

若要消除单一故障点，请部署应用程序以复制关键路径组件，并使用负载均衡器、监视和恢复机制。 Kubernetes 可以处理所有这些活动。

下载此图的 Visio 文件。

在复制的应用程序中：

• 根据每个组件的性能和工作负载，复制具有不同数量副本的业务层组件。
• 还可以在负载均衡器后面复制数据层。

Kubernetes 提供了多种构造和机制（例如负载均衡和运行情况探测），有助于掌握 HA 要素。 以下清单和讨论将这些构造和机制分为对应于四大 HA 要素的类别。

Kubernetes HA 清单

除了状态管理之外，Kubernetes 还执行维护应用程序 HA 的特殊作业。 HA 清单列出了可用于优化 Kubernetes HA 管理的常见配置。 若要使用清单，请根据以下机制和构造对自己的 Kubernetes 部署进行评估，并落实缺少的部分。

HA 要素	解决方案
冗余	☐ Kubernetes 控制器类型 ☐ 副本数 ☐ 计划反相关性
监视	☐ 运行情况探测 ☐ 就绪情况探测 ☐ 启动探测
恢复	☐ 服务类型 ☐ 选主 ☐ 重启策略 ☐ 预停止挂钩
检查点	☐ 永久卷声明 ☐ 永久卷

冗余

冗余可缓解单一故障点的影响。 需要在应用程序的所有层之间实现冗余。 若要实现冗余，请使用一个或多个相同副本复制给定层的组件。

• 控制器类型，配置 。 Kubernetes 提供了多个可管理应用程序 Pod 生命周期的控制器。 最常用的控制器是 Deployment。 其他控制器包括 Statefulset，在恢复后急需维护 Pod 标识时，它会派上用场。 其他控制器（如 Replicasets）不提供与部署提供的相同的有用功能（如回滚）。

• 副本数，配置 。 为了采用冷备用模型而特意将副本数设置为仅一个。 冷备用意味着发生故障时，新实例会从头开始，这会影响可用性。 此模型可能适用于具有低数据量工作负载的组件，但请考虑复制无状态、高数据量组件的情况。

  通过指定资源请求限制（即 spec.containers[].resources），可以添加横向 Pod 自动缩放 (HPA)，这会让 Kubernetes 根据定义的资源利用率阈值自动纵向扩展或缩减副本数。 HPA 有助于避免负载激增导致应用程序由于过载而无法满足请求的情况。

• 计划反相关性，配置 。 典型的生产级 Kubernetes 群集的节点分布在多个可用性区域间，用 topologyKey 表示。 同一部署的 Pod 之间应具有首选反相关性或软反相关性。 此配置确保能在不同可用性区域中的节点上计划 Pod。

  AKS 群集可以有多个节点池，每个节点池具有不同的 虚拟机规模集大小和规格。 例如，可以在具有快速固态硬盘 (SSD) 的节点上托管数据库 Pod，并在具有图形处理单元 (GPU) 的节点上托管机器学习 Pod。

监视

如果没有监视，冗余可能会变得无效。 需要采用稳定的监视机制，以确保工作负载达到正常的副本。

• 运行情况探测，配置 ，监视 Pod 的运行状况。 如果容器崩溃或退出，Kubernetes 可以检测到它。 运行失败时，Kubernetes 会重启容器。

• 就绪情况探测，配置 ，确定是否将流量发送到 Pod。 如果部署的任何 Pod 尚未准备就绪，则不属于抽象部署的 Kubernetes 服务终结点，因此没有作用。 请务必仔细设置就绪情况探测，因为它们不会触发重启，而是用于在准备就绪之前阻止 Pod 接收流量。

• 启动探测，配置 ，主要防止慢速启动应用程序中的就绪情况和运行情况出现误报。 启动探测成功后，运行情况探测将启动。

Azure 提供了更深入的见解，可用于设置基于群集运行状况的警报。

恢复

监视的主要目的是在检测到故障时触发恢复。 恢复过程涉及三个阶段：

1. 隔离和重定向：确保故障副本未接收流量，并将工作负载定向到正常的副本。
2. 修复：重启故障副本，该副本可以修复暂时性错误。
3. 重新加入：修复后，如果监视认为副本正常，则将该副本重新加入到处理工作负载的副本中。

• 服务类型，配置 。 通过服务公开 Pod 可以分类为冗余和恢复。 但是，在某些情况下，你可能具有单副本部署。 就算没有负载均衡，通过服务公开 Pod 也有好处。

  服务的主要优点是使用 Kubernetes 服务终结点自动更新域名服务 (DNS) 条目。 就绪情况探测失败的容器所属的 Pod 不会通过 AKS 接收流量。 尽管 Kubernetes 群集 IP 服务的负载均衡能力是很基础的，但可以将无外设服务与入口或其他服务网格解决方案耦合，以更好地平衡负载分布。

  Kubernetes 不涵盖外部流量触达 AKS 群集的方式。 可以使用 Azure 应用程序网关等服务处理外部流量。

• 选主。 某些组件最好部署为单一实例。 计划程序就是这样的组件，因为两个活动计划程序可能会冲突。 使用单一实例会使应用程序面临冷备用问题。 若要启用 Pod 的热备用状态，可以进行选主，仅由一个 Pod（主 Pod）处理请求。

• 重启策略，配置 。 重启策略适用于 Pod 中的所有容器。 应具备将此属性设置为 Never 的正当理由。 某些容器每次启动时都会联系许可证服务器，你可能希望避免过度重启的附加成本。

• 预停止挂钩，配置 。 在将 SIGTERM 信号发送到容器之前运行预停止挂钩。 预停止脚本就像 30 秒睡眠命令一样简单。

  例如，当由 HPA 管理的应用程序纵向缩减时，正在进行的请求可能会突然终止，除非应用程序有一个 SIGTERM 处理程序（该处理程序会在退出前完成对请求的服务）。 预停止挂钩会从服务终结点中删除 Pod 终结点（从而删除 DNS 条目）。 在预停止挂钩运行时，无法将新请求发送到 Pod。 预停止挂钩允许 Pod 完成其正在处理的请求，且不会接收新请求。 预停止挂钩是一种简单方法，可最大程度地减少未被处理好的请求，且无需修改应用程序代码。

检查点

新式应用程序有许多无状态组件，但完全无状态的应用程序仍然很少见。 大多数应用程序在数据层中检查其状态。 Kubernetes 有意地不提供任何处理应用程序状态的机制。 状态管理是不属于容器管理的复杂任务。

可以在三个级别中保存应用程序状态：

• 数据记录级别将数据存储在数据库中。 每个数据库记录都可以跨多个数据库实例复制。 数据库记录是持久保存状态的主要形式，尤其是保存在 Azure Cosmos DB 等托管云数据库中。

• 文件系统级别通常复制数据文件，例如预写日志记录 (WAL) 文件。 大多数云提供商为其解决方案提供插件（例如Azure 文件存储）。

• 磁盘级别在块级别保留数据，可以灵活地定义要使用的文件系统，就像在 Azure 磁盘存储中一样。

Kubernetes 卷、永久卷和永久卷声明可以在文件系统或磁盘级别保留应用程序的状态。 存储状态的最常用模式仍然是数据记录级别。

HA 和 DR

在 HA 和灾难恢复 (DR) 中，网络拓扑和负载均衡解决方案的选择非常重要。

但是，DR 需要在整个服务级别部署多区域服务，并在 Azure 区域之间使用负载均衡解决方案。 应用程序分散在多个区域，或者在每个区域中部署一个完整的应用程序实例。 该选择取决于应用程序类型、应用程序体系结构以及组件之间的延迟容忍度。

HA 没有使用多个区域，而是使用 Azure 区域中的多区域部署，并从中中受益 下图说明了 HA 和 DR 的可用性区域与区域之间的差异。

下载此体系结构的 Visio 文件。

本指南重点介绍一个 AKS 群集内应用程序级别的 HA。 有关 AKS 多群集部署中的 DR 的详细信息，请参阅适用于多区域群集的 AKS 基线。

其他注意事项

• 若要维护应用程序 HA，请确保 Kubernetes 控制平面（包括 API 服务器和控制器管理器）高度可用。 请考虑使用 AKS 运行时间 SLA 来保证 HA。

• 资源整合策略直接违反 HA 冗余要素。 因此应仔细分析冗余成本。 Azure 定价计算器可以提供帮助。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Ali Kanso | 首席软件工程师

其他参与者：

• Karthik Sankara Subramanian | 软件工程师 II
• Kinshuman Patra | 合作伙伴组工程经理
• Ayobami Ayodeji | 高级项目经理
• Oscar L Pla Alvarez | 域解决方案架构师

若要查看非公开领英个人资料，请登录领英。

后续步骤

• 高可用性 Kubernetes 群集模式
• 区域和可用性区域
• Azure Kubernetes 服务 (AKS) 中的配额、虚拟机大小限制和区域可用性
• 协调安排微服务和多容器应用程序，实现高可伸缩性和高可用性
• Azure Kubernetes 服务 (AKS) 群集体系结构和操作

相关资源

• 多区域群集的 AKS 基线
• Azure Kubernetes 服务上的微服务体系结构
• Azure 架构良好的框架评审 - Azure Kubernetes 服务 (AKS)

本指南讨论 Azure Kubernetes 服务 (AKS) 群集中多层应用程序部署的高可用性 (HA) 问题。 本文介绍 Kubernetes HA 机制和构造，并提供用于识别和消除单一 HA 故障点的清单和指南。

要为 AKS 应用程序实现 HA，有两项基本任务。

• 识别应用程序中的所有单一故障点。
• 消除单一故障点。

消除单一故障点需要使用 HA 解决方案。

四个 HA 要素

对于所有高可用性系统而言，都有四个 HA 要素：

• 冗余
• 监视
• 恢复
• 检查点

考虑多层 AKS 应用程序，在此类应用程序中，流量会到达业务逻辑层、数据层会保留状态，而应用程序将返回对用户的响应。

识别单一故障点

要识别单一故障点，请首先确定客户端请求与为这些请求提供服务的组件之间的关键路径。 此路径上的任何不受四大 HA 要素管制的组件，或者不受其中三大要素管制的无状态组件（没有检查点）都是单一故障点。 如果不受监视，那么即使是复制的组件也会被视为单一故障点，因为其故障是静默且不被检测到的。

消除单一故障点

若要消除单一故障点，请部署应用程序以复制关键路径组件，并使用负载均衡器、监视和恢复机制。 Kubernetes 可以处理所有这些活动。

下载此图的 Visio 文件。

在复制的应用程序中：

• 根据每个组件的性能和工作负载，复制具有不同数量副本的业务层组件。
• 还可以在负载均衡器后面复制数据层。

Kubernetes 提供了多种构造和机制（例如负载均衡和运行情况探测），有助于掌握 HA 要素。 以下清单和讨论将这些构造和机制分为对应于四大 HA 要素的类别。

Kubernetes HA 清单

除了状态管理之外，Kubernetes 还执行维护应用程序 HA 的特殊作业。 HA 清单列出了可用于优化 Kubernetes HA 管理的常见配置。 若要使用清单，请根据以下机制和构造对自己的 Kubernetes 部署进行评估，并落实缺少的部分。

HA 要素	解决方案
冗余	☐ Kubernetes 控制器类型 ☐ 副本数 ☐ 计划反相关性
监视	☐ 运行情况探测 ☐ 就绪情况探测 ☐ 启动探测
恢复	☐ 服务类型 ☐ 选主 ☐ 重启策略 ☐ 预停止挂钩
检查点	☐ 永久卷声明 ☐ 永久卷

冗余

冗余可缓解单一故障点的影响。 需要在应用程序的所有层之间实现冗余。 若要实现冗余，请使用一个或多个相同副本复制给定层的组件。

• 控制器类型，配置 。 Kubernetes 提供了多个可管理应用程序 Pod 生命周期的控制器。 最常用的控制器是 Deployment。 其他控制器包括 Statefulset，在恢复后急需维护 Pod 标识时，它会派上用场。 其他控制器（如 Replicasets）不提供与部署提供的相同的有用功能（如回滚）。

• 副本数，配置 。 为了采用冷备用模型而特意将副本数设置为仅一个。 冷备用意味着发生故障时，新实例会从头开始，这会影响可用性。 此模型可能适用于具有低数据量工作负载的组件，但请考虑复制无状态、高数据量组件的情况。

  通过指定资源请求限制（即 spec.containers[].resources），可以添加横向 Pod 自动缩放 (HPA)，这会让 Kubernetes 根据定义的资源利用率阈值自动纵向扩展或缩减副本数。 HPA 有助于避免负载激增导致应用程序由于过载而无法满足请求的情况。

• 计划反相关性，配置 。 典型的生产级 Kubernetes 群集的节点分布在多个可用性区域间，用 topologyKey 表示。 同一部署的 Pod 之间应具有首选反相关性或软反相关性。 此配置确保能在不同可用性区域中的节点上计划 Pod。

  AKS 群集可以有多个节点池，每个节点池具有不同的 虚拟机规模集大小和规格。 例如，可以在具有快速固态硬盘 (SSD) 的节点上托管数据库 Pod，并在具有图形处理单元 (GPU) 的节点上托管机器学习 Pod。

监视

如果没有监视，冗余可能会变得无效。 需要采用稳定的监视机制，以确保工作负载达到正常的副本。

• 运行情况探测，配置 ，监视 Pod 的运行状况。 如果容器崩溃或退出，Kubernetes 可以检测到它。 运行失败时，Kubernetes 会重启容器。

• 就绪情况探测，配置 ，确定是否将流量发送到 Pod。 如果部署的任何 Pod 尚未准备就绪，则不属于抽象部署的 Kubernetes 服务终结点，因此没有作用。 请务必仔细设置就绪情况探测，因为它们不会触发重启，而是用于在准备就绪之前阻止 Pod 接收流量。

• 启动探测，配置 ，主要防止慢速启动应用程序中的就绪情况和运行情况出现误报。 启动探测成功后，运行情况探测将启动。

Azure 提供了更深入的见解，可用于设置基于群集运行状况的警报。

恢复

监视的主要目的是在检测到故障时触发恢复。 恢复过程涉及三个阶段：

1. 隔离和重定向：确保故障副本未接收流量，并将工作负载定向到正常的副本。
2. 修复：重启故障副本，该副本可以修复暂时性错误。
3. 重新加入：修复后，如果监视认为副本正常，则将该副本重新加入到处理工作负载的副本中。

• 服务类型，配置 。 通过服务公开 Pod 可以分类为冗余和恢复。 但是，在某些情况下，你可能具有单副本部署。 就算没有负载均衡，通过服务公开 Pod 也有好处。

  服务的主要优点是使用 Kubernetes 服务终结点自动更新域名服务 (DNS) 条目。 就绪情况探测失败的容器所属的 Pod 不会通过 AKS 接收流量。 尽管 Kubernetes 群集 IP 服务的负载均衡能力是很基础的，但可以将无外设服务与入口或其他服务网格解决方案耦合，以更好地平衡负载分布。

  Kubernetes 不涵盖外部流量触达 AKS 群集的方式。 可以使用 Azure 应用程序网关等服务处理外部流量。

• 选主。 某些组件最好部署为单一实例。 计划程序就是这样的组件，因为两个活动计划程序可能会冲突。 使用单一实例会使应用程序面临冷备用问题。 若要启用 Pod 的热备用状态，可以进行选主，仅由一个 Pod（主 Pod）处理请求。

• 重启策略，配置 。 重启策略适用于 Pod 中的所有容器。 应具备将此属性设置为 Never 的正当理由。 某些容器每次启动时都会联系许可证服务器，你可能希望避免过度重启的附加成本。

• 预停止挂钩，配置 。 在将 SIGTERM 信号发送到容器之前运行预停止挂钩。 预停止脚本就像 30 秒睡眠命令一样简单。

  例如，当由 HPA 管理的应用程序纵向缩减时，正在进行的请求可能会突然终止，除非应用程序有一个 SIGTERM 处理程序（该处理程序会在退出前完成对请求的服务）。 预停止挂钩会从服务终结点中删除 Pod 终结点（从而删除 DNS 条目）。 在预停止挂钩运行时，无法将新请求发送到 Pod。 预停止挂钩允许 Pod 完成其正在处理的请求，且不会接收新请求。 预停止挂钩是一种简单方法，可最大程度地减少未被处理好的请求，且无需修改应用程序代码。

检查点

新式应用程序有许多无状态组件，但完全无状态的应用程序仍然很少见。 大多数应用程序在数据层中检查其状态。 Kubernetes 有意地不提供任何处理应用程序状态的机制。 状态管理是不属于容器管理的复杂任务。

可以在三个级别中保存应用程序状态：

• 数据记录级别将数据存储在数据库中。 每个数据库记录都可以跨多个数据库实例复制。 数据库记录是持久保存状态的主要形式，尤其是保存在 Azure Cosmos DB 等托管云数据库中。

• 文件系统级别通常复制数据文件，例如预写日志记录 (WAL) 文件。 大多数云提供商为其解决方案提供插件（例如Azure 文件存储）。

• 磁盘级别在块级别保留数据，可以灵活地定义要使用的文件系统，就像在 Azure 磁盘存储中一样。

Kubernetes 卷、永久卷和永久卷声明可以在文件系统或磁盘级别保留应用程序的状态。 存储状态的最常用模式仍然是数据记录级别。

HA 和 DR

在 HA 和灾难恢复 (DR) 中，网络拓扑和负载均衡解决方案的选择非常重要。

但是，DR 需要在整个服务级别部署多区域服务，并在 Azure 区域之间使用负载均衡解决方案。 应用程序分散在多个区域，或者在每个区域中部署一个完整的应用程序实例。 该选择取决于应用程序类型、应用程序体系结构以及组件之间的延迟容忍度。

HA 没有使用多个区域，而是使用 Azure 区域中的多区域部署，并从中中受益 下图说明了 HA 和 DR 的可用性区域与区域之间的差异。

下载此体系结构的 Visio 文件。

本指南重点介绍一个 AKS 群集内应用程序级别的 HA。 有关 AKS 多群集部署中的 DR 的详细信息，请参阅适用于多区域群集的 AKS 基线。

其他注意事项

• 若要维护应用程序 HA，请确保 Kubernetes 控制平面（包括 API 服务器和控制器管理器）高度可用。 请考虑使用 AKS 运行时间 SLA 来保证 HA。

• 资源整合策略直接违反 HA 冗余要素。 因此应仔细分析冗余成本。 Azure 定价计算器可以提供帮助。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

• Ali Kanso | 首席软件工程师

其他参与者：

• Karthik Sankara Subramanian | 软件工程师 II
• Kinshuman Patra | 合作伙伴组工程经理
• Ayobami Ayodeji | 高级项目经理
• Oscar L Pla Alvarez | 域解决方案架构师

若要查看非公开领英个人资料，请登录领英。

后续步骤

• 高可用性 Kubernetes 群集模式
• 区域和可用性区域
• Azure Kubernetes 服务 (AKS) 中的配额、虚拟机大小限制和区域可用性
• 协调安排微服务和多容器应用程序，实现高可伸缩性和高可用性
• Azure Kubernetes 服务 (AKS) 群集体系结构和操作

相关资源

• 多区域群集的 AKS 基线
• Azure Kubernetes 服务上的微服务体系结构
• Azure 架构良好的框架评审 - Azure Kubernetes 服务 (AKS)