Solución de problemas de errores de webhooks en clústeres de IBM Cloud Kubernetes

Resuelve los problemas relacionados con los webhooks en tu clúster de IBM Cloud Kubernetes identificando y depurando el webhook problemático.

Al ejecutar mandatos oc, verá mensajes de error similares a los de los ejemplos siguientes.

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

Los webhooks anómalos también pueden causar problemas similares a los siguientes.

No puede crear o modificar pods, secretos o espacios de nombres.
No puede añadir nodos trabajadores a un clúster o crear un secreto que contenga la clave de cifrado LUKS.
No puede aplicar parches, actualizar o actualizar y el error subyacente está relacionado con la creación de recursos en el clúster.

Un problema en el servicio llamado o en el túnel seguro puede hacer que las solicitudes fallen debido a tiempos de espera excedidos. Es posible que no sepa que tiene webhooks de control de admisión instalados hasta que esto suceda.

Los webhooks de control de admisión proporcionan la posibilidad de validar o modificar, o mutar, las solicitudes de API de Kubernetes. Estos webhooks se llaman desde el clúster apiserver o openshift-apiserver y normalmente llaman a un servicio que se ejecuta en el clúster. Los webhooks de control de admisión tienen reglas que definen el tipo de recurso, como pod, espacio de nombres, etc., y la operación para la que se solicitan, como crear, recuperar, actualizar o eliminar.

Los webhooks tienen una política de anomalía que indica si Kubernetes puede ignorar los errores de conexión al llamar al webhook o si el error de conexión debe fallar la operación. Un recurso ValidatingWebhookConfiguration inspecciona la solicitud mientras que un recurso MutatingWebhookConfiguration modifica los datos de la solicitud antes de que se procesen.

Los webhooks también pueden denegar solicitudes como parte del funcionamiento normal: un webhook puede denegar solicitudes que violen las políticas de seguridad o puede realizar otra validación de datos. En tales casos, la información de anomalía contiene una respuesta denied the request con una razón que indica el problema.

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

En Red Hat OpenShift on IBM Cloud, los webhooks que llaman a servicios que se ejecutan en el clúster lo hacen utilizando un túnel seguro que conecta el plano de control del clúster en una cuenta de IBM Cloud a los nodos trabajadores del clúster de su cuenta de cliente.

Realice los pasos siguientes para identificar el webhook que está causando el problema. A continuación, depure el servicio relacionado y elimine o vuelva a crear el webhook si es necesario.

Ejecute los mandatos siguientes para obtener los registros de pod de VPN. Si no puede obtener los registros de VPN, siga los pasos para Depurar problemas de CLI comunes y vuelva a esta página cuando pueda recuperar los registros. Si los mandatos se ejecutan correctamente y puede obtener los registros, el túnel VPN está funcionando y puede continuar con el paso siguiente.
```
oc get pods -n kube-system -l app=vpn
```
```
oc logs -n kube-system -l app=vpn
```
Describa los webhooks de control de admisión y guarde la salida en un archivo denominado webhooks.txt.
```
kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
```
Revise el archivo webhooks.txt para ver los mensajes de error. Los mensajes de error relacionados con webhook de una aplicación, incluido oc, pueden ayudarle a identificar el webhook.
Revise las métricas de apiserver para el tipo de rechazo, el recuento y el código de rechazo. Puede obtener una visión general de las métricas utilizando el siguiente 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 valor de rejection_code de 0 indica que se ha producido un error al llamar al webhook. Un valor de rejection_code distinto de cero indica que el webhook ha rechazado la solicitud.

Hay 3 instancias de apiserver. El mandato oc obtiene métricas de uno de ellos y refleja la actividad allí. Cada apiserver devuelve datos diferentes. Es posible que las instancias que no han procesado las solicitudes anómalas no devuelvan esta métrica.
Revise la salida del mandato de los pasos anteriores y busque descripciones de webhook para identificar el valor MutatingWebhookConfiguration o ValidatingWebhookConfiguration específico. Si los errores, registros o métricas no ayudan, revise las descripciones de webhook que ha recuperado anteriormente. Cada configuración de webhook tiene un conjunto de reglas que especifican los tipos de recursos y acciones para los que se llama al webhook. Esta información se puede utilizar para identificar los webhook que pueden estar implicados.
- Si se produce un error al llamar al webhook, revise la documentación de dicho servicio para ver los pasos de depuración específicos del producto.
- Si el webhook rechaza las solicitudes, consulte las políticas y las opciones de configuración del webhook. Es posible ajustarlos para permitir la solicitud. O bien, la solicitud puede estar violando las políticas y la solicitud o la aplicación que realiza la solicitud debe cambiarse. Para obtener más información, consulte Cuáles son las mejores prácticas para utilizar webhooks.

Revisión del servicio al que llama el webhook

Obtenga los detalles del servicio y sus puntos finales.
```
kubectl get svc NAME -n NAMESPACE
```
```
kubectl get ep NAME -n NAMESPACE
```
- Si el webhook está llamando a un servicio que no existe, es posible que el webhook esté sobrante de una eliminación incompleta o incorrecta de una aplicación. En este caso, busque la documentación específica del servicio y siga los pasos para desinstalar el servicio.
- Si no puede desinstalar el servicio, suprima la configuración de webhook.
```
    kubectl delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    kubectl delete mutatingwebhookconfiguration NAME
    ```
```
Si el servicio existe, pero no tiene puntos finales, compruebe el estado de los pods. En primer lugar, obtenga las etiquetas de pod del servicio.
```
kubectl describe svc NAME -n NAMESPACE
```
Salida de ejemplo
```
Selector:          app=my-webhook
```
Enumera los pods que utilizan las etiquetas. Por ejemplo, la etiqueta del mandato siguiente es app=mywebhook.
```
kubectl get pods -n NAMESPACE -l app=my-webhook
```
Revise la salida del mandato. Si los pods no están en buen estado, comprueba los eventos de los pods, los registros, el estado de los nodos de trabajo y otros componentes para solucionar el problema. Para obtener más información, consulte Depuración de despliegues de app.

Inhabilitación o eliminación de un webhook

Ignore temporalmente la conexión y los tiempos de espera estableciendo la política de anomalía en Ignore. Edita el webhook ejecutando los siguientes comandos.
```
kubectl edit validatingwebhookconfiguration NAME
```
```
kubectl edit mutatingwebhookconfiguration NAME
```
Busque failurePolicy y cambie el valor a Ignore.
Guarda la configuración y sal del editor. Si el ajuste de la política de anomalía no resuelve el problema, repita los pasos anteriores y vuelva a cambiar el valor a Fail.

Elimine temporalmente el webhook. Guarde la configuración de webhook existente en un archivo antes de suprimirla.

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

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

Suprima la configuración de webhook.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME

Espere unos minutos y, a continuación, vuelva a intentar los mandatos kubectl que no han podido ver si se ha resuelto el problema.
Vuelva a crear el webhook.
```
kubectl apply -f webhook-config.yaml
```
Si el problema persiste, póngase en contacto con soporte. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir los archivos de registro relevantes, los mensajes de error o las salidas de mandato.