Garantir 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. Caso tenha se passado menos de 24 horas desde que você implementou a orientação da recomendação, marque-a como resolvida. 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'
  - 'subjectacessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

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

A seguir