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

Sim, consulte o Kubernetes e Red Hat OpenShift documentação 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. Para os clusters OpenShift, os componentes do avião de controle muitas vezes têm seu próprio tempo limite de 13 seconds.

  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 atividade e prontidão para ajudar a garantir que seu contêiner de webhook esteja em execução e pronto para atender às solicitações.

• Configure regras de planejamento antiafinidade de 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.

• Escoar seu webhook para o projeto apropriado. Evite webhooks que processem recursos executados em projetos críticos para o sistema, configurados por padrão no seu cluster, como os projetos kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator e openshift-*.

• 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 do seu cluster tenham o tamanho adequado 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

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.