你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
管理新式应用程序平台群集
云采用框架提供了一种核心方法，用于以不可知方式定义云的运营管理过程。 其指导有助于建立运营管理基线和其他专用运营层。 本指南可能适用于混合使用基础结构即服务 (IaaS) 、平台即服务 (PaaS) 和容器化工作负载的组织。 本文概述了为准备容器管理而需要集成到现有运营中的内容。 它还强调了将 Azure Kubernetes Service (AKS) 集成到容器管理策略中的好处。
运营管理需求的业务一致性
容器可删除多个基础结构层上的依赖关系，从而改善了操作管理功能。 若要实现这些运营改进，可能需要修改总体云管理策略，从业务一致性开始。
若要建立适当的运营管理做法，必须了解在云采用计划中将如何使用虚拟桌面，以及想要从这种向容器化工作负载的转移获得哪些好处。
- 你会在云平台中管理多个技术解决方案（如容器、IaaS 和 PaaS）吗？
- 集中式团队会支持容器或 AKS 平台的运营和管理吗？ 这种责任是否转移到单独的工作负载团队？
- 集中式团队是否支持在每个容器或 pod 中运行的工作负载的操作和管理？ 这种责任是否转移到单独的工作负载团队？
- 是否对任务关键型工作负载使用容器？
- 是否只使用容器来实现不太关键的工作负载或实用工作负载以降低成本？
- 单个工作负载的性能和可靠性有多重要？
- 容器中的应用程序是否无状态？ 是否需要保留状态以保护和恢复容器中的工作负载？
这些基本问题将决定如何以最佳方式将容器和 AKS 集成到运营管理策略中。
运营基线
执行操作基线可以集中式访问在云环境中运营和管理所有资产所需的工具。 如果你的非容器化资产没有操作基线，可以执行管理方法中定义的操作基线。
操作基线应包括用于提供可见性、监视、运营符合性、优化和保护/恢复的工具和配置。
以上文章中概述的操作基线不会支持容器或 AKS 平台。 但是，它将提供可以扩展以支持容器的工具基础，如 Azure Monitor、Azure 备份和其他工具。
如果云中的大多数项目都托管在容器中，请考虑在操作基线中包括下一节中的专用平台操作。
平台运营
除非此实现是组织首次或仅部署到云，否则应该具有操作基线。 本部分将介绍一些你可能想要包括的工具来帮助管理容器或 AKS 部署。
清单和可见性
监视容器和 AKS 群集使用操作基线中包含的工具、仪表板和警报。 但是，你可能需要执行更多配置才能将容器中的数据导入到操作监视工具中，例如 容器 Azure Monitor。 请参阅容器 Azure Monitor 概述，收集将容器和 AKS 平台操作添加到操作基线所需的数据。
配置 Azure Monitor 以便在虚拟桌面上收集数据后，可以监视以下区域，作为集中式管理过程的一部分：
- 确定在不同区域中运行的群集，理想情况下绑定到服务树条目并标识这些群集上的关键事实
- 确定群集节点池、网络和这些群集的存储拓扑
- 标识 AKS 版本和节点映像版本分层。
- 确定群集节点资源利用率 (进程、内存和存储)
- 确定节点上运行的容器及其对节点利用率的贡献
- 了解群集在平均负载和最重负载下的行为。 此信息有助于了解容量需求及确定群集可承受的最大负载。
- 配置警报，以便在节点或容器上的 CPU 和内存使用率超过阈值时，或者在基础结构中的群集或节点运行状况汇总中发生运行状况状态更改时，主动通知你或进行记录。
- 使用查询创建一组常见的警报和仪表板，并详细执行详细分析
此数据还会通过提供有关容器化平台上运行的工作负载的详细信息来支持工作负载操作团队：
- 查看在主机上运行的与支持 Pod 的标准过程无关的工作负荷的资源利用率。
- 与 Prometheus 集成以查看应用程序指标。
- 监视部署到 AKS 引擎本地和 Azure Stack 上的 AKS 引擎的容器工作负载。
- 监视部署到 Azure Red Hat OpenShift 的容器工作负载。
- 监视部署到已启用 Azure Arc 的 Kubernetes（预览版）的容器工作负载。
操作符合性
在容器化环境中的几个不同级别进行修补、优化和大小调整。 操作员可能位于许多不同的团队中，具体取决于所需的操作方法。 为了维护运营符合性，操作员将监视使用情况，调整资产大小以平衡性能和成本，并修补基础系统以便最大程度地降低风险和配置偏移。 中心 IT 组织往往会在 IaaS 和 PaaS 解决方案的操作基线中提供这些任务。
在 Azure 中的群集环境中，这些任务在多个级别执行：AKS 群集、节点映像和节点操作系统。 所有这些操作任务都依赖于在群集中或各个节点池上运行的工作负载的理解和工作关系。 以下语句将帮助评估执行容器环境时要执行哪些操作以及是否要执行操作容器环境。
- 如果 AKS 群集的大小调整和修补、节点映像或节点 OS 作为应用程序的部署管道的一部分进行传送，或依赖于应用程序体系结构或配置，则最好将操作符合性转移到工作负载团队进行精细控制。 由于工作负载经常依赖于业务流程功能，这是在意外发生 AKS 版本更改或节点映像更改时最常见的模式，可能会对工作负载或其运行时工具造成灾难性的变化。
- 对于不太常见的集中式群集，支持一系列工作负载和各种应用程序，集中操作团队可能仍负责执行操作相容性任务，以下指南有助于在群集中提供这些任务。 定期执行这些任务为平台特定操作打下基础。 中心运营方法存在明显的风险，在预生产环境中对升级进行周密测试，明确并遵循计划的维护，以及针对不符合要求的工作负载的应变计划都需要准备就绪。 一个坏的升级可能是单一故障点，同样，无法升级的工作负载会导致群集不受支持。 认真规划和管理多租户群集。
对于这两类群集，请按照下面的升级、节点映像和节点 OS 更新的指导进行操作：
保护和恢复
AKS 节点本质上是暂时的，因此不能以单独还原的方式备份。 从事件中恢复可能需要将工作负载重新部署到新的节点池或整个新群集，具体取决于事件的范围。
- 选择将运行时间 SLA 添加到群集。
- 对于更高的 SLA，可能还需要考虑采用多区域 BCDR 最佳方案来提供附加保护。
- 由于群集不应包含状态，因此使用现有操作基线指南处理外部状态还原。 如果已将状态置于群集中，请确保遵循有关存储的最佳实践，并制定策略来备份和还原给定工作负载的这些数据。 使用 Velero 等工具是用于扩展操作基线的平台特定操作的示例。
- 如果应用程序组合的状态不一致，则中心运营团队不应尝试同时维护这两种解决方案。 相反，将对所有容器的所需状态工具链进行标准化，但将备用恢复解决方案的责任转移到工作负载操作团队。 此方法允许开发人员自由设计、保持较低的中心成本，并为工作负荷团队提供符合标准的成本降低奖励。
工作负荷运营
上面的平台运营部分说明了管理 AKS 群集时常见的对话。 Kubernetes 群集是需要集中管理的技术平台吗？ 或者，它们是一种工作负载工具，应该由拥有每个工作负载的团队管理吗？ 对于不同的组织，答案是不同的。 大多数组织一直认为，容器和 AKS 旨在使工作负荷团队能够更灵活地运行每个工作负荷，并为这些工作负荷提供特定功能，以便在其基础中使用这些工作负载，从而使应用程序的所有者和客户受益。
工作负荷操作可以基于现有操作基线和特定于平台的操作进行构建。 你还可以使用完全分散的工作负荷操作来安全地操作 AKS 群集。 在任一情况下，当需要提升运营以专注于特定工作负荷的特定结果时，可以使用 Azure 架构良好的框架和 Microsoft Azure 架构良好的评审来具体了解用于工作负荷的运营过程和工具的类型。
下一步：下一个迁移迭代
新式应用程序平台迁移完成后，云采用团队即可开始下一次特定于方案的迁移。 或者，如果要迁移其他平台，则可以再次使用本文系列来指导您下一次的新式应用程序平台迁移或部署。