¿Por qué fallan las operaciones del clúster maestro debido a un webhook defectuoso?

Nube privada virtual Infraestructura clásica

Este tema de resolución de problemas no es para la resolución de problemas de webhook general. Consulte Depuración de webhooks para ver los problemas de webhook no relacionados con la actualización del maestro de clúster.

Soluciona los problemas relacionados con los webhooks defectuosos que interfieren en las operaciones del clúster maestro.

Durante una operación en el nodo maestro, como por ejemplo actualizar la versión del clúster, el clúster tenía una aplicación webhook dañada.

Ahora, no se pueden completar las operaciones del nodo maestro. Verá un error parecido al siguiente:

Cannot complete cluster master operations because the cluster has a broken webhook application. For more information, see the troubleshooting docs: 'https://ibm.biz/master_webhook'

El clúster tiene recursos de webhook de Kubernetes que se pueden configurar, validando o mutando los webhooks de admisión, que pueden interceptar y modificar solicitudes procedentes de diversos servicios del clúster destinadas al servidor de API del nodo maestro del clúster.

Puesto que los webhooks pueden cambiar o rechazar solicitudes, los webhooks dañados pueden afectar a la funcionalidad del clúster de varias maneras; por ejemplo, pueden impedir que se actualice la versión del nodo maestro u otras operaciones de mantenimiento. Para obtener más información, consulta la sección Control dinámico de admisión en la documentación de Kubernetes.

Las posibles causas de que un webhook resulte dañado incluyen las siguientes:

Falta el recurso subyacente que emite la solicitud o no está en buen estado, como un servicio de Kubernetes, un punto final o un pod.
El webhook forma parte de un complemento o de otra aplicación de plugin que no se ha instalado correctamente o que no está en buen estado.
El clúster puede tener un problema de conectividad de red que impida que el webhook se comunique con el servidor de la API de Kubernetes en el nodo maestro del clúster.

Ejecute los siguientes comandos para crear un pod de prueba para obtener un error que identifique el webhook roto. Si la prueba se supera, es posible que el fallo haya sido temporal y se pueda volver a intentar.

Ejecute los siguientes comandos para crear el pod de prueba y etiquetar el ibm-system espacio de nombres.

oc run webhook-test --image us.icr.io/armada-master/pause:3.10 -n ibm-system
oc delete pod -n ibm-system webhook-test --ignore-not-found
oc label ns ibm-system ibm-cloud.kubernetes.io/webhook-test-at="$(date -u +%FT%H_%M_%SZ)" --overwrite

Es posible que el mensaje de error contenga el nombre del webhook dañado. En el siguiente ejemplo de resultado, el webhook es trust.hooks.securityenforcement.admission.cloud.ibm.com.

Error from server (InternalError): Internal error occurred: failed calling webhook "trust.hooks.securityenforcementadmission.cloud.ibm.com": Post https://ibmcloud-image-enforcement.ibm-system.svc:443/mutating-pods?timeout=30s: dialtcp 172.21.xxx.xxx:443: connect: connection timed out

Obtenga el nombre del webhook dañado.

Si el mensaje de error contiene un webhook dañado, sustituya trust.hooks.securityenforcement.admission.cloud.ibm.com por el webhook dañado que ha identificado previamente.

    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations -o jsonpath='{.items[?(@.webhooks[*].name=="trust.hooks.securityenforcement.admission.cloud.ibm.com")].metadata.name}{"\n"}'
    ```
    Salida de ejemplo
    ```sh {: pre}
    image-admission-config
    ```
*   Si el error no contiene un webhook dañado, obtenga una lista de todos los webhooks del clúster y compruebe sus configuraciones en los siguientes pasos.
```sh {: pre}
    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations
    ```

Revise los detalles de servicio y de ubicación de la configuración de webhook de mutación o de validación en la sección clientConfig de la salida del mandato siguiente. Sustituya image-admission-config por el nombre que ha identificado previamente. Si el webhook existe fuera del clúster, póngase en contacto con el propietario del clúster para comprobar el estado del webhook.
```
oc get mutatingwebhookconfiguration image-admission-config -o yaml
```
```
oc get validatingwebhookconfigurations image-admission-config -o yaml
```
Salida de ejemplo
```
  clientConfig:
    caBundle: <redacted>
    service:
        name: <name>
        namespace: <namespace>
        path: /inject
        port: 443
```

Opcional: Haz una copia de seguridad de los webhooks, especialmente si no sabes cómo reinstalar el webhook o no tienes los permisos necesarios para crear webhooks.

oc get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml

oc get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml

Compruebe el estado del servicio relacionado y de los pods correspondientes al webhook.

Compruebe los campos Type, Selector y Endpoint del servicio.

    oc describe service -n <namespace> <service_name>
    ```
2. Si el tipo de servicio es **ClusterIP**, comprueba que el pod de Konnectivity se encuentre en estado **Running** para que el webhook pueda conectarse de forma segura a la API de Kubernetes en el nodo maestro del clúster. Si el pod no está en buen estado, compruebe los sucesos de pod, los registros, el estado del nodo trabajador y otros componentes para resolver el problema.

    * Compruebe los pods del agente de Konnectivity.
        ```sh {: pre}
        oc describe pods -n kube-system -l app=konnectivity-agent
        ```

1. Si el servicio no tiene un punto final, compruebe el estado de los recursos de respaldo, como por ejemplo un despliegue o un pod. Si el recurso no está en buen estado, compruebe los sucesos de pod, los registros, el estado del nodo trabajador y otros componentes para resolver el problema. Para obtener más información, consulte [Depuración de despliegues de app](/docs/openshift?topic=openshift-debug_apps).
```sh {: pre}
    oc get all -n my-service-namespace -l <key=value>
    ```
1. Si el servicio no dispone de recursos de respaldo, o si la resolución de problemas de los pods no soluciona el problema, elimine la configuración del webhook de mutación o validación identificada anteriormente.
```sh {: pre}
    oc delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    oc delete mutatingwebhookconfiguration NAME
    ```

Vuelva a intentar la operación del nodo maestro del clúster, como por ejemplo actualizar el clúster.
Si todavía ve el error, es posible que tenga problemas de conectividad de red o del nodo trabajador.
- Resolución de problemas de nodos trabajadores.
- Asegúrese de que el webhook se puede conectar al servidor de API de Kubernetes en el nodo maestro del clúster. Por ejemplo, si utiliza políticas de red de Calico, grupos de seguridad o algún otro tipo de cortafuegos, configure el clúster clásico o de VPC con el acceso adecuado.
- Si el webhook está gestionado por un complemento que ha instalado, desinstale el complemento. Estos son algunos complementos comunes que causan problemas de webhook:
  - Portieris
Vuelva a crear el webhook o vuelva a instalar el complemento.
Si el problema persiste, póngase en contacto con soporte. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir todos los archivos de registro, mensajes de error o salidas de comandos relevantes.