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 não comunicam 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. Inspeção da 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 *, 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.

Webhooks que bloqueiam componentes críticos do sistema

Os webhooks que intercetam pedidos para criar ou atualizar ClusterRoles e ClusterRoleBindings podem interferir com a capacidade do plano de controlo de reconciliar estes recursos críticos do sistema. Por exemplo, durante uma atualização do cluster, o kube-apiserver pode ter de atualizar as respetivas funções do sistema. Se um webhook que não esteja disponível ou esteja configurado incorretamente bloquear esta atualização, o kube-apiserver não vai ficar em bom estado, o que vai bloquear a atualização do cluster.

O GKE não deteta se os webhooks intercetam ClusterRoles e ClusterRoleBindings, pelo que não é gerada nenhuma estatística para este cenário.

O exemplo seguinte mostra uma configuração de webhook problemática que interceta ClusterRoles:

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

Para evitar esta situação, certifique-se de que os seus webhooks não intercetam pedidos de ClusterRoles e ClusterRoleBindings que tenham a definição system: prefix.

Impasse de admissão

Quando um webhook está configurado para falhar fechado, pode criar uma situação em que o cluster não consegue recuperar automaticamente. Por exemplo, se todos os nós num cluster forem eliminados, o webhook também fica inativo. Uma vez que a adição de um novo nó requer a validação de admissão, o webhook tem de estar disponível para aprovar o pedido. Isto cria uma dependência circular que pode impedir a recuperação do plano de controlo do cluster.

O GKE não deteta cenários de impasse de admissão, pelo que não são geradas estatísticas para este cenário. No entanto, pode ocorrer um impasse de admissão se os pods do webhook estiverem inativos. Nesse caso, o GKE deteta que o webhook não tem pontos finais disponíveis e gera uma estatística.K8S_ADMISSION_WEBHOOK_UNAVAILABLE

Para mitigar esta situação, pode eliminar o ValidatingWebhookConfiguration para interromper a dependência circular e permitir que o cluster seja recuperado.

Disponibilidade do plano de controlo do cluster

Quando um webhook está configurado para falhar fechado, a disponibilidade do painel de controlo do Kubernetes passa a depender da disponibilidade do webhook. Para melhorar a disponibilidade do plano de controlo, considere o seguinte:

O GKE não deteta problemas de disponibilidade do plano de controlo do cluster causados por webhooks, pelo que não é gerada nenhuma estatística para este cenário.

  • Limite o âmbito do webhook: pode isentar recursos críticos de serem validados pelo webhook para impedir que o webhook interfira em processos confidenciais. Pode isentar espaços de nomes ou tipos específicos de recursos. No entanto, tenha em atenção as dependências não óbvias. Por exemplo, um ConfigMap pode ser um recurso crítico para a eleição de líder no Kubernetes.

  • Reforce a implementação do webhook: a execução do webhook em vários pods pode aumentar a respetiva resiliência e tempo de atividade. Pode usar seletores de nós para distribuir os pods por diferentes domínios de falha.

O que se segue?