Solução de problemas relacionados a erros de webhook em clusters do IBM Cloud Kubernetes

Resolva problemas relacionados a webhooks no seu cluster do IBM Cloud Kubernetes, identificando e depurando o webhook problemático.

Ao executar comandos oc, você vê mensagens de erro semelhantes aos exemplos a seguir.

Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out

error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s

Falhar webhooks também pode causar problemas semelhantes aos seguintes problemas.

Você não pode criar ou modificar podas, segredos ou espaços de nomes.
Não é possível incluir nós do trabalhador em um cluster ou criar um segredo que contenha a chave de criptografia LUKS.
Você não pode corrigir, atualizar ou fazer o upgrade e a falha subjacente está relacionada à criação de recursos no cluster.

Um problema no chamado serviço ou no túnel seguro pode fazer com que os pedidos falhem devido aos tempos limites. Você pode desconhecer que você tem webhooks de controle de admissão instalados até que isso aconteça.

Os webhooks de controle de admissão fornecem a capacidade de validar ou modificar, ou mutar, solicitações de API Kubernetes. Estes webhooks são chamados a partir do cluster apiserver ou openshift-apiserver e tipicamente chamam um serviço em execução no cluster. Os webhooks de controle de admissão têm regras que definem o tipo de recurso, como pod, namespace, etc., e a operação para a qual são chamados, como criar, recuperar, atualizar ou excluir.

Webhooks possuem uma política de falha que indica se Kubernetes pode ignorar erros de conexão ao ligar para o webhook ou se o erro de conexão deve falhar a operação. Um recurso ValidatingWebhookConfiguration inspeciona a solicitação enquanto um recurso MutatingWebhookConfiguration modifica os dados da solicitação antes que ele seja processado.

Webhooks também podem negar solicitações como parte da operação normal: um webhook pode negar solicitações que violam políticas de segurança ou pode executar outra validação de dados. Nesses casos, as informações de falha contêm uma resposta denied the request com um motivo que indica o problema

admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported

Em Red Hat OpenShift on IBM Cloud, webhooks que chamam de serviços em execução no cluster o fazem usando um túnel seguro que conecta o plano de controle de cluster em uma conta IBM Cloud para clusters de trabalhadores de cluster em sua conta de cliente.

Complete as etapas a seguir para identificar o webhook que está causando o problema. Em seguida depurar o serviço relacionado e remover ou recriar seu webhook se necessário.

Execute os comandos a seguir para obter os logs do pod de VPN Se você não pode obter os logs de VPN, siga os passos para Debug problemas comuns da CLI e retorne para esta página quando for capaz de recuperar os logs. Se os comandos forem bem-sucedidos e você puder obter os logs, o túnel VPN estará funcionando e será possível continuar com a próxima etapa.
```
oc get pods -n kube-system -l app=vpn
```
```
oc logs -n kube-system -l app=vpn
```
Descreva seus webhooks de controle de admissão e salve a saída em um arquivo chamado webhooks.txt.
```
kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
```
Revise o arquivo webhooks.txt para mensagens de erro. Mensagens de erro relacionadas ao Webhook a partir de um aplicativo, incluindo oc, podem ajudar a identificar o webhook.
Revise as métricas de apiserver para o tipo de rejeição, conte e o código de rejeição. Você pode obter um resumo das métricas usando o comando a seguir.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count
```
```
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16
```
Um valor rejection_code de 0 indica um erro ocorreu ao chamar o webhook. Um valor de não zero rejection_code indica que o webhook rejeitou o pedido.

Há 3 instâncias apiserver. O comando oc obtém métricas de um deles e reflete a atividade lá. Cada apiserver retorna dados diferentes. Instâncias que não processaram as solicitações com falha podem não retornar esta métrica.
Revise a saída de comando das etapas anteriores e procure descrições de webhook para identificar o valor específico MutatingWebhookConfiguration ou ValidatingWebhookConfiguration. Se os erros, logs ou métricas não ajudam, revise as descrições de webhook que você recuperou anteriormente. Cada configuração de webhook possui um conjunto de regras que especificam os tipos de recursos e ações que o webhook é chamado para. Essas informações podem ser usadas para identificar o (s) webhook (s) que podem estar envolvidos.
- Se houver um erro ao chamar o webhook, revise a documentação para esse serviço para etapas de depuração específicas do produto.
- Se o webhook estiver rejeitando os pedidos, veja as políticas e opções de configuração para o webhook. Pode ser possível ajustá-los para permitir o pedido. Ou ainda, a solicitação pode estar violando as políticas e a solicitação ou o aplicativo fazendo o pedido precisa ser alterado. Para obter mais informações, consulte Quais são as melhores práticas para uso de webhooks.

Revisando o serviço que o webhook está chamando

Obtem os detalhes do serviço e de seus terminais.
```
kubectl get svc NAME -n NAMESPACE
```
```
kubectl get ep NAME -n NAMESPACE
```
- Se o webhook está chamando um serviço que não existe, o webhook pode ser sobra de uma remoção incompleta ou indevida de um aplicativo. Nesse caso, procure a documentação específica do serviço e siga os passos para desinstalar o serviço.
- Se você não conseguir desinstalar o serviço, exclua a configuração do webhook.
```
    kubectl delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    kubectl delete mutatingwebhookconfiguration NAME
    ```
```
Se o serviço existe, mas não tem terminais, verifique a saúde dos pods. Primeiro, pegue os rótulos de pod do serviço.
```
kubectl describe svc NAME -n NAMESPACE
```
Saída de exemplo
```
Selector:          app=my-webhook
```
Liste os pods que estão usando os rótulos. Por exemplo, a etiqueta no comando a seguir é app=mywebhook.
```
kubectl get pods -n NAMESPACE -l app=my-webhook
```
Revise a saída de comando. Se os pods não estiverem funcionando corretamente, verifique os eventos dos pods, os logs, o estado dos nós de trabalho e outros componentes para solucionar o problema. Para obter mais informações, consulte Depurando implementações de aplicativos.

Desabilitando ou removendo um webhook

Ignoram temporariamente a conexão e os tempos de timeouts configurando a política de falha para Ignore. Edite o webhook executando os seguintes comandos.
```
kubectl edit validatingwebhookconfiguration NAME
```
```
kubectl edit mutatingwebhookconfiguration NAME
```
Procure por failurePolicy e altere o valor para Ignore.
Salve a configuração e saia do editor. Se ajustar a política de falha não resolve a questão, repita as etapas anteriores e altere o valor de volta para Fail.

Remova temporariamente o webhook. Salve a configuração do webhook existente em um arquivo antes de excluí-o.

kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml

Excluir a configuração do webhook.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME

Aguarde alguns minutos, em seguida, tente novamente os comandos kubectl que estavam falhando para ver se o problema está resolvido.
Recriar o webhook.
```
kubectl apply -f webhook-config.yaml
```
Se o problema persistir, entre em contato com o suporte. Abrir um caso de suporte. Nos detalhes do caso, certifique-se de incluir qualquer arquivo de log relevante, mensagens de erro ou saídas de comandos.