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

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

SUSE Security Admission Controller在大规模环境中的

本节详细介绍了SUSE Security Admission Controller在要求苛刻的大规模环境中的实际部署。它说明了如何配置Admission Controller以实现高可用性和性能，以及在高负载下的预期。

如果您想了解更多关于如何在生产中运行Admission Controller的提示，请查看生产部署文档。

环境概述

基础设施由大约20个Kubernetes集群组成。这些集群中最大的集群具有显著的规模和资源量：

为了满足该环境的需求，Admission Controller 被配置为专注于工作负载隔离和高可用性。

策略实施：在集群中强制执行 22 个 ClusterAdmissionPolicies，没有特定于名称空间的 AdmissionPolicies。
策略服务器架构：使用两个独立的 PolicyServer 部署来隔离工作负载：
- 一个 PolicyServer 专门用于上下文感知策略。
- 第二个 PolicyServer 处理所有其他非上下文感知策略。
可伸缩性和资源：
- 复本：每个 PolicyServer 部署运行 15 个副本以处理大量请求。
- 资源分配：每个副本分配 300 MB 内存和 4 个处理器内核。

该配置成功管理高频率的入场请求，同时保持可预测的性能。

入场请求吞吐量：集群每秒处理高达 300 个入场请求（包括 webhook 验证和审计扫描）。
策略延迟：
- 典型延迟：上下文感知策略通常需要大约 500 毫秒来执行。
- 超时：在这个高吞吐量的环境中，Webhook 超时设置为 2.5 秒，而 PolicyServer 超时设置为 10 秒。虽然大多数请求都很快，但基础设施的构建能够处理偶尔的慢操作，而不会影响 API 服务器的稳定性。

审计扫描器用于确保大量资源的持续合规性。

--parallel-namespaces: "10"
--parallel-resources: "20"
--parallel-policies: "20"
--page-size: "1000"