Soluciona problemas de Distributed Cloud conectado

Google supervisa y mantiene de forma remota el hardware de Google Distributed Cloud conectado. Para ello, los ingenieros de Google tienen acceso de Secure Shell (SSH) al hardware de Distributed Cloud conectado. Si Google detecta un problema, un ingeniero de Google se comunicará contigo para solucionarlo. Si identificaste un problema, comunícate de inmediato con el equipo de Atención al Cliente de Google para diagnosticarlo y resolverlo.

Actualizaciones de software de Distributed Cloud conectado

En esta sección, se describe cómo usar el Explorador de métricas para verificar si un clúster conectado de Distributed Cloud está en proceso de actualización de software.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Versión actual del clúster (/edge_cluster/current_cluster_version): Indica la versión actual del software de Distributed Cloud conectado que se ejecuta en el clúster.

  • Versión de destino del clúster (/edge_cluster/target_cluster_version): Indica la versión de destino de Distributed Cloud Connected a la que se actualiza el clúster.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring
  3. (Opcional) Es el valor de machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados devueltos.

Usa el Explorador de métricas para verificar las versiones de software actuales y de destino del clúster

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso objetivo:

    1. En la página Explorador de métricas, navega a la página Configuración.

    2. Haz clic en Selecciona una métrica.

    3. Usa la barra de búsqueda para buscar el tipo de recurso Cluster. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Cluster.

    4. En los resultados que se muestran, haz clic en el tipo de recurso Clúster.

  3. Obtén la versión de software actual del clúster:

    1. En la sección Métrica, busca el valor current_cluster_version.

    2. Selecciona la métrica Tiempo de actividad de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

    3. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

  4. Obtén la versión de software de destino del clúster:

    1. Haz clic en Agregar consulta.

    2. En la sección Métrica, busca el valor target_cluster_version.

    3. Selecciona la métrica Versión del clúster de destino. Su ruta de acceso completa es edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

    4. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

  5. Verifica el estado de actualización del software del clúster en el gráfico que aparece.

    • Si las líneas Versión actual del clúster y Versión de destino del clúster indican valores diferentes, el clúster se está sometiendo a una actualización de software.

    • Si las líneas Versión actual del clúster y Versión de destino del clúster indican el mismo valor, el clúster no se está sometiendo a una actualización de software.

  6. Verifica el resultado del paso anterior con el siguiente comando:

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

    Reemplaza lo siguiente:

    • CLUSTER_ID: Es el ID del clúster de destino.
    • REGION: Es la región Google Cloud en la que se creó el clúster.

    En el resultado del comando, anota los valores de los siguientes campos:

    • Si el valor del campo status es UPDATING, el clúster se está actualizando.
    • Si los valores de los campos clusterVersion y targetVersion son diferentes, compáralos con los valores que muestra el Explorador de métricas.

Cómo comprender los resultados

En la siguiente tabla, se explican los resultados que muestran el Explorador de métricas y el comando gcloud.

Estado del clúster Diagnóstico Solución
Correcto
Los valores de currentVersion y targetVersion coinciden
El valor de "status" es RUNNING
 El clúster ejecuta la versión de destino del software de Distributed Cloud conectado. Ninguno
Actualización
El valor de currentVersion es inferior a targetVersion
El valor de "status" es UPDATING
 El clúster se está actualizando a la versión de destino del software conectado de Distributed Cloud. Supervisa el clúster en el Explorador de métricas hasta que coincidan los valores de la versión actual y la versión de destino del clúster.
Atascado
El valor de currentVersion es inferior a targetVersion de forma indefinida
El valor de "status" es UPDATING de forma indefinida
 No se pudo actualizar a la versión de destino del software conectado de Distributed Cloud en al menos un nodo del clúster. Verifica la conectividad de la máquina y los registros del sistema, y comunícate con Google para obtener ayuda.
Se revierte
El valor de currentVersion es mayor que el de targetVersion
El valor de "status" es UPDATING
 luster está revirtiendo a una versión anterior del software de Distributed Cloud conectado. Comunícate con Google para identificar el motivo de la reversión.

Si falló la actualización de software en el clúster o si el clúster revirtió a una versión anterior del software, verifica lo siguiente:

  • Estado del nodo Verifica que cada máquina física conectada a Distributed Cloud tenga conectividad de red y tiempo de actividad de informes, como se describe en la siguiente sección.
  • Períodos de mantenimiento. Verifica si la actualización de software se detuvo debido a un período de exclusión de mantenimiento.
  • Registros del sistema Examina los registros del sistema para identificar los posibles motivos de la falla en la actualización del software, como los tiempos de espera de desalojo de Pods.

Si los pasos de resolución que se indican en la tabla no resuelven el problema, comunícate con la Atención al Cliente de Google y proporciona el valor de machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Se reinicia la máquina de Distributed Cloud conectado

En esta sección, se describe cómo usar el Explorador de métricas para verificar si se reinició una máquina física conectada a Distributed Cloud y determinar el motivo del reinicio. Supervisar los reinicios ayuda a determinar si fueron parte de un mantenimiento planificado o el resultado de una falla de hardware o una interrupción de energía.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Tiempo de actividad de la máquina (/machine/uptime): Indica el tiempo, en segundos, desde el último reinicio.

  • Reinicios de la máquina (/machine/restart_count): Indica la cantidad total de reinicios de la máquina objetivo desde su implementación.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring
  3. (Opcional) Es el valor de machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados devueltos.

Usa el Explorador de métricas para verificar el tiempo de actividad y el recuento de reinicios de la máquina

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso objetivo:

    1. En la página Explorador de métricas, navega a la página Configuración.

    2. Haz clic en Selecciona una métrica.

    3. Usa la barra de búsqueda para buscar el tipo de recurso Máquina. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Machine.

    4. En los resultados que se muestran, haz clic en el tipo de recurso Máquina.

  3. Comprueba el tiempo de actividad de la máquina:

    1. En la sección Métrica, busca el valor uptime.

    2. Selecciona la métrica Tiempo de actividad de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/uptime.

    3. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que el gráfico de tiempo de actividad aumente de forma continua. Si en algún momento el valor de tiempo de actividad se reduce a cero y se reinicia, esto indica que la máquina se reinició.

  4. Verifica la cantidad de reinicios de la máquina:

    1. En la sección Métrica, busca el valor restart_count.

    2. Selecciona la métrica Reinicios de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/restart_count.

    3. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea del gráfico permanezca en 0, lo que indica que no se produjeron reinicios. Si en algún momento esta línea alcanza un pico de 1, esto indica que la máquina se reinició. Anota la marca de tiempo exacta del reinicio para solucionar problemas más adelante.

    5. (Opcional) Para ver eventos individuales en lugar de un gráfico, navega a la sección Agregación de la página, configura el campo Período de alineación en 1 minute y el campo Alineador por serie en Delta.

Cómo comprender los resultados

En la siguiente tabla, se explican los resultados que muestra el Explorador de métricas.

Estado de la máquina Diagnóstico Solución
Estable
La métrica "Tiempo de actividad de la máquina" aumenta de forma constante
El delta de la métrica "Reinicios de la máquina" es 0
 La máquina no se reinició. Ninguno
Reinicio limpio
La métrica "Tiempo de actividad de la máquina" disminuye a 0
La métrica "Reinicios de la máquina" aumenta a 1
 La máquina se reinició correctamente y se volvió a conectar a Google Cloud. Revisa los registros del sistema para determinar el motivo del reinicio.
Falla de energía
El gráfico de la métrica "Tiempo de actividad de la máquina" tiene una interrupción sin datos
La métrica "Reinicios de la máquina" no cambió durante la interrupción del tiempo de actividad de la máquina
 La máquina perdió la alimentación o la conectividad de red antes de que pudiera reiniciarse. Revisa los cables de alimentación y de red, la configuración de la red local y el estado del indicador LED.
Intermitente
El valor de la métrica "Máquina conectada" alterna entre 0 y 1
El valor de la métrica "Conectividad de red" alterna entre 0 y 1
 Conexión de red inestable, pérdida de paquetes o latencia excesiva Verifica si hay congestión y hardware defectuoso en tu red local.

Si los pasos de resolución que se indican en la tabla no resuelven el problema, comunícate con la Atención al Cliente de Google y proporciona el valor de machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Conectividad de máquinas de Distributed Cloud conectado

En esta sección, se describe cómo verificar la conectividad a Internet y de Google Cloud de tus máquinas conectadas a Distributed Cloud con la función Explorador de métricas de Cloud Monitoring.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Machine Connected (/machine/connected): Indica si la máquina está conectada a Google Cloud.

  • Network Connectivity (/machine/network/connectivity): Indica si la interfaz de red principal de la máquina tiene conectividad a Internet.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring
  3. (Opcional) Es el valor de machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados devueltos.

Usa el Explorador de métricas para verificar la conectividad de la máquina

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso objetivo:

    1. En la página Explorador de métricas, navega a la página Consultas.

    2. Usa la barra de búsqueda para buscar el tipo de recurso Máquina. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Machine.

    3. En los resultados que se muestran, haz clic en el tipo de recurso Máquina.

  3. Comprueba la conexión de la máquina a Google Cloud:

    1. En la sección Métrica, busca el valor connected.

    2. Selecciona la métrica Máquina conectada. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/connected.

    3. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea En buen estado permanezca en el 100% de forma contigua. Si en algún momento este valor es 0% o Unhealthy, la máquina perdió la conectividad con Google Cloud en el momento indicado.

  4. Comprueba la conectividad a Internet de la máquina:

    1. En la sección Métrica, busca el valor connectivity.

    2. Selecciona la métrica Network Connectivity. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/network/connectivity.

    3. (Opcional) Filtra por el valor de machine_id objetivo con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea En buen estado permanezca en el 100% de forma contigua. Si en algún momento este valor es 0% No saludable, significa que la máquina perdió la conectividad a Internet en el momento indicado.

Cómo comprender los resultados

En la siguiente tabla, se explican los resultados que muestra el Explorador de métricas.

Estado de la máquina Diagnóstico Solución
En buen estado
El valor de la métrica "Máquina conectada" es 1
El valor de la métrica "Conectividad de red" es 1
 Operación normal. Ninguno
Desconectado
El valor de la métrica "Máquina conectada" es 0
El valor de la métrica "Conectividad de red" es 1
 La máquina tiene conectividad a Internet, pero no se puede conectar a Google Cloud. Verifica tus reglas de firewall para los servicios y los extremos de las APIs de Google. Verifica que los agentes conectados de Distributed Cloud se estén ejecutando en la máquina.
Aislado
El valor de la métrica "Máquina conectada" es 0
El valor de la métrica "Conectividad de red" es 0
 La máquina no tiene conexión a Internet. Revisa los cables de alimentación y de red, la configuración de la red local y el estado del indicador LED. Verifica la configuración de VLAN y de enrutamiento.
Intermitente
El valor de la métrica "Máquina conectada" alterna entre 0 y 1
El valor de la métrica "Conectividad de red" alterna entre 0 y 1
 Conexión de red inestable, pérdida de paquetes o latencia excesiva Verifica si hay congestión y hardware defectuoso en tu red local.

Si observas valores sostenidos de 0 para cualquiera de las métricas, sigue los pasos para solucionar problemas que se describen en la tabla para resolverlos. Si el problema persiste, comunícate con Atención al Cliente de Google y proporciona el valor de machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Máquinas virtuales atascadas en el estado Pending

Una carga de trabajo de máquina virtual puede quedar atascada en el estado Pending y no programarse en un nodo si sucede una de las siguientes situaciones:

  • Distributed Cloud Connected no puede asignar los recursos solicitados, como tiempo de CPU, memoria o espacio en disco, a la máquina virtual.
  • Hay una falla en la configuración de la máquina virtual.
  • Hay una falla en el almacenamiento de la máquina virtual.
  • El nodo de destino está contaminado.

Para solucionar este problema, haz lo siguiente:

  1. Obtén credenciales del clúster como se describe en Cómo obtener credenciales para un clúster.

  2. Obtén información sobre la máquina virtual afectada:

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    Reemplaza lo siguiente:

    • VM_NAME: Es el nombre de la máquina virtual de destino.
    • NAMESPACE: Es el espacio de nombres de la máquina virtual de destino.

    El comando muestra un resultado similar al siguiente:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

    El resultado del comando contiene mensajes que pueden indicar limitaciones de recursos, fallas de programación, errores de almacenamiento y otros problemas.

  3. Examina el resultado para determinar las causas del error de programación, como se explica en las siguientes secciones.

Recursos insuficientes

Es posible que veas un mensaje que indica que no hay recursos suficientes, como CPU, memoria o espacio en disco. Por ejemplo:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Para solucionar este problema, verifica los recursos asignados a las máquinas virtuales afectadas y otras cargas de trabajo programadas en el nodo. Luego, haz lo siguiente según tus necesidades comerciales:

  • Reducir la escala de otras cargas de trabajo programadas en el nodo
  • Reducir la cantidad de recursos asignados a la máquina virtual afectada
  • Agrega más máquinas al clúster afectado.

Nodos con taint

Es posible que veas un mensaje que indica que el nodo de destino está dañado. Por ejemplo:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Para solucionar este problema, haz lo siguiente:

  1. Usa el siguiente comando para verificar si hay taints en el nodo:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    El comando muestra un resultado similar al siguiente:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. Realiza una de las siguientes acciones:

    • En el caso de los taints inesperados, quítalos como se describe en Taints y tolerancias.
    • Para los taints esperados, agrega las tolerancias correspondientes a la configuración de la máquina virtual, como se describe en Taints y tolerancias.

Fallas de almacenamiento

Es posible que veas un mensaje que indica una falla en el almacenamiento de la máquina virtual. Por ejemplo:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Este mensaje puede indicar que el volumen persistente correspondiente no se puede activar en el nodo de destino.

Para solucionar este problema, haz lo siguiente:

  1. Usa el siguiente comando para obtener el estado de los reclamos de volúmenes persistentes (PVC) en el espacio de nombres de la máquina virtual afectada:

    kubectl get pvc -n NAMESPACE

    Reemplaza NAMESPACE por el nombre del espacio de nombres de destino.

    El comando muestra un resultado similar al siguiente:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. Verifica que el PVC correspondiente tenga el estado Bound. Si el estado es Pending, significa que el subsistema de almacenamiento no pudo aprovisionar el volumen. En esos casos, debes solucionar los problemas de configuración del subsistema de almacenamiento y asegurarte de que esté disponible el StorageClass adecuado.

Bloqueos de programación causados por webhooks de admisión fallidos

Los webhooks de admisión te permiten interceptar solicitudes al servidor de la API de Kubernetes antes de que el objeto se vuelva persistente. Si bien son útiles para aplicar políticas de seguridad personalizadas, los webhooks mal configurados pueden causar interrupciones en todo el clúster, especialmente durante operaciones críticas, como actualizaciones de software y actualizaciones de certificados. Específicamente, un webhook de admisión bloqueado o no disponible puede detener el plano de control de Kubernetes, lo que impide cualquier programación adicional de cargas de trabajo en el clúster.

Interbloqueo del plano de control

Un interbloqueo por dependencia circular puede ocurrir cuando un webhook de admisión es responsable de validar los recursos que se requieren para la recuperación del propio webhook. Por ejemplo, si se configura un webhook de admisión para validar Pods y ese Pod de webhook debe reprogramarse durante una actualización de software del nodo, es posible que el servidor de la API de Kubernetes intente comunicarse con el webhook para autorizar la creación del nuevo Pod. Si no se puede acceder al webhook, la solicitud falla, no se crea el Pod y el clúster entra en un estado de interbloqueo en el que no se pueden programar cargas de trabajo nuevas.

Cuando se configura un webhook con failurePolicy: Fail, cualquier error de comunicación o tiempo de espera agotado entre el servidor de la API y el webhook provoca el rechazo de la solicitud a la API. Esto provoca los siguientes problemas:

  • Falla la actualización de software: No se pueden programar componentes del sistema ni VMs durante la actualización de software del nodo ni después de ella.
  • No se pueden iniciar los servicios del sistema: No se pueden iniciar los pods de infraestructura, como Symcloud Storage y VM Runtime en GDC.
  • Nodos atascados en modo de mantenimiento: Los nodos en modo de mantenimiento no se pueden reconciliar ni salir porque la lógica de admisión bloquea el controlador.

Prácticas recomendadas para la configuración de webhooks

Sigue las prácticas recomendadas que se describen en esta sección para evitar el bloqueo del plano de control que se mencionó anteriormente. Estas prácticas recomendadas se aplican a todos los objetos ValidatingWebhookConfiguration y MutatingWebhookConfiguration.

Utilizar failurePolicy: Ignore

A menos que los requisitos de tu empresa indiquen que una solicitud a la API debe fallar si no se puede validar, siempre establece el campo failurePolicy en Ignore. Esto garantiza que el servidor de la API de Kubernetes siga funcionando incluso cuando el servicio de webhook afectado no esté disponible, lo que permite que los Pods críticos para el sistema se programen y recuperen.

Excluye los espacios de nombres reservados

Tus webhooks nunca deben interceptar solicitudes de recursos en espacios de nombres reservados. Debes excluir esos espacios de nombres de la configuración del webhook con el campo namespaceSelector. Consulta Restricciones del espacio de nombres de administración para obtener una lista completa de los espacios de nombres reservados. Por ejemplo:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Recupera un clúster bloqueado por webhooks con errores

Si tu clúster se bloqueó debido a webhooks con errores y tus comandos kubectl para crear recursos agotan el tiempo de espera o muestran errores, por lo general, se debe a que el webhook tiene su failurePolicy establecido en Fail. Sigue los pasos que se indican en esta sección para recuperar el clúster del bloqueo. Si el webhook que falló es un webhook de mutación, usa mutatingwebhookconfiguration en lugar de validatingwebhookconfiguration.

  1. Identifica los webhooks fallidos:

    1. Enumera los webhooks de validación implementados en el clúster:

      kubectl get validatingwebhookconfigurations

    2. Enumera los webhooks de mutación implementados en el clúster:

      kubectl get mutatingwebhookconfigurations

  2. Verifica si los Pods que respaldan esos webhooks se están ejecutando:

    kubectl get pods -A | grep WEBHOOK_SERVICE

    Reemplaza WEBHOOK_SERVICE por el nombre del servicio del webhook de destino.

  3. Establece el failurePolicy del webhook fallido en Ignore:

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    Reemplaza WEBHOOK_SERVICE por el nombre del servicio del webhook de destino.

  4. (Opcional) Si falló el paso anterior, borra de forma forzada la configuración del webhook afectado:

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    Reemplaza WEBHOOK_CONFIG por el nombre de la configuración del webhook de destino.

Después de modificar o borrar por la fuerza la configuración del webhook, el servidor de la API de Kubernetes reanuda el procesamiento de solicitudes, lo que resuelve el interbloqueo y permite que se completen los procesos bloqueados.