Azure 上任务关键型工作负载的操作

与使用任何应用程序一样，任务关键型工作负荷会发生更改。 随着时间推移，密钥将过期，修补程序将发布，等等。 应使用部署管道应用所有更改和维护。 本文提供有关进行常见更改和更新的操作指南。

组织一致性对操作过程同样重要。 对于任务关键型工作负荷的操作成功而言，将端到端责任集中于一个团队，即 DevOps 团队，是至关重要的。

技术执行应利用 Azure 原生平台功能，并使用自动化 Azure Pipelines 将更改部署到应用程序、基础设施和配置中。 同样，应自动执行维护任务，应避免手动任务。

以下部分介绍了处理不同类型的更改的方法。

应用程序自动化

持续集成和持续部署（CI/CD）可正确部署和验证任务关键型工作负荷。 CI/CD 是将更改部署到任何环境、开发/测试、生产和其他环境的首选方法。 对于任务关键型工作负荷，以下部分中所列的更改应会导致部署全新的部署标记。 在流量通过蓝/绿部署策略路由到标记之前，应全面测试新的部署标记作为发布过程的一部分。

以下部分介绍应尽可能通过 CI/CD 实现的更改。

应用程序更改

应通过 CI/CD 部署对应用程序代码的所有更改。 应根据回归对代码进行生成、Lint 分析和测试。 应监视应用依赖关系，例如运行时环境或包，并通过 CI/CD 部署进行更新。

基础结构更改

基础结构应建模和预配为代码。 这种做法通常称为基础结构即代码（IaC）。 应通过 CI/CD 管道部署对 IaC 的所有更改。 对基础结构的更新（例如修补 OS）也应通过 CI/CD 管道进行管理。

配置更改

配置更改是应用程序中断的常见原因。 若要应对这些中断，应将应用程序或基础结构的配置捕获为代码。 这种做法称为“配置即代码”（CaC）。 应通过 CI/CD 管道部署对 CaC 的更改。

库文件/SDK 更新

对于任务关键型应用程序，当新版本可用时，源代码和依赖项必须更新。 建议的方法是利用源代码存储库中的配置管理更改过程。 应将其配置为自动为各种依赖项更新创建拉取请求，例如：

• .NET NuGet 包
• JavaScript Node 包管理器包
• Terraform 提供程序

以下方法演示如何在 GitHub 存储库中使用 dependabot 自动执行库更新。

1. Dependabot 检测应用程序代码中使用的库和 SDK 的更新

2. Dependabot 更新分支中的应用程序代码，并使用针对主分支进行的这些更改创建拉取请求 (PR)。 PR 包含所有相关信息，并已准备好进行最终评审。

   

3. 完成代码评审和测试后，可以将 PR 合并到主分支。

对于依赖项 dependabot 无法监视，请确保有进程来检测新版本。

密钥/机密/证书轮换

轮换（续订）密钥和机密应该是任何工作负荷中的标准过程。 在公开或定期作为良好的安全做法后，可能需要在短时间内更改机密。

由于过期或无效的机密可能会导致应用程序 （请参阅故障分析）中断，因此必须有一个明确定义和经过验证的过程。 对于 Azure 任务关键型工作负载，印花预计只会生存几个星期。 因此，不需关注如何轮换印花资源的机密。 如果一个印章中的密钥失效，整个应用程序将继续运行。

但是，管理用于访问长期全球资源的机密至关重要。 一个值得注意的示例是 Azure Cosmos DB API 密钥。 如果 Azure Cosmos DB API 密钥过期，则所有戳记都会同时受到影响，并导致应用程序完全中断。

以下方法是一种 Azure 任务关键型测试和记录的方法，用于轮换 Azure Cosmos DB 密钥，而不会导致 Azure Kubernetes 服务中运行的服务停机。

1. 使用辅助密钥更新戳记。 默认情况下，Azure Cosmos DB 的主 API 密钥以机密的形式存储在 Azure Key Vault 中（在每个印花中）。 创建一个 PR 来更新 IaC 模板代码，它使用辅助 Azure Cosmos DB API 密钥。 通过常规 PR 评审和更新过程运行此更改，以将其部署为新版本或修补程序。

2. （可选）如果将更新作为修补程序部署到现有版本，Pod 会在几分钟后自动从 Azure Key Vault 获取新机密。 但是，Azure Cosmos DB 客户端代码当前不会使用更改的密钥重新初始化。 若要解决此问题，请使用群集上的以下命令手动重启所有 Pod：

   kubectl rollout restart deployment/CatalogService-deploy -n workload
   kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload
   kubectl rollout restart deployment/healthservice-deploy -n workload
   

3. 新部署的或重启的 Pod 现在使用辅助 API 密钥连接到 Azure Cosmos DB。

4. 当所有部署标记上的 Pod 重启完毕，或部署了新的部署标记后，请重新生成 Azure Cosmos DB 的主 API 密钥。 使用以下命令模式：

   az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup
   

5. 更改 IaC 模板以将主 API 密钥用于将来的部署。 或者，可以继续使用辅助密钥，并在续订辅助密钥时切换回主 API 密钥。

警报

警报是了解环境是否存在问题以及何时出现问题的关键。 应通过 CI/CD 管道实现对警报和/或操作组的更改。 有关警报的详细信息，请参阅 Azure 上任务关键型工作负载的运行状况建模和可观测性。

自动化

在 Azure 上运行的许多平台和服务为常见操作活动提供自动化。 此自动化包括自动缩放和密钥和证书的自动处理。

扩展

在应用程序设计过程中，应确定将作为一个整体的印花的缩放单元进行定义的缩放要求。 邮票中的单个服务需要能够横向扩展以满足高峰需求，或缩小规模以节省资金或资源。

没有足够的资源的服务可能会表现出不同的副作用，包括以下列表：

• 处理来自队列/项目/分区的消息的 Pod 数量不足，导致越来越多的未处理的消息。 这一结果有时称为队列深度的增长。
• Azure Kubernetes 服务节点上的资源不足可能会导致 Pod 无法运行。
• 以下情况会导致请求受到限制：
  • Azure Cosmos DB 的请求单位（RU）不足
  • 事件中心高级层的处理单位 (PU) 不足，或标准层的吞吐量单位 (TU) 不足
  • 服务总线高级层的消息传送单元 (MU) 不足

尽可能利用服务的以下自动缩放功能，确保有足够的资源来满足需求：

• 水平 Pod 自动缩放允许你根据需求增加或减少运行工作负荷的 Pod 数。
• AKS 群集自动缩放程序 允许根据需求增加或减少群集中的节点数。
• 可以自动纵向扩展 Azure 事件中心吞吐量单位（标准层）
• 可以自动更新 Azure 服务总线命名空间的消息传送单元

管理密钥、机密和证书

尽可能使用托管标识，以避免管理 API 密钥或机密（如密码）。

使用密钥、机密或证书时，请尽可能使用 Azure 本机平台功能。 这些平台级功能包括以下示例：

• Azure Front Door 具有 TLS 证书管理和续订的内置功能。
• Azure Key Vault 支持自动密钥轮换。

手动操作

存在需要手动干预的操作活动。 应测试这些进程。

死信消息

无法处理的消息应路由到死信队列，并为该队列配置警报。 这些消息通常需要手动干预才能理解和缓解问题。 应构建查看、更新和重播死信消息的功能。

Azure Cosmos DB 还原

当意外删除、更新或损坏 Azure Cosmos DB 数据时，需要从定期备份执行还原。 只能通过支持案例从定期备份进行还原。 此过程应记录并定期测试。

配额增加

Azure 订阅具有配额限制。 达到这些限制时，部署可能会失败。 某些配额是可调整的。 对于可调整的配额，可以从 Azure 门户上的 “我的配额”页上请求增加配额。 对于不可调整的配额，需要提交支持请求。 Azure 支持团队与你合作查找解决方案。

贡献者

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• 艾伦·苏德布林 |高级内容开发人员

若要查看非公共LinkedIn个人资料，请登录 LinkedIn。

后续步骤