Garanta a estabilidade do plano de controle ao usar webhooks

Webhooks de admissãowebhooks no Kubernetes, são um tipo decontrolador de admissão , que pode ser usado em clusters do Kubernetes para validar ou modificar solicitações para o plano de controle antes que uma solicitação seja mantida. É comum que aplicativos de terceiros usem webhooks que operam em recursos e namespaces críticos para o sistema. Os webhooks configurados incorretamente podem afetar o desempenho e a confiabilidade do plano de controle. Por exemplo, um webhook configurado incorretamente, criado por um aplicativo de terceiros, pode impedir que o GKE crie e modifique recursos no namespace kube-system gerenciado, o que pode prejudicar a funcionalidade do cluster.

O Google Kubernetes Engine (GKE) monitora os clusters e usa o serviço do recomendador para fornecer orientações sobre como otimizar o uso da plataforma. Para garantir que o cluster permaneça estável e funcionando, consulte as recomendações do GKE para os seguintes cenários:

  • Webhooks que funcionam, mas não têm endpoints disponíveis.
  • Webhooks considerados não seguros quando operam em recursos e namespaces críticos do sistema.

Com essa orientação, é possível ver instruções sobre como verificar e atualizar webhooks potencialmente mal configurados, se necessário.

Para saber mais sobre como gerenciar insights e recomendações dos Recommenders, consulte Otimizar o uso do GKE com insights e recomendações.

Identifique webhooks mal configurados que podem afetar o cluster

Para conseguir insights que identificam webhooks que podem afetar o desempenho e a estabilidade do cluster, siga as instruções para ver insights e recomendações. É possível conseguir insights das seguintes maneiras:

  • Use o console do Google Cloud .
  • Use a Google Cloud CLI ou a API Recommender filtrando com os subtipos K8S_ADMISSION_WEBHOOK_UNSAFE e K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Depois de identificar os webhooks com os insights, siga as instruções para resolver problemas com os webhooks detectados.

Quando o GKE detecta webhooks mal configurados

O GKE gera um insight e uma recomendação se um dos critérios a seguir for verdadeiro para um cluster:

Resolver problemas dos webhooks detectados

As seções a seguir têm instruções para você solucionar problemas de webhooks que o GKE detectou como possivelmente configurados incorretamente.

Depois que você implementar as instruções e os webhooks forem configurados corretamente, a recomendação será resolvida em até 24 horas e não aparecerá mais no console.

Se você não quiser implementar a recomendação, dispense-a.

Não há endpoints disponíveis nos relatórios de webhooks

Se um webhook informar que não tem endpoints disponíveis, o serviço que está apoiando o endpoint do webhook terá um ou mais pods que não estão em execução. Para disponibilizar os endpoints do webhook, siga as instruções para encontrar e resolver problemas de pods do serviço que fazem isso:

  1. Acesse insights e recomendações escolhendo um insight de cada vez para resolver problemas. O GKE gera um insight por cluster, que lista um ou mais webhooks com um endpoint corrompido que precisam ser investigados. Para cada um desses webhooks, o insight também informa o nome do serviço, qual endpoint está corrompido e a última vez em que o endpoint foi chamado.

  2. Encontre os pods de exibição do serviço associado ao webhook:

    Console

    No painel da barra lateral do insight, confira a tabela de webhooks configurados incorretamente. Clique no nome do Serviço.

    kubectl

    Execute o comando a seguir para descrever o Serviço:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Substitua SERVICE_NAME e SERVICE_NAMESPACE pelo nome e namespace do serviço, respectivamente.

    Se você não encontrar o nome do serviço listado no webhook, o endpoint indisponível poderá ser causado por uma incompatibilidade entre o nome listado na configuração e o nome real do serviço. Para corrigir a disponibilidade do endpoint, atualize o nome do serviço na configuração do webhook para corresponder ao objeto de serviço correto.

  3. Inspecione os pods de exibição para este serviço:

    Console

    Em Como exibir pods, em Detalhes do serviço, consulte a lista de pods que dão suporte a esse serviço.

    kubectl

    Identifique quais pods não estão em execução listando a implantação ou os pods:

    kubectl get deployment -n SERVICE_NAMESPACE

    Ou execute este comando:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Para qualquer pod que não esteja em execução, inspecione os registros do pod para ver por que o pod não está em execução. Para instruções sobre problemas comuns com pods, consulte Como solucionar problemas com cargas de trabalho implantadas.

Webhooks considerados não seguros

Se um webhook estiver interceptando qualquer recurso em namespaces gerenciados pelo sistema ou determinados tipos de recursos, o GKE considerará isso não seguro e recomenda que você atualize os webhooks para evitar a interceptação recursos.

  1. Siga as instruções para acessar insights e recomendações, escolhendo um insight de cada vez para resolver problemas. O GKE só gera um insight por cluster, que lista uma ou mais configurações de webhook, cada uma listando um ou mais webhooks. Para cada configuração de webhook listada, o insight indica o motivo da sinalização da configuração.

  2. Inspecione a configuração do webhook:

    Console

    No painel da barra lateral do insight, acesse a tabela. Em cada linha está o nome da configuração do webhook e o motivo da sinalização dessa configuração.

    Para inspecionar cada configuração, clique no nome para acessá-la no painel do Navegador de objetos do GKE.

    kubectl

    Execute o comando kubectl a seguir para conseguir a configuração do webhook, substituindo CONFIGURATION_NAME pelo nome da configuração do webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Se esse comando não retornar nada, execute o comando novamente, substituindo validatingwebhookconfigurations por mutatingwebhookconfigurations.

    Na seção webhooks, há um ou mais webhooks listados.

  3. Edite a configuração, dependendo do motivo da sinalização do webhook:

    Excluir namespaces kube-system e kube-node-lease

    Um webhook será sinalizado se scope for *. Ou um webhook será sinalizado se o escopo for Namespaced e uma das seguintes condições for verdadeira:

    • A condição operator é NotIn, e values omite kube-system e kube-node-lease, como no exemplo a seguir:

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

      Verifique se scope está definido como Namespaced (e não *), para que o webhook opere apenas em namespaces específicos. Além disso, se operator for NotIn, inclua kube-system e kube-node-lease em values (neste exemplo, com blue-system).

    • A condição operator é In e values inclui kube-system e kube-node-lease, como no exemplo a seguir:

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system
      - kube-node-lease

      Verifique se scope está definido como Namespaced (não *), para que o webhook opere apenas em namespaces específicos. Se operator for In, não inclua kube-system e kube-node-lease em values. Neste exemplo, somente blue-system precisa estar em values, já que operator é In.

    Excluir recursos correspondentes

    Um webhook também será sinalizado se nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estiverem listados em "Recursos", como no seguinte exemplo:

    - admissionReviewVersions:
...
  resources:
  - 'pods'
  - 'nodes'
  - 'tokenreviews'
  - 'subjectaccessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

    Remova nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests da seção de recursos. Você pode manter pods em resources.

Webhooks que bloqueiam componentes essenciais do sistema

Os webhooks que interceptam solicitações para criar ou atualizar ClusterRoles e ClusterRoleBindings podem interferir na capacidade do plano de controle de reconciliar esses recursos críticos do sistema. Por exemplo, durante um upgrade de cluster, o kube-apiserver pode precisar atualizar as funções do sistema. Se um webhook indisponível ou configurado incorretamente bloquear essa atualização, o kube-apiserver não ficará íntegro, o que vai impedir o upgrade do cluster.

O GKE não detecta se os webhooks interceptam ClusterRoles e ClusterRoleBindings. Portanto, nenhum insight é gerado para esse cenário.

O exemplo a seguir mostra uma configuração de webhook problemática que intercepta ClusterRoles:

-   admissionReviewVersions:
  ...
  resources:
  -   'clusterroles'
  -   'clusterrolebindings'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

Para evitar essa situação, verifique se os webhooks não interceptam solicitações de ClusterRoles e ClusterRoleBindings que têm a configuração system: prefix.

Impasse de admissão

Quando um webhook é configurado para falhar fechado, ele pode criar uma situação em que o cluster não consegue se recuperar automaticamente. Por exemplo, se todos os nós de um cluster forem excluídos, o webhook também ficará inativo. Como a adição de um novo nó exige validação de admissão, o webhook precisa estar disponível para aprovar a solicitação. Isso cria uma dependência circular que pode impedir a recuperação do plano de controle do cluster.

O GKE não detecta cenários de deadlock de admissão, então nenhum insight é gerado para esse cenário. No entanto, um impasse de admissão pode ocorrer se os pods de webhook estiverem inativos. Nesse caso, o GKE detecta que o webhook não tem endpoints disponíveis e gera um insight K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Para evitar isso, exclua o ValidatingWebhookConfiguration para interromper a dependência circular e permitir que o cluster seja recuperado.

Disponibilidade do plano de controle do cluster

Quando um webhook é configurado para falhar fechado, a disponibilidade do plano de controle do Kubernetes depende da disponibilidade do webhook. Para melhorar a disponibilidade do plano de controle, considere o seguinte:

O GKE não detecta problemas de disponibilidade do plano de controle do cluster causados por webhooks. Portanto, não é possível gerar insights para esse cenário.

  • Limite o escopo do webhook:é possível isentar recursos críticos da validação pelo webhook para evitar que ele interfira em processos sensíveis. É possível isentar namespaces ou tipos específicos de recursos. No entanto, fique atento a dependências não óbvias. Por exemplo, um ConfigMap pode ser um recurso essencial para a eleição de líderes no Kubernetes.

  • Reforce a implantação do webhook:executar o webhook em vários pods pode aumentar a resiliência e o tempo de atividade dele. É possível usar seletores de nós para distribuir os pods em diferentes domínios de falha.

A seguir