Esta documentação é referente à versão atual do GKE na AWS, lançada em novembro de 2021. Consulte as Notas de lançamento para mais informações.

Resolver problemas do GKE no webhook da AWS

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

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

Tipos de webhooks problemáticos

Webhooks de admissão, ou webhooks no Kubernetes, são um tipo de controlador de admissão que pode ser usado em clusters do Kubernetes para validar ou modificar solicitações para o plano de controle antes que elas sejam mantidas. É 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 na AWS 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 funcionam, mas não têm endpoints disponíveis. Siga as instruções para verificar os webhooks sem endpoints disponíveis.
Webhooks considerados não seguros quando 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 os recursos Nodes, TokenReviews, SubjectAccessReviews e CertificateSigningRequests .
Siga as instruções para verificar os webhooks que são considerados não seguros.

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 estarã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 dá suporte a eles:

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, 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.
Inspecione os pods de exibição em busca desse serviço. Identifique quais pods não estão em execução listando a implantação:
```
kubectl get deployment -n SERVICE_NAMESPACE
```
Também é possível executar 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 saber por que eles não estão em execução.

Webhooks considerados não seguros

Se um webhook interceptar recursos em namespaces gerenciados pelo sistema, a recomendação será a atualização para evitar a interceptação desses recursos.

Inspecione a configuração do webhook. Execute o seguinte comando kubectl para conferir 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 será 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 quando nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estão listados em recursos, como no seguinte exemplo:
```
- 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