Resolver problemas do GKE em Bare Metal com webhook

Nesta página, mostramos como resolver problemas com webhooks problemáticos ou não seguros no Google Distributed Cloud Virtual para Bare Metal.

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 Google Distributed Cloud Virtual para Bare Metal 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:

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.
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.

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.
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