Risoluzione degli errori relativi ai webhook nei cluster IBM Cloud Kubernetes

Risolvi i problemi relativi ai webhook nel tuo cluster IBM Cloud Kubernetes individuando e correggendo il webhook problematico.

Quando si eseguono i comandi oc, vengono visualizzati dei messaggi di errore simili ai seguenti esempi.

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

I webhook malfunzionanti potrebbero anche causare problemi simili ai seguenti.

Non puoi creare o modificare i pod, i segreti o gli spazi dei nomi.
Non puoi aggiungere nodi di lavoro a un cluster o creare un segreto che contiene la chiave di crittografia LUKS.
Non è possibile applicare patch, aggiornare o aggiornare e l'errore sottostante è correlato alla creazione di risorse nel cluster.

Un problema nel servizio richiamato o nel tunnel protetto può causare l'esito negativo delle richieste a causa dei timeout. Potresti non essere a conoscenza del fatto che hai dei webhook di controllo di ammissione installati fino a quando ciò non accade.

I webhook di controllo di ammissione forniscono la capacità di convalidare o modificare o modificare le richieste API Kubernetes. Questi webhook vengono richiamati dal cluster apiserver o openshift-apiserver e generalmente richiamano un servizio in esecuzione nel cluster. I webhook di controllo dell'ammissione hanno regole che definiscono il tipo di risorsa, come pod, spazio dei nomi e così via, e l'operazione per cui sono chiamati, come creare, recuperare, aggiornare o eliminare.

I webhook hanno una politica di errore che indica se Kubernetes può ignorare gli errori di connessione quando richiama il webhook o se l'errore di connessione deve non riuscire nell'operazione. Una risorsa ValidatingWebhookConfiguration esamina la richiesta mentre una risorsa MutatingWebhookConfiguration modifica i dati della richiesta prima che vengano elaborati.

I webhook possono anche negare le richieste come parte del normale funzionamento: un webhook potrebbe negare le richieste che violano le politiche di sicurezza o potrebbe eseguire un'altra convalida dei dati. In tali casi, le informazioni sull'errore contengono una risposta denied the request con un motivo che indica il problema.

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

In Red Hat OpenShift on IBM Cloud, i webhook che richiamano i servizi in esecuzione nel cluster lo fanno utilizzando un tunnel protetto che connette il piano di controllo del cluster in un account IBM Cloud ai nodi di lavoro del cluster nel tuo account cliente.

Completa la seguente procedura per identificare il webhook che sta causando il problema. Quindi, eseguire il debug del servizio correlato e rimuovere o ricreare il webhook, se necessario.

Immetti questi comandi per ottenere i log del pod VPN. Se non riesci a ottenere i log VPN, segui la procedura per Debug dei problemi comuni della CLI e torna a questa pagina quando puoi richiamare i log. Se i comandi hanno esito positivo e puoi ottenere i log, il tunnel VPN funziona e puoi continuare con il passo successivo.
```
oc get pods -n kube-system -l app=vpn
```
```
oc logs -n kube-system -l app=vpn
```
Descrivere i webhook di controllo di ammissione e salvare l'emissione in un file denominato webhooks.txt.
```
kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
```
Esaminare il file webhooks.txt per i messaggi di errore. I messaggi di errore relativi al webhook da un'applicazione, incluso oc, possono aiutare a identificare il webhook.
Esaminare le metriche apiserver per il tipo di rifiuto, il conteggio e il codice di rifiuto. Puoi ottenere un'istantanea delle metriche utilizzando il seguente comando.
```
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
```
Un valore rejection_code pari a 0 indica che si è verificato un errore durante il richiamo del webhook. Un valore rejection_code diverso da zero indica che il webhook ha rifiutato la richiesta.

Ci sono 3 istanze apiserver. Il comando oc richiama le metriche da una di esse e riflette l'attività. Ogni apiserver restituisce dati differenti. Le istanze che non hanno elaborato le richieste non riuscite potrebbero non restituire questa metrica.
Esamina l'output del comando dai passi precedenti e cerca le descrizioni webhook per identificare il valore MutatingWebhookConfiguration o ValidatingWebhookConfiguration specifico. Se gli errori, i log o le metriche non sono di aiuto, esamina le descrizioni del webhook che hai richiamato in precedenza. Ogni configurazione webhook ha una serie di regole che specificano i tipi di risorse e azioni per cui viene richiamato il webhook. Queste informazioni possono essere utilizzate per identificare i webhook che potrebbero essere coinvolti.
- Se si verifica un errore durante il richiamo del webhook, esaminare la documentazione per tale servizio per i passi di debug specifici del prodotto.
- Se il webhook sta rifiutando le richieste, esaminare le politiche e le opzioni di configurazione per il webhook. Potrebbe essere possibile modificarli per consentire la richiesta. Oppure, la richiesta potrebbe violare le politiche e la richiesta o l'applicazione che effettua la richiesta deve essere modificata. Per ulteriori informazioni, vedi Quali sono le procedure ottimali per l'utilizzo dei webhook.

Revisione del servizio che il webhook sta chiamando

Ottenere i dettagli del servizio e dei suoi endpoint.
```
kubectl get svc NAME -n NAMESPACE
```
```
kubectl get ep NAME -n NAMESPACE
```
- Se il webhook sta richiamando un servizio che non esiste, il webhook potrebbe essere rimasto da una rimozione incompleta o non corretta di un'applicazione. In questo caso, cercare la documentazione specifica del servizio e seguire la procedura per disinstallarlo.
- Se non riesci a disinstallare il servizio, elimina la configurazione webhook.
```
    kubectl delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    kubectl delete mutatingwebhookconfiguration NAME
    ```
```
Se il servizio esiste, ma non ha endpoint, controlla l'integrità dei pod. Per prima cosa, ottieni le etichette del pod dal servizio.
```
kubectl describe svc NAME -n NAMESPACE
```
Output di esempio
```
Selector:          app=my-webhook
```
Elenca i pod che utilizzano le etichette. Ad esempio, l'etichetta nel seguente comando è app=mywebhook.
```
kubectl get pods -n NAMESPACE -l app=my-webhook
```
Esaminare l'output del comando. Se i pod non sono in buono stato, controllare gli eventi dei pod, i log, lo stato dei nodi worker e gli altri componenti per risolvere il problema. Per ulteriori informazioni, vedi Debug delle distribuzioni dell'applicazione.

Disabilitazione o rimozione di un webhook

Ignorare temporaneamente la connessione e i timeout impostando la politica di errore su Ignore. Modifica il webhook eseguendo i seguenti comandi.
```
kubectl edit validatingwebhookconfiguration NAME
```
```
kubectl edit mutatingwebhookconfiguration NAME
```
Ricercare failurePolicy e modificare il valore in Ignore.
Salva la configurazione ed esci dall'editor. Se la modifica della politica di errore non risolve il problema, ripetere i passi precedenti e modificare nuovamente il valore in Fail.

Rimuovere temporaneamente il webhook. Salvare la configurazione del webhook esistente in un file prima di eliminarla.

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

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

Elimina la configurazione webhook.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME

Attendere alcuni minuti, quindi ritentare i comandi kubectl che non erano in grado di verificare se il problema è stato risolto.
Ricreare il webhook.
```
kubectl apply -f webhook-config.yaml
```
Se il problema persiste, contattare il supporto. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere i file di log, i messaggi di errore o gli output dei comandi pertinenti.