Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Esta é uma documentação não divulgada para Admission Controller 1.34-dev.

SUSE Security Admission Controller em um Ambiente de Grande Escala

Esta seção detalha uma implantação do mundo real de SUSE Security Admission Controller em um ambiente de grande escala exigente. Ela ilustra como configurar Admission Controller para alta disponibilidade e desempenho e o que esperar sob carga pesada.

Se você quiser ver mais dicas sobre como executar Admission Controller em produção, confira a documentação de Implantações em produção.

Visão Geral do Ambiente

A infraestrutura consiste em aproximadamente 20 clusters Kubernetes. Os maiores desses clusters são caracterizados por tamanho significativo e volume de recursos:

  • Nós: ~400

  • Namespaces: ~4.000

  • Recursos gerenciados:

    • Pods: 10,000

    • RoleBindings: 13.000

    • Ingresses: 12.000

    • Implantações: 8.000

    • Serviços: 13.000

Admission Controller Configuração

Para atender às demandas deste ambiente, Admission Controller é configurado com foco no isolamento de carga de trabalho e alta disponibilidade.

  • Aplicação da Política: 22 ClusterAdmissionPolicies são aplicadas em todos os clusters, sem AdmissionPolicies específico de namespace.

  • Arquitetura do PolicyServer: Duas implantações PolicyServer separadas são usadas para isolar cargas de trabalho:

    • Uma PolicyServer é dedicada exclusivamente a políticas contextuais.

    • Uma segunda PolicyServer lida com todas as outras políticas não contextuais.

  • Escalabilidade e Recursos:

    • Réplicas: Cada implantação PolicyServer executa 15 réplicas para lidar com o alto volume de solicitações.

    • Alocação de Recursos: Cada réplica é alocada com 300 MB de memória e 4 núcleos de CPU.

Métricas de Desempenho

Esta configuração gerencia com sucesso uma alta taxa de solicitações de admissão enquanto mantém um desempenho previsível.

  • Taxa de Processamento das Solicitações de Admissão: Os clusters lidam com até 300 solicitações de admissão por segundo (incluindo validações de webhook e varreduras de auditoria).

  • Latência da Política:

    • Latência Típica: Políticas contextuais geralmente levam cerca de 500ms para serem executadas.

    • Tempos de espera: Neste ambiente de alta capacidade, os tempos de espera do webhook estão configurados para 2,5 segundos, enquanto o tempo de espera PolicyServer está definido para 10 segundos. Embora a maioria das solicitações seja rápida, a infraestrutura é construída para lidar com operações ocasionalmente lentas sem comprometer a estabilidade do servidor da API.

Desempenho do Scanner de Auditoria

O scanner de auditoria é utilizado para garantir conformidade contínua em um grande número de recursos.

  • Frequência: Uma auditoria em todo o cluster é realizada a cada 4 horas.

  • Configuração: O trabalho de auditoria é ajustado para máximo paralelismo a fim de reduzir o tempo de execução:

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

  • Duração da Auditoria: Mesmo no maior cluster com dezenas de milhares de recursos, um trabalho de auditoria completo é concluído em