你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
验证许可控制器
本文是一系列文章的其中一篇。 从概述开始。
许可控制器很少导致问题，但确保其正常运行至关重要。 本文讨论许可控制器在无法正常运行时如何影响其他组件。 它还介绍了可用于验证许可控制器性能的命令。
许可控制器
许可控制器是一段代码，它在对象持久化之前，但在请求经过身份验证和授权之后，拦截对 Kubernetes API 服务器的请求。
许可控制器可以是验证、变异或两者的组合。 变异控制器可以在许可请求之前修改相关对象。 验证控制器只确保请求满足特定的预定义条件。
许可控制器的主要功能之一是规范对象创建、删除和修改的请求。 此外，许可控制器还可以限制自定义谓词，例如通过 API 服务器代理请求与 Pod 的连接。 但是，许可控制器无法阻止读取对象的请求，包括 get、watch 或 list 等操作。
某些组件可能会影响许可控制器，例如变异和验证 Webhook。 在 Kubernetes 群集中合并变异和验证 Webhook 时，必须确保高可用性。 运行不正常的节点不应阻止 API 服务器请求。 监视许可控制管道至关重要，这样就不会阻止对 API 服务器的请求。 不正常的许可控制器可能会影响变异和验证 Webhook。 应监视的基于 Webhook 的许可控制器包括：
适用于 Azure Kubernetes 服务 (AKS) 群集的 Azure Policy 加载项，其扩展了 Gatekeeper。 Gatekeeper 是 Open Policy Agent 的许可控制器 Webhook。
Kyverno，在 Kubernetes 群集中作为动态许可控制器运行。 Kyverno 从 Kubernetes API 服务器接收验证和变异许可 Webhook HTTP 回调，并应用匹配的策略以返回强制实施许可策略或拒绝请求的结果。 有关故障排除参考（如 APIServer 调用 webhook 失败），请参阅 Kyverno 故障排除文档。
或者，未正常运行的许可控制器可能会影响各种组件，例如服务网格。 服务网格（如 Istio 和 Linkerd）使用许可控制器自动在 Pod 内注入挎斗容器以及其他功能。 请务必评估和验证许可控制器是否正常运行，以确保服务网格的无缝操作。
检查适用于 AKS 群集的 Azure Policy 加载项的状态
如果安装适用于 AKS 的 Azure Policy 加载项，则可以使用以下 kubectl 命令验证群集中 Azure Policy 许可控制器的安装和功能：
# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system
# Sample output
...
NAME READY STATUS RESTARTS AGE
gatekeeper-audit-65844778cb-rkflg 1/1 Running 0 163m
gatekeeper-controller-78797d4687-4pf6w 1/1 Running 0 163m
gatekeeper-controller-78797d4687-splzh 1/1 Running 0 163m
...
运行上一个命令，验证 gatekeeper-system 命名空间中 Azure Policy 代理 Pod 的可用性。 如果输出不是预期内容，则可能表示许可控制器、API 服务或自定义资源定义 (CRD) 存在问题。
# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources
# Sample output
...
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
...
上一个命令可帮助你验证所有 API 资源是否正常运行。 确保输出包含预期的资源，且没有任何错误或缺少组件。 使用 kubectl get pod 和 kubectl api-resources 命令检查适用于 AKS 的 Azure Policy 加载项的状态，并验证 Kubernetes 群集中许可控制器的功能。 定期监视许可控制器，确保它们正常运行，以便保持群集的整体运行状况和稳定性。
使用以下 kubectl get 命令来确认策略分配已应用于你的群集：
kubectl get constrainttemplates
注意
策略分配可能需要最多 20 分钟来与每个群集同步。
输出应类似于以下示例：
NAME AGE
k8sazureallowedcapabilities 23m
k8sazureallowedusersgroups 23m
k8sazureblockhostnamespace 23m
k8sazurecontainerallowedimages 23m
k8sazurecontainerallowedports 23m
k8sazurecontainerlimits 23m
k8sazurecontainernoprivilege 23m
k8sazurecontainernoprivilegeescalation 23m
k8sazureenforceapparmor 23m
k8sazurehostfilesystem 23m
k8sazurehostnetworkingports 23m
k8sazurereadonlyrootfilesystem 23m
k8sazureserviceallowedports 23m
有关详细信息，请参阅以下资源：
验证 Webhook
要确保验证和变异 Webhook 在 Kubernetes 群集中按预期工作，请执行以下步骤。
运行以下命令来列出群集中的验证 Webhook：
kubectl get ValidatingWebhookConfiguration -o wide输出应类似于以下示例：
NAME WEBHOOKS AGE aks-node-validating-webhook 1 249d azure-policy-validating-webhook-configuration 1 249d gatekeeper-validating-webhook-configuration 1 249d查看输出，验证验证 Webhook 是否存在以及其配置是否符合预期。 输出包括每个验证 Webhook 的名称、Webhook 的数量以及每个 Webhook 的使用期限。
运行以下命令来列出群集中的变异 Webhook：
kubectl get MutatingWebhookConfiguration -o wide输出应类似于以下示例：
NAME WEBHOOKS AGE aks-node-mutating-webhook 1 249d azure-policy-mutating-webhook-configuration 1 249d gatekeeper-mutating-webhook-configuration 1 249d检查输出，确保变异 Webhook 正确列出并且它们的配置符合要求。 输出包括每个变异 Webhook 的名称、Webhook 的数量以及每个 Webhook 的使用期限。
运行以下命令，检索特定许可控制器的特定详细信息：
kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml将
<mutating-webhook-name>替换为要检索其详细信息的变异 Webhook 的名称。 此命令的输出显示指定变异 Webhook 配置的 YAML 表示形式。
运行本部分中的命令并查看输出，以便可以确认 Kubernetes 群集中的验证和变异 Webhook 是否存在并按预期进行配置。 此验证对于确保正常运行至关重要。 确保 Webhook 遵循策略来验证和修改群集中的资源，这一点也很重要。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Paolo Salvatori | 首席客户工程师
其他参与者：
- Francis Simy Nazareth | 高级技术专家
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。