你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文是一系列文章的其中一篇。 从 概述开始。
准入控制器很少引起问题，但确保其正常运行至关重要。 本文讨论了当其他组件无法正常工作时，准入控制器如何影响它们。 它还介绍了可用于验证准入控制器性能的命令。
准入控制器
准入控制器是一段代码，用于在对象持久化之前但在请求经过身份验证和授权之后拦截对 Kubernetes API 服务器的请求。
准入控制器可以是 validating、 mutating 或两者的组合。 mutating controller 可以在接受请求之前修改相关对象。 验证 控制器仅确保请求满足特定的预定义条件。
准入控制器的主要功能之一是控制对象创建、删除和修改的请求。 此外，准入控制器可以限制自定义动词，例如通过 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 中自动注入 sidecar 容器，以及其他功能。 评估并验证准入控制器是否正常运行，以支持服务网格的持续稳定运行为非常重要。
检查 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使用 and 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 | 首席客户工程师
其他参与者：
- 弗朗西斯·西米·纳扎雷斯 |高级技术专家
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。