本文档采用自动化机器翻译技术翻译。尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。若出现任何内容不一致情况，请以原始英文版本为准，且原始英文版本为权威文本。

这是尚未发布的文档。 Admission Controller 1.34-dev.

紧急禁用

在紧急情况下，运维团队可能需要执行那些SUSE Security Admission Controller通常会阻止的操作。

本文档解释了如何禁用Admission Controller，以便运维团队可以处理集群故障。解决情况后，运维团队可以重新启动Admission Controller。

禁用Admission Controller

首先，停止Admission Controller控制器。您可以通过将其部署缩减为零来实现：

kubectl scale deployment kubewarden-controller \
  --replicas=0 \
  -n kubewarden

确保使用Admission Controller堆栈部署所在名称空间的名称。在这里，堆栈部署在`kubewarden`名称空间中。

接下来，删除所有由Admission Controller创建的`ValidatingWebhookConfigurations`和`MutatingWebhookConfigurations`：

# Delete all the ValidatingWebhookConfiguration created by {short-project-name}
kubectl delete validatingwebhookconfigurations \
  -l app.kubernetes.io/part-of=kubewarden

# Delete all the MutatingWebhookConfiguration created by {short-project-name}
kubectl delete mutatingwebhookconfigurations \
  -l app.kubernetes.io/part-of=kubewarden

恢复Admission Controller

当紧急情况结束时，通过恢复Admission Controller控制器来恢复Admission Controller堆栈：

kubectl scale deployment kubewarden-controller \
  --replicas=1 \
  -n kubewarden

确保使用Admission Controller堆栈部署所在名称空间的名称。在这里，堆栈部署在`kubewarden`名称空间中。
确保将控制器的规模恢复到其原始值。此示例假设控制器仅运行一个副本。

一旦控制器运行，它将协调已部署的策略。之前被删除的`ValidatingWebhookConfiguration`和`MutatingWebhookConfiguration`资源被重新创建，从而强制执行策略。