Quais são os controladores de admissão padrão no meu cluster?

Revise a ordem dos controladores de admissão padrão por versão de cluster nas informações de referência do componente kube-apiserver.

Posso criar meus próprios controladores de admissão?

Sim, consulte a documentação do Kubernetes para obter mais informações.

Como observado na documentação do Kubernetes, é possível usar controladores de admissão para operações que, de outra forma, são manipuladas pelo plano de controle. Como tal, tenha grande cuidado ao configurar um controlador de admissão customizado. Você é responsável por quaisquer mudanças que aconteçam em seu cluster por causa de um controlador de admissão customizado.

Quais são as melhores práticas para usar webhooks?

Evite usar webhooks sempre que possível. Use e MutatingAdmissionPolicyValidatingAdmissionPolicy (quando habilitado por padrão) como alternativas.

Se você precisar usar webhooks, tenha em mente as seguintes práticas recomendadas e considerações ao configurar um webhook.

• Não use webhooks de mutação para alterar recursos de propriedade de outro controlador ou operador. Fazer isso pode causar um loop de reconciliação infinito entre o proprietário do recurso e o webhook. Os webhooks podem determinar a propriedade do recurso verificando se metadata.ownerReferences está definido nos dados do recurso. Por exemplo, um recurso de conjunto de réplicas Kubernetes é de propriedade de um recurso de implantação Kubernetes e nunca deve ser alterado por um webhook.

• Crie pods de réplica para o webhook para que, se um pod cair, o webhook ainda possa processar solicitações de seus recursos. Espalhe os pods de réplica entre as zonas, se possível.

• Configure uma opção failurePolicy apropriada, como se o seu webhook falhar ou ignorar falhas de conexão ou timeouts. Você pode configurar o failurePolicy para Ignore se você quiser que seu webhook ignore erros de conexão um timeouts. Note que isso não altera como o apiserver se comporta se o webhook rejeitar uma solicitação.

• Revise o intervalo timeoutSeconds. Webhooks mais antigos que usam a API v1beta1.admissionregistration.k8s.io têm um tempo limite padrão de 30 seconds segundos. A API v1 usa um padrão de 10 seconds. Se a política de falha do webhook for Ignore e a atual timeoutSeconds for 30, considere reduzir o tempo limite para 10 seconds segundos.

  Evite permitir que vários webhooks mutantes operem nos mesmos recursos. Os webhooks mutantes são executados sequencialmente. Um único webhook mutável pode funcionar conforme o esperado do ponto de vista da política de tempo limite e falha, mas quando combinado com webhooks mutáveis adicionais que operam no mesmo recurso, os webhooks mutáveis podem exceder o tempo limite total do contexto concedido para executar todos os webhooks.

• Configure solicitações de recursos e limites de CPU e memória apropriados para o seu webhook.

• Adicione sondas de vivacidade e prontidão para ajudar a garantir que o contêiner do webhook esteja em execução e pronto para atender às solicitações.

• Configure as regras de planejamento antiafinidade do pod para preferir que seus pods de webhook sejam executados em diferentes nós do trabalhador e zonas quando possível. Você pode usar topologia de pod no lugar. No entanto, evite contaminações ou afinidade forçada que possa restringir onde os pods de webhook podem ser planejados.

• Defina a prioridade do pod para system-cluster-critical para os pods de webhook para que outros pods não possam tirar recursos dos pods de webhook.

• Defina o escopo de seu webhook para o namespace apropriado. Evite webhooks que processam recursos executados em namespaces críticos para o sistema que são configurados em seu cluster por padrão, como kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator e openshift-* namespaces.

• Revise a opção namespaceSelector. Você pode adicionar etiquetas aos determinados namespaces críticos, como kube-system, portanto, o webhook não é chamado para esses casos. Esta configuração é chamada de configuração de estilo "opt out". Ou ainda, é possível configurar a opção namespaceSelector para que o webhook seja chamado apenas para namespaces que tenham uma etiqueta específica. Esta configuração é chamada de configuração "opt in". Dependendo da finalidade do webhook, pode ser importante que o webhook seja chamado para todos os namespaces. Revise as opções de configuração namespaceSelector na documentação Kubernetes e ajuste sua configuração de webhook.

• Certifique-se de que os nós de trabalho em seu cluster tenham o tamanho correto para executar seus aplicativos de webhook. Por exemplo, se seus pods solicitarem mais CPU ou memória do que o nó do trabalhador pode fornecer, os pods não serão planejados.

Quais outros tipos de apps usam controladores de admissão?

Muitos complementos de cluster, plug-ins e outras extensões de terceiros usam controladores de admissão. Alguns comuns incluem:

• Portieris
• Istio

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

Preciso de ajuda com um webhook interrompido. O que posso fazer?

Para ajudar a resolução de problemas de webhooks, consulte Debugging webhooks ou Cluster não pode atualizar por causa do webhook quebrado.