Garanta a estabilidade do plano de controlo quando usar webhooks

Os webhooks de admissão, ou webhooks no Kubernetes, são um tipo de controlador de admissão, que podem ser usados em clusters do Kubernetes para validar ou alterar pedidos ao plano de controlo antes de um pedido ser persistido. É comum as aplicações de terceiros usarem webhooks que operam em recursos e espaços de nomes críticos para o sistema. Os webhooks configurados incorretamente podem afetar o desempenho e a fiabilidade do plano de controlo. Por exemplo, um webhook configurado incorretamente criado por uma aplicação de terceiros pode impedir o GKE de criar e modificar recursos no espaço de nomes kube-system gerido, o que pode degradar a funcionalidade do cluster.

O Google Kubernetes Engine (GKE) monitoriza os seus clusters e usa o serviço Recommender para fornecer orientações sobre como pode otimizar a sua utilização da plataforma. Para ajudar a garantir que o cluster permanece estável e com bom desempenho, consulte as recomendações do GKE para os seguintes cenários:

  • Webhooks que funcionam, mas não têm pontos finais disponíveis.
  • Webhooks considerados inseguros, uma vez que operam em recursos e espaços de nomes críticos do sistema.

Com estas orientações, pode ver instruções sobre como verificar os webhooks potencialmente mal configurados e atualizá-los, se necessário.

Para saber como gerir as estatísticas e as recomendações dos Recommenders, consulte o artigo Otimize a sua utilização do GKE com estatísticas e recomendações.

Identifique webhooks mal configurados que possam afetar o seu cluster

Para receber estatísticas que identificam webhooks que podem afetar o desempenho e a estabilidade do seu cluster, siga as instruções para ver estatísticas e recomendações. Pode obter estatísticas das seguintes formas:

  • Use a Google Cloud consola.
  • 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 através das estatísticas, siga as instruções para resolver problemas com os webhooks detetados.

Quando o GKE deteta webhooks configurados incorretamente

O GKE gera uma estatística e uma recomendação se algum dos seguintes critérios for verdadeiro para um cluster:

Resolva problemas dos webhooks detetados

As secções seguintes contêm instruções para resolver problemas com os webhooks que o GKE detetou como potencialmente configurados incorretamente.

Depois de implementar as instruções e os webhooks estarem configurados corretamente, a recomendação é resolvida no prazo de 24 horas e deixa de aparecer na consola.

Se não quiser implementar a recomendação, pode ignorá-la.

Os webhooks comunicam que não existem pontos finais disponíveis

Se um webhook estiver a comunicar que não tem pontos finais disponíveis, o serviço que suporta o ponto final do webhook tem um ou mais pods que não estão em execução. Para disponibilizar os pontos finais do webhook, siga as instruções para encontrar e resolver problemas dos pods do serviço que suporta este ponto final do webhook:

  1. Ver estatísticas e recomendações, escolhendo uma estatística de cada vez para resolver problemas. O GKE gera uma estatística por cluster, e esta estatística apresenta um ou mais webhooks com um ponto final danificado que tem de ser investigado. Para cada um destes webhooks, a estatística detalhada também indica o nome do serviço, que ponto final está danificado e a última vez que o ponto final foi chamado.

  2. Encontre os pods de publicação para o serviço associado ao webhook:

    Consola

    No painel da barra lateral das estatísticas, consulte a tabela de webhooks configurados incorretamente. Clique no nome do serviço.

    kubectl

    Execute o seguinte comando para descrever o serviço:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Substitua SERVICE_NAME e SERVICE_NAMESPACE pelo nome e espaço de nomes do serviço, respetivamente.

    Se não conseguir encontrar o nome do serviço indicado no webhook, o ponto final indisponível pode ser causado por uma falta de correspondência entre o nome indicado na configuração e o nome real do serviço. Para corrigir a disponibilidade do ponto final, atualize o nome do serviço na configuração do webhook para corresponder ao objeto de serviço correto.

  3. Inspeccione os pods de publicação deste serviço:

    Consola

    Em Serving Pods nos detalhes do serviço, consulte a lista de Pods que suportam este serviço.

    kubectl

    Identifique os pods que não estão em execução listando a implementação ou os pods:

    kubectl get deployment -n SERVICE_NAMESPACE

    Em alternativa, execute este comando:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Para todos os pods que não estejam em execução, inspecione os registos dos pods para ver por que motivo o pod não está em execução. Para ver instruções sobre problemas comuns com pods, consulte o artigo Resolva problemas com cargas de trabalho implementadas.

Webhooks considerados inseguros

Se um webhook estiver a intercetar recursos em espaços de nomes geridos pelo sistema ou determinados tipos de recursos, o GKE considera esta ação insegura e recomenda que atualize os webhooks para evitar a interceção destes recursos.

  1. Siga as instruções para ver estatísticas e recomendações, escolhendo uma estatística de cada vez para resolver problemas. O GKE só gera uma estatística por cluster, e esta estatística apresenta uma ou mais configurações de webhook, cada uma das quais apresenta um ou mais webhooks. Para cada configuração de webhook apresentada, a estatística indica o motivo pelo qual a configuração foi denunciada.

  2. Inspecione a configuração do webhook:

    Consola

    No painel da barra lateral das estatísticas, consulte a tabela. Em cada linha, encontra o nome da configuração do webhook e o motivo pelo qual esta configuração foi sinalizada.

    Para inspecionar cada configuração, clique no nome para navegar para esta configuração no painel de controlo do explorador de objetos do GKE.

    kubectl

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

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Se este comando não devolver nada, execute-o novamente, substituindo validatingwebhookconfigurations por mutatingwebhookconfigurations.

    Na secção webhooks, existem um ou mais webhooks listados.

  3. Edite a configuração, consoante o motivo pelo qual o webhook foi denunciado:

    Exclua os espaços de nomes kube-system e kube-node-lease

    Um webhook é sinalizado se scope for *. Em alternativa, um webhook é denunciado se o âmbito for Namespaced e qualquer uma das seguintes condições for verdadeira:

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

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

      Certifique-se de que define scope como Namespaced e não como *, para que o webhook funcione apenas em espaços de nomes específicos. Certifique-se também de que, se o elemento operator for NotIn, inclui 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 seguinte:

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

      Certifique-se de que define scope como Namespaced e não como *, para que o webhook funcione apenas em espaços de nomes específicos. Certifique-se de que, se operator for In, não inclui kube-system e kube-node-lease em values. Neste exemplo, apenas blue-system deve estar em values, uma vez que operator é In.

    Exclua recursos correspondentes

    Um webhook também é denunciado se nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estiverem listados em recursos, como no exemplo seguinte:

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

    Remova nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests da secção de recursos. Pode manter pods em resources.

O que se segue?