通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

治理新式应用程序平台解决方案

  • 项目

云采用框架提供了一种方法，可以系统地逐步改进云产品组合的治理。 本文演示如何将治理方法扩展到部署到 Azure 或其他公有云或私有云的 Kubernetes 群集。

初始治理基础

治理从初始治理基础（通常称为治理 MVP）入手。 该基础部署了跨云环境实现治理所需的基本 Azure 产品。

初始治理基础侧重于治理以下方面：

  • 基本混合网络和连接。
  • Azure 基于角色的访问控制 (RBAC)，用于标识和访问控制。
  • 用于一致标识资源的命名和标记标准。
  • 使用资源组、订阅和管理组的资源的组织。
  • 使用 Azure Policy 强制实施治理策略。

初始治理基础的这些功能可用于治理新式应用程序平台解决方案实例。 但首先，需要向初始基础添加一些组件，以将 Azure Policy 应用于容器。 配置后，可以使用 Azure Policy 和初始治理基础来治理以下类型的容器：

扩展治理规则

初始治理基础可用于扩展各种治理规则，以确保在所有 Kubernetes 实例中采用一致、稳定的部署方法。

可以通过五个不同的视角来查看 Kubernetes 群集的治理。

Azure 资源治理

第一个是 Azure 资源视角。 确保所有群集都符合组织的要求。 这包括网络拓扑、专用群集、SRE 团队的 Azure RBAC 角色、诊断设置、区域可用性、节点池注意事项、Azure 容器注册表治理、Azure 负载均衡器选项、AKS 加载项、诊断设置等概念。 这种治理可确保组织中群集的“外观”和“拓扑”保持一致。 这还应扩展到群集部署启动后，例如必须安装哪些安全代理以及如何对其进行配置。

Snowflake 群集很难在任何中央容量中进行治理。 尽量减少群集之间的差异，以便可以统一应用策略，不建议使用异常群集并且可以检测此类群集。 这可能还包括用于部署群集的技术，例如 ARM、Bicep 或 Terraform。

在管理组/订阅级别应用 Azure Policy 可以帮助提供很多注意事项，但并非全部。

Kubernetes 工作负载治理

由于 Kubernetes 本身是一个平台，因此第二个视角是治理群集中发生的情况。 这包括命名空间指南、网络策略、Kubernetes RBAC、限制和配额等内容。 这是适用于工作负载的治理，而不适用于群集。 每个工作负载都将是唯一的，因为它们都解决了不同的业务问题，并且将采用各种技术以各种方式实现。 可能没有很多“通用”的治理实践，但应该考虑围绕 OCI 项目创建/使用、供应链要求、公共容器注册表使用情况、映像隔离过程、部署管道治理等内容进行治理。

如果可行，也可以考虑围绕常见的工具和模式进行标准化。 提出有关 Helm、服务网格、入口控制器、GitOps 运算符、永久卷等技术的建议。 此处还包括围绕 Pod 托管标识的使用情况和从 Key Vault 获取机密的治理。

推动对遥测访问的强烈期望，确保工作负载所有者能够适当访问改进其产品所需的指标和数据，同时确保群集操作员能够访问系统遥测数据以改进其服务产品。 数据通常需要在两者之间进行交叉关联，确保治理策略就位，从而确保在必要时进行适当的访问。

应用于群集级别 AKS 的 Azure Policy 可以帮助提供其中的一些内容，但不是全部。

群集操作员角色（DevOps、SRE）

第三个视角是围绕群集操作员角色的治理。 SRE 团队如何与群集进行交互？ 该团队与工作负载团队之间的关系是什么。 他们是一样的吗？ 群集操作员应具有明确定义的群集会审活动 playbook，例如他们如何访问群集、从哪里访问群集，以及他们对群集拥有哪些权限，以及何时分配这些权限。 确保在此上下文中围绕工作负载操作员与群集操作员的治理文档、策略和培训材料进行任何区分。 根据你的组织，它们可​​能是相同的。

每个工作负载的群集或每个群集的多个工作负载

第四个视角是对多租户的治理。 也就是说，根据定义，群集是否应该包含完全由同一个工作负载团队拥有的应用程序组成的“相似分组”，并表示一组相关工作负载组件。 或者，根据设计，群集在性质上应该是多租户的，并且具有多个不同的工作负载和工作负载所有者；在组织中像托管服务产品一样运行和管理。 治理策略对于每个策略都明显不同，因此，你应该管理是否强制执行选择的策略。 如果必须同时支持这两种模型，请确保治理计划明确定义了哪些策略适用于哪些类型的群集。

应在策略阶段做出此选择，因为它对人员配备、预算和创新有重大影响。

保持最新工作

第五个视角围绕操作，如节点映像新鲜度（补丁）和 Kubernetes 版本控制。 谁负责节点映像升级、跟踪应用的修补程序、跟踪和组合针对 Kubernetes 和 AKS 常见漏洞和透露的修正计划？ 工作负载团队需要参与验证其解决方案是否适用于群集升级，如果群集不是最新的，它们将无法得到 Azure 支持。 在 AKS 中，围绕“保持最新”工作进行强有力的治理至关重要，Azure 中的大多数其他平台更是如此。 这要求与应用程序团队保持非常紧密的工作关系，并至少每月分配一次专用于工作负载验证的时间，以确保群集保持最新状态。 确保依赖于 Kubernetes 的所有团队都了解这项持续工作的要求和成本，只要他们还在平台上，这项工作就会持续下去。

安全基线

可以将以下最佳做法添加到安全基线中，以考虑 AKS 群集的安全性：

标识

有许多最佳做法可以应用于标识基线，以确保跨 Kubernetes 集群进行一致的标识和访问管理：

后续步骤：管理新式应用程序平台解决方案

以下文章将在云采用旅程中的特定阶段为你提供指导，帮助你在云采用方案中取得成功。