Resolver problemas do GKE no webhook do Azure

Nesta página, mostramos como resolver problemas com webhooks problemáticos ou não seguros no GKE no Azure.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Tipos de webhooks problemáticos

Os webhooks de admissão, ou webhooks no Kubernetes, são um tipo de controlador de admissão que pode ser usado nos clusters do Kubernetes para validar ou modificar solicitações para o plano de controle antes de uma solicitação ser 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 no Azure crie e modifique recursos no namespace kube-system gerenciado, o que pode prejudicar a funcionalidade do cluster.

Os webhooks problemáticos incluem os seguintes tipos:

• Webhooks que operam, mas não têm endpoints disponíveis. Siga as instruções para verificar os webhooks sem endpoints disponíveis.

• Webhooks que são considerados não seguros porque operam em recursos e namespaces críticos do sistema.

  Os webhooks abaixo são considerados não seguros:

  • Webhooks que interceptam pods e leases no namespace kube-system.
  • Webhooks que interceptam leases no namespace kube-node-lease.
  • Webhooks que interceptam recursos Nodes, TokenReviews, SubjectAccessReviews e CertificateSigningRequests.

  Siga as instruções para verificar os webhooks que são considerados inseguros.

Webhooks que não têm endpoints disponíveis

Se um webhook não tiver endpoints disponíveis, o serviço que apoia 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 solucionar problemas dos pods do serviço que está oferecendo suporte a esse endpoint do webhook:

1. Encontre os pods de exibição do serviço associado ao webhook. Execute o seguinte comando para descrever o serviço:

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   Substitua:

   • SERVICE_NAME pelo nome do serviço.
   • SERVICE_NAMESPACE pelo nome do namespace.

   Se você não encontrar o nome do serviço listado no webhook, talvez o endpoint indisponível seja 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.

2. Inspecione os pods de exibição deste serviço. Identifique quais pods não estão em execução listando a implantação:

   kubectl get deployment -n SERVICE_NAMESPACE
   

   Ou execute o seguinte comando para listar os pods:

   kubectl get pods -n SERVICE_NAMESPACE -o wide
   

   Inspecione os registros de pods que não estejam em execução para ver por que ele não está em execução.

Webhooks considerados não seguros

Se um webhook interceptar recursos em namespaces gerenciados pelo sistema, recomendamos que você os atualize para evitar a interceptação.

1. Inspecione a configuração do webhook. Execute o seguinte comando kubectl para ver a configuração do webhook:

   kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
   

   Substitua CONFIGURATION_NAME pelo nome da configuração do webhook.

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

   Na seção webhooks da saída, um ou mais webhooks são listados.

2. Edite a configuração, dependendo do motivo pelo qual o webhook é considerado não seguro:

   Excluir namespaces kube-system e kube-node-lease

   Um webhook não é considerado seguro se scope for * ou 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 # add 'kube-system' and 'kube-node-lease' if `NotIn`
       objectSelector: {}
       rules:
       - apiGroups:
         ...
         scope: '*' # 'Namespaced'
       sideEffects: None
       timeoutSeconds: 3
     

     Verifique se scope está definido como Namespaced, não *, para que o webhook opere apenas em namespaces específicos. Verifique se operator é NotIn, kube-system e kube-node-lease estão incluídos em values.

   • 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 # remove as operator is `In`
           - kube-node-lease # remove as operator is `In`
     

     Verifique se scope está definido como Namespaced, não *, para que o webhook opere apenas em namespaces específicos. Verifique se operator é In, kube-system e kube-node-lease não estão incluídos em values.

   Excluir recursos correspondentes

   Um webhook também é considerado não seguro se nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estiverem listados em recursos, como no exemplo a seguir:

   - admissionReviewVersions:
   ...
       resources:
       - 'pods' # keep, remove everything else
       - 'nodes'
       - 'tokenreviews'
       - 'subjectacessreviews'
       - 'certificatesigningrequests'
       scope: '*'
     sideEffects: None
     timeoutSeconds: 3
   

   Remova nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests da seção de recursos.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.