通过用于 Kubernetes 的 Azure Policy 配置 AKS 资源配额策略

  • 10 分钟

Azure Policy 有助于你强制执行标准并大规模评估云环境是否符合条件。 对公司而言，实施业务规则来定义员工该如何使用组织中的公司软件、硬件和其他资源，这是一种不错的做法。 因此，企业使用策略来强制要求、审查和定义访问权限。 策略可帮助组织满足监管和法律要求、实施最佳做法和制定组织约定。

借助 Azure Kubernetes 服务 (AKS)，可通过策略高效地协调云原生应用程序。 你意识到，你需要强制执行业务规则来管理团队对 AKS 的使用，确保使用的方法经济高效。 在基于 Azure 的云资源方面，你决定使用 Azure Policy 在其中运用此构思。

在讨论如何使用用于 Kubernetes 的 Azure Policy 之前，应了解一些从 Kubernetes 内启用此功能的概念。

什么是 Kubernetes 准入控制器？

准入控制器是一种 Kubernetes 插件，用于在请求的 Kubernetes 对象暂留之前，截获针对 Kubernetes API 的已验证和已授权的请求。 例如，假设你部署了一个新的工作负载，而且部署中包含一个具有特定内存要求的 Pod 请求。 准入控制器会截获该部署请求，必须先授权部署，然后再将它保存到群集。

你可将准入控制器视为控制和强制执行使用和设计群集的方式的软件。 它限制了对创建、删除和修改 Kubernetes 对象的请求。

什么是准入控制器 Webhook？

准入控制器 Webhook 是一个 HTTP 回调函数，用于接收准入请求，然后对这些请求进行处理。 需要在运行时配置准入控制器。 这些控制器可用于编译的准入插件，或者用作作为 Webhook 运行的已部署扩展。

准入 Webhook 有两种类型：验证型 Webhook 或修改型 Webhook。 首先调用修改型 Webhook，可以更改并应用发送到 API 服务器的对象上的默认值。 验证型 Webhook 验证对象值，可以拒绝请求。

什么是开放策略代理 (OPA)？

开放策略代理 (OPA) 是一个开源的通用策略引擎，为你提供了一种用于编写策略的高级声明性语言。 这些策略允许你定义监视系统行为方式的规则。

什么是 OPA Gatekeeper？

OPA Gatekeeper 是一种开放源代码验证型 Kubernetes 准入控制器 Webhook，可强制执行基于自定义资源定义 (CRD) 且遵循 OPA 语法的策略。

OPA Gatekeeper 的目标是使你能够使用配置而不是硬编码的服务策略规则来自定义准入策略。 由此，你还可全面了解群集，确定违反策略的资源。

使用 OPA Gatekeeper 定义组织范围的策略，规则如下：

  • 对所有已配置的 Pod 强制实施最大资源限制，例如 CPU 和内存限制。

  • 仅允许从已批准的存储库部署映像。

  • 群集中所有命名空间的标签命名约定必须指定每个命名空间的联系点。

  • 强制要求群集服务具有全局唯一的选择器。

适用于 AKS 的 Azure Policy

Azure Policy 扩展了 OPA Gatekeeper 版本 3，并通过内置策略与 AKS 集成。 这些策略以集中且一致的方式在群集上应用大规模强制和保护措施。

你公司的开发团队希望优化开发并引入开发工具（如 DevSpaces），以简化其 Kubernetes 开发工作流。 你需要确保团队成员遵守其项目的特定资源限制。 你决定采用定义开发命名空间中允许的计算资源、存储资源和对象计数的策略。

若要设置资源限制，可在命名空间级别应用资源配额，并监视资源使用情况以调整策略配额。 使用此策略可在开发团队中保留和限制资源。

如何启用用于 AKS 的 Azure Policy 加载项

注册用于 AKS 的 Azure Policy 加载项的功能时，有几个步骤。 我们将在此处提供示例，但实际上你将完成下一单元中的步骤。

  1. 使用 az provider register 命令注册两个资源提供程序：

    • Microsoft.ContainerService 和 Microsoft.PolicyInsights：这些资源提供程序支持查询策略事件相关信息和管理容器等操作。 这些是用于查询、创建、更新或删除策略修正的操作。

    下面是这两个注册命令的示例：

    az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.PolicyInsights

  2. 向 Microsoft. ContainerService 资源提供程序注册 AKS-AzurePolicyAutoApprove 功能。 下面是该命令的示例：

    az feature register --namespace Microsoft.ContainerService --name AKS-AzurePolicyAutoApprove

  3. 确认成功注册此功能后，运行带 --namespace 参数的 az provider register 命令，以传播新功能注册。 下面是该命令的示例：

    az provider register -n Microsoft.ContainerService

  4. 启用 Azure Policy 加载项：

    az aks enable-addons \
    --addons azure-policy \
    --name myAKSCluster \
    --resource-group myResourceGroup

    激活加载项将在群集上的两个命名空间中调度工作负载。 第一个命令空间是 kube-system，其中包含 azure-policy 和 azure-policy-webhook。 第二个命令空间是 gatekeeper-system，其中包含 gatekeeper-controller-manager。 这些工作负载负责计算提交到 AKS 控制平面的请求。 根据已配置的策略，策略 Webhook 可以允许或拒绝请求。

分配内置策略定义

使用 Azure Policy 合规性仪表板管理 Azure 环境的策略。 通过仪表板，可向下钻取到每个资源和每个策略级别的详细信息。 它可对现有资源使用批量修正并为新资源使用自动修正，使你的资源符合要求。

对于每个策略，将列出以下概述信息：

项 说明 示例
Name 策略的名称。 [预览版]：确保容器的 CPU 和内存资源限制不超过 Kubernetes 群集中指定的限制”的策略。
范围 此策略应用到的订阅资源组。 mySubscription/rg-akscostsaving.
符合性状态 已分配策略的状态。 “符合”、“冲突”、“未开始”或“未注册”。
资源符合性 符合策略的资源百分比。 此计算将考虑符合、不符合和有冲突的资源。 100
不符合的资源 违反了一个或多个策略规则的唯一资源数。 3
不符合的策略 不符合策略的数目。 5

在此，可向下钻取已触发事件的每个资源和每个策略的详细信息。 例如，可检查遭到拒绝的工作负载部署的详细信息。

分配策略

要分配策略，请在 Azure Policy 导航面板中的“创作”部分下选择“分配”选项。

可通过以下两种方式之一分配 Azure 策略：作为一组策略（称为“计划”），或者作为单个策略。

计划分配

计划分配是指组合在一起以满足特定目标或目的的 Azure 策略定义集合。 例如，目标可能是在资源中应用支付卡行业数据安全标准。

策略分配

策略分配会分配单个策略，例如“不允许 Kubernetes 群集中有特权容器”。

如何分配策略

每个策略均使用一系列配置步骤定义。 你捕获的信息量取决于要选择的策略类型。

例如，若要限制开发人员在公司云环境中的资源部署，可为 Azure Kubernetes 服务分配其中一个内置的 Azure 策略。 策略名称为“确保容器的 CPU 和内存资源限制不超过 Kubernetes 群集中指定的限制”。

策略要求你对部署请求所请求的允许资源设置限制。

让我们看一下分配策略时的可配置选项。

基本策略信息

第一步需要选择和输入定义新策略的基本信息。 例如，此信息可以是策略和资源范围。 下表显示了可以配置的每个项：

项 说明
范围 范围确定对其强制执行策略分配的资源或资源组。 此值基于订阅或管理组。 你可以从所选内容中排除级别低于范围级别的资源。
策略定义 要应用的策略。 可从多个内置策略选项中进行选择。
分配名称 用于标识已分配策略的名称。
描述 描述策略的任意文本说明。
策略实施 可以选择“已启用”和“已禁用”。 如果选项为“已禁用”，则不应用策略，并且不拒绝不符合要求的请求。
分配者 默认为已注册的用户的自由文本值。 你可以更改此值。

策略参数

策略要求你配置适用于每个特定策略的业务规则。 并非所有策略都具有相同的业务规则，因此每个策略都有不同的参数。

例如，“确保容器的 CPU 和内存资源限制不超过 Kubernetes 群集中指定的限制”策略要求你设置 3 个参数：

  • 容器所允许的最大 CPU 单位数
  • 容器所允许的最大内存字节数
  • 要从策略中排除的 Kubernetes 命名空间的列表

将上述策略与“只能通过 HTTPS 访问 Web 应用程序”策略进行比较，后者没有要配置的自定义参数。

所有策略都有“效果”设置。 此设置可启用或禁用策略执行。 与参数一样，策略也可具有不同的“效果”选项。

例如，对于资源管理策略，可以选择“审核”、“拒绝”或“禁用”作为效果值。 对于 Web 应用程序策略，只能选择“审核”或“禁用”。

下表列出了当前在策略定义中支持的所有效果：

效果 描述
追加 向所请求的资源添加更多字段
审核 在活动日志中创建警告事件
AuditIfNotExists 启用与资源相关的审核，该资源与条件相匹配
拒绝 阻止未通过策略定义与已定义标准匹配的资源请求，并使请求失败
DeployIfNotExists 满足条件时执行模板部署
已禁用 适用于测试情况或在策略定义已将效果参数化时使用，以及在你想要禁用单个分配时使用
修改 在创建或更新期间添加、更新或删除资源上的标记

策略修正

最后一步是考虑策略修正。 分配策略时，资源可能已经存在并违反新策略。 默认情况下，新策略仅应用于新创建的资源。 分配新策略后，使用修正检查现有资源。 修正任务因应用的策略类型而异。

在下一个练习中，将使用“确保容器的 CPU 和内存资源限制不超过 Kubernetes 群集中指定的限制”策略来进一步降低成本。